More customers, more revenue. On the dashboard, growth always looks good. But there is one number almost nobody tracks that determines whether that growth is sustainable: what it costs to serve a single customer. If that number grows along with your revenue, you are working harder for the same result. If it grows more slowly, your product actually becomes more profitable as you scale.
That difference is not made in the accounts. It is made in the architecture, often months earlier, at a moment when nobody was looking at it yet.
Short answer
- Sustainable growth means the cost per customer or per transaction falls or stays flat as you scale.
- The FinOps practice calls this cloud unit economics: total infrastructure cost divided by the units of value delivered.
- Pick one unit that fits your product: cost per customer, per transaction, per ride, per analysis or per model call.
- Without measurement you discover too late that a tier loses money. A tier that costs 7.20 to serve and brings in 8 leaves nothing for support and engineering.
- Cost is an architecture question: caching, queues, data storage and how you structure AI calls determine the bill.
- One metric can hide an expensive subsystem. Add a second metric only when it supports a different decision.
What cloud unit economics means
Cloud unit economics translates technical cost into the language of the business. Instead of one large monthly figure you look at what a single unit of value costs. The formula is simple: attributed infrastructure cost divided by the number of units delivered.
The craft lies in choosing the right unit. For a product that mainly handles requests, "cost per request" makes sense. For a subscription product, "cost per customer" is better. For an analysis platform it is "cost per analysis". For AI work, "cost per model call" or "cost per token" is the most direct.
The FinOps Foundation, the professional body behind this practice, distinguishes between business metrics such as cost per customer and efficiency metrics such as cost per request. The first tells you whether your business model holds up. The second tells you whether your engineering is efficient. You usually need both, but for different decisions.
Why this is more than a financial exercise
The tempting thing about unit economics is that it produces a number. The dangerous thing is that a number only has value if someone uses it to change something. A measurement that disappears into a report is administration.
Where it really does something is at the intersection of engineering and commercial. When you know that serving one customer costs three euros in infrastructure, you can price with confidence instead of with a feeling. When you know that one specific feature causes most of your bill, you can decide whether that feature is worth it. And when you know that your cost per customer rises as you grow, you know there is an architecture problem before it shows up in your margin.
Companies often discover this too late. Picture a SaaS business that charges 8 per month for an entry tier and later finds out that serving a customer on that tier costs 7.20. Almost nothing is left for support, sales or development. Adjusting the price fixes it, but the number could have been known months earlier.
Cost is an architecture question
It is easy to see cloud cost as an invoice you try to reduce after the fact. In practice it is determined by the decisions you make while building. How you store data, whether you cache, whether you put work in queues instead of running it synchronously, how often you call a model and whether you do so cleverly: all of it determines the bill.
A few examples. A list page that fetches every record from the database on every view costs nothing at ten users and a lot at ten thousand. An AI feature that calls a model on every page request instead of storing results scales linearly with your traffic. A system that keeps all raw data forever instead of summarising it grows with time without giving you anything back.
None of these things are wrong at the moment you build them. They are wrong at the moment you scale and nobody has revisited them. That is why cost-aware building is not a saving you make afterwards. It is a property of the architecture.
From measuring to steering
The practice starts with attributing cost to components. Without tagging and a cost hierarchy you do not know which part of the bill belongs to which feature. That is why many teams have a total invoice and no idea where the money goes.
Start small. Pick one unit, measure it consistently and keep the measurement the same as you grow. Add a second metric only when it supports a different decision. A company measuring cost per active user while engineering watches requests and background jobs is measuring two things and steering neither.
For AI and machine learning work there is one more thing: alongside cost, look at the quality and speed of what you deliver. Cost per token without regard for accuracy or latency can reward a cheap solution that drives users away. The measurement should therefore always say something about value, not just about spending.
Conclusion
Sustainable growth is not more revenue with more cost. It is delivering more value at the same or lower cost per unit. That only works if you know what a unit costs, if you use that knowledge while building and if your architecture grows with your customers instead of trailing behind them.
Want to know what serving one customer or one transaction in your product actually costs? GitCity is happy to look at the architecture, the infrastructure and the business model behind it with you. Get in touch for a first, no-obligation conversation.