Most writing about how to build software is written somewhere else. It assumes a domestic market of hundreds of millions of people, a venture pipeline three offices away, engineers who can be hired on a fortnight’s notice, and a data centre in the same time zone as the customers. None of that describes Australia.
This is the first of six pieces about what actually changes when you build and run subscription software from here. Not the patriotic version. The practical one: the constraints that are real, the ones that are imagined, and the decisions that follow.
The market is smaller than the pitch deck assumes
Twenty seven million people is not nothing, but it will not carry a product that needs a million paying customers to work. That single fact reshapes the sensible strategy for a small Australian software company.
If you need enormous volume, you have to be global from the first line of code, which means currencies, tax treatments, app store tiers and support hours you have not planned for. If you can be profitable at a few thousand subscribers, you can stay local, stay small and keep the whole thing comprehensible. The failure mode is choosing neither, and building for a domestic market at a price point that only works globally.
We picked the second option deliberately. Two products, each of which has to pay for itself, run by the people who wrote them. That decision cascades through everything in this series, including the boring architectural choices in part four.
Distance is real, and it is mostly solved
Australia is a long way from the machines that run the internet. A round trip from Sydney to a server on the east coast of the United States costs the better part of 200 milliseconds before your code does anything at all. Put four of those in sequence behind a login screen and the product feels broken.
The good news is that this problem has known answers: run in an Australian region, put static assets on an edge network, and design so that the round trip is not on the critical path in the first place. That is part three.
The bad news is that it is easy to inherit the problem accidentally. A default region in a console, a third-party API that only exists in Virginia, an analytics script that blocks rendering — none of that shows up on a developer’s machine in an office with fibre, and all of it shows up on a phone in a regional town.
The rules are specific, and they are not American
Australian software has to satisfy Australian law, and the defaults baked into most libraries, templates and SaaS vendors are not written for it. The Privacy Act and the Australian Privacy Principles are not the GDPR with different words. Consumer guarantees under the Australian Consumer Law cannot be contracted away, no matter what an imported terms template says. The Notifiable Data Breaches scheme has its own thresholds and its own regulator.
None of this is hard. It is just specific, and it needs to be read rather than assumed. Part two covers privacy and data location, and part five covers the consumer law and store rules that turn out to be product decisions rather than paperwork.
Small teams can now do what departments used to
The genuinely new thing about building software in 2026 is not any single tool. It is the accumulated effect of managed infrastructure, good open source and capable coding assistants on what a very small team can hold.
A two-person company can now run automated deployments, infrastructure defined as code, dependency scanning, error monitoring and a static site with a global edge cache, without hiring anyone to operate any of it. Work that needed a platform team in 2015 is a configuration file and a pipeline today.
That shifts the bottleneck. It is no longer how much you can build; it is how much you can support, explain, bill for and keep secure with the people you have. We would rather run two products properly than six badly, and the limit is not the engineering.
The advantages nobody mentions
Three things about building here are quietly useful.
Customers can reach you. An Australian product with Australian support answered in Australian business hours is competing against overseas software with a help centre and a chatbot. That gap is worth more than a feature.
Trust is a differentiator. Australians ask where their data is held, and they are right to. Being able to answer with a region name rather than a marketing phrase is a real advantage, and it is cheap to earn.
Being small is legible. A customer can understand who we are. The registered entity, the ABN and the people behind the software are all published, and every product says who to email. That is not a compliance exercise. It is the thing that makes a stranger willing to put their credit card into a subscription from a company they have never heard of.
What this series covers
The five pieces that follow are each about one part of the job, written from what we actually do rather than what we would recommend in the abstract.
- Where your data lives — the Privacy Act, cross-border disclosure and picking a region.
- Designing for distance — latency, edge delivery, offline-first and the time zone mess.
- What it costs to run — the cloud bill, the traps and the discipline that keeps it small.
- Compliance is product work — consumer guarantees, store rules, tax and accessibility.
- Shipping with a small team — the pipeline, the boring choices and where AI actually helps.
None of it is advice for your circumstances. It is what we have found, from Brisbane, running two subscription products that have to pay for themselves.