A self-funded company has a different relationship with its infrastructure bill than a funded one. There is no runway to burn through and no quarter in which the numbers stop mattering. The bill is not a line item; it is the floor under the price of the product.
This piece is about where the money actually goes when you run subscription software from Australia, and the decisions that keep it small without making the software worse.
Australian regions cost more, and it is usually still right
Compute, storage and data transfer in Australian regions are priced above the large North American regions. That premium is real, it shows up on every invoice, and the honest answer is that it is usually worth paying anyway.
Latency for local customers, data residency you can state plainly, and a story a privacy-conscious buyer accepts are worth more than the difference on a bill of this size. Where the premium actually hurts is at volume: if you are moving large amounts of data or running fleets of always-on instances, the gap compounds and deserves a proper analysis rather than a principle.
For a small subscription product, though, the cloud bill is rarely dominated by the region. It is dominated by what you left running.
Where the money actually goes
In rough order of how often it surprises people:
Idle capacity. A database instance provisioned for a launch that has not happened yet, a staging environment nobody switched off, a NAT gateway sitting in a VPC doing nothing at three in the morning. Idle resources are the most expensive thing in a small stack, because they cost the same whether you have ten customers or ten thousand.
Data transfer out. Egress is the line item that catches everyone. Traffic leaving the cloud to the internet is billed per gigabyte, cross-region replication is billed, and in some architectures traffic between availability zones is billed too. An image-heavy product with no caching layer can spend more on moving bytes than on storing or serving them.
Logs and metrics. Observability is priced by ingestion and retention, and the default settings are generous in the vendor’s favour. Debug logging left on in production for a fortnight can cost more than the service it was debugging.
Per-request pricing on chatty architectures. Serverless functions and managed queues are cheap per call and not cheap per million calls. A polling loop that felt harmless in development has a monthly price.
Model inference, where you use it. AI features are the newest line on the bill and the easiest to misjudge, because cost scales with usage in a way that traditional hosting does not. Budget it per feature and cap it, or it becomes a variable cost you cannot price a subscription around.
The architecture that keeps the bill boring
Nothing here is clever. That is the point.
Static where static is possible. This website is built ahead of time into plain HTML and served through a content delivery network. There is no server to run, patch, scale or pay for while nobody is reading. A studio site with a database behind it is a cost and a security surface bought for no reason.
Managed services over instances we would have to operate. A managed database costs more per hour than a virtual machine and less per year than the time spent patching one. For a two-person company, the hours are the scarce resource.
Scale to zero where the traffic allows it. Background work that runs a few times a day belongs in something that costs nothing when it is not running.
Cache at the edge aggressively. Every response served from a point of presence is a request your origin does not pay for, plus a faster page. Long cache lifetimes on hashed asset filenames make this free of invalidation pain.
One environment less than you think you need. Production and a single, cheap, scaled-down preview is usually enough. A third environment that mirrors production is a second production bill.
Retention policies on everything that accumulates. Logs, metrics, backups, build artefacts. Set the policy when you create the bucket, because nobody ever goes back to clean up storage that is quietly costing a few dollars a month.
The costs that are not on the cloud bill
The invoice is the easy part to see, and usually not the biggest number.
Store commissions. If you sell through the App Store or Google Play, the platform takes a percentage of every subscription. Both operate reduced rates for small developers below an annual revenue threshold, and both handle tax collection in many jurisdictions as part of that arrangement. It is a meaningful share of revenue, and it changes the arithmetic of web checkout versus in-app purchase.
Payment processing. Card fees, international card surcharges and currency conversion, plus a chargeback fee when a customer disputes rather than emails.
Software you did not think of as infrastructure. Error monitoring, email delivery, domains, certificates for anything not automated, design tools, a password manager. Individually small, collectively a real monthly number.
Support. Every hour answering email is an hour not building. This is the cost that actually limits how many products a small company can run, and no amount of cloud optimisation touches it.
Compliance and advice. Accountant, and a solicitor when policies or contracts need reviewing. Cheaper before you need it than after.
How we keep it honest
Three habits, none of them sophisticated:
Look at the bill every month, by service. Not the total. The total tells you nothing except whether to panic. The breakdown tells you what changed, and one line always has.
Set a budget alarm at a number that would annoy you. Not at a number that would ruin you. The point is to find the runaway loop on day two, not day thirty.
Delete things. The cheapest resource is the one that no longer exists. Old environments, unused buckets, abandoned branches with pipelines attached, the proof of concept from eighteen months ago. A quarterly sweep pays for itself.
The number that matters
For a subscription business, infrastructure cost per paying customer per month is the number worth watching, not the absolute bill. If it is falling as you grow, the architecture is working. If it is flat, you have a per-customer cost you have not noticed. If it is rising, something is wrong and it is usually either a chatty architecture or a feature that quietly does inference on every request.
Our own answer is deliberately unexciting: static where possible, managed where not, Australian regions, short retention, few vendors. It is not the cheapest possible bill. It is the cheapest bill that two people can understand completely, which is a more useful property.
Next: compliance is product work, where the rules stop being background noise and start changing what you build.