A

Six months later, the cloud bill is three times what anyone expected. Two engineers are spending 40% of their time on operational work instead of features. A bad architectural decision from the early build is now costing two weeks every time anyone touches that part of the system. And nobody factored in what happens when a senior engineer leaves and takes six months of undocumented context with them.

The cost of building scalable software is not the developer hours. Developer hours are the most visible line item, which is precisely why they become the entire conversation. This post is about everything else — the costs that compound quietly until they don't.

The infrastructure bill will surprise you

Cloud providers make getting started cheap. They make staying cheap much harder.

The pay-as-you-go model feels efficient at the beginning. A small staging environment, a modest database instance, a single region. Then you grow, traffic increases, and the bill grows with it — sometimes faster than the traffic does. Some SaaS startups report spending over 40% of their revenue on cloud infrastructure during rapid growth phases. That's not a failure state. For many companies, that's just what scaling looks like if nobody's actively managing the spend.

The specific cost buckets that catch teams off guard:

Data egress fees. Moving data out of a cloud provider costs money. Data egress fees run from $0.01 to $0.09 per GB for transferring data out. At low volumes this is irrelevant. At high volumes — especially if your architecture moves data between services, regions, or providers frequently — this becomes a material line item. A distributed architecture that wasn't designed with data locality in mind can generate egress fees that dwarf the compute cost.

Unused and oversized resources. Flexera's 2024 State of the Cloud Report found that companies waste up to 32% of cloud spend on unused or underutilised resources. Early-stage teams rarely have dedicated people watching this. A developer provisions a larger database instance to fix a performance problem, solves the problem, and forgets to right-size it. Multiply this across 12 months and a growing team and the waste accumulates into a budget line that nobody owns.

Support tiers. The default cloud support plan is minimal. Premium support plans from major cloud providers run from $29 to $15,000 per month. Once you're in production and customers depend on your uptime, the free tier of support is rarely adequate. This cost usually gets added reactively — after the first serious incident where the free support response time wasn't good enough.

Multi-region and availability zone transfer costs. Building for high availability means running infrastructure across multiple zones. That introduces cross-zone data transfer costs. Not large per request, but they accumulate at scale, and most infrastructure cost models in the early build phase don't account for them.

None of these are reasons to avoid cloud infrastructure. They're reasons to model the full infrastructure cost before you commit to an architecture, not after.

Operational cost: the engineering time that doesn't build features

This is the cost that's hardest to see because it doesn't appear on an invoice.

Every system in production requires attention. Monitoring, incident response, dependency updates, security patching, performance tuning, backup verification, database maintenance, certificate renewals. This operational burden shifts engineering focus away from building product features — instead of innovation, teams spend hours managing infrastructure.

For a team of five engineers, losing 30% of capacity to operational work means you effectively have 3.5 feature engineers. This is a significant capacity reduction that affects product velocity, roadmap delivery, and competitive positioning. It rarely shows up in the post-mortem on a missed quarter.

The operational cost scales with architectural complexity. A well-structured monolith has relatively predictable operational overhead. A system with 25 microservices, multiple data stores, async message queues, and cross-region replication has operational overhead that requires dedicated attention — typically one or more Site Reliability Engineers, or a significant portion of senior engineering time. That headcount has a fully-loaded cost: salary, benefits, management overhead, onboarding time, and the opportunity cost of what those people would otherwise build.

We've seen Series A companies in Jakarta carrying three engineers whose primary function is keeping the existing system running rather than evolving it. That's not an engineering failure. It's what happens when infrastructure complexity outruns infrastructure investment.

The cost of an early architectural mistake

Some costs are front-loaded. This one is back-loaded, and it tends to be the most expensive.

An architectural decision made at month two of a build — which database to use, how to structure the data model, where to draw service boundaries, how to handle authentication — will be revisited many times over the life of the system. If the decision was right, those revisits are cheap. If it was wrong, they compound.

A concrete example: a marketplace built in Surabaya chose to store inventory state in a way that made sense for the product at launch. As the catalogue grew past 500,000 SKUs, the query patterns became impossible to optimise without changing the data model. Changing the data model in a live system serving active users required a migration strategy, a dual-write period, a reconciliation process, and six weeks of engineering time. The original architectural choice took two days. The correction took six weeks and introduced three production incidents.

McKinsey's research shows that short-term fixes — building isolated systems or adding functionality without integration — create a growing layer of indirect costs: the "hidden tax" of fragmented design.

The honest point here is that some architectural mistakes are unavoidable. You can't perfectly predict what your system will need to do at 10x current scale when you're building at 1x. What you can do is make the cost of correction lower: favour reversible decisions over irreversible ones, prefer standard patterns over novel ones, and invest in a data model review before you hit the scale at which the model becomes load-bearing.

Knowledge concentration: the cost nobody puts in a spreadsheet

Here's a category that almost never appears in a software budget conversation.

Every engineering team accumulates institutional knowledge — understanding of why certain decisions were made, where the edge cases live, what the undocumented behaviour of a critical service is, which database query will bring down the whole system if it runs at the wrong time. This knowledge lives in people's heads.

When a senior engineer leaves, that knowledge leaves with them. The replacement cost isn't just the recruiter fee and the months of salary to hire. It's the ramp-up time (typically three to six months before a new engineer is fully productive on a complex system), the incidents that happen during that ramp-up because the new person didn't know what the departing person knew, and the architectural decisions that get made with incomplete context.

A two-year-old startup in Jakarta lost their lead backend engineer in the middle of a database migration. Nobody else fully understood the migration script. They paused the migration for three weeks while the remaining team reverse-engineered the approach. Three weeks of engineering time on a non-feature-building task, triggered by one departure.

The mitigation is unglamorous: documentation, runbooks, architecture decision records, pairing practices, and code that's written to be read by a future engineer who has no context. These practices aren't free — they cost engineering time in the short term. They're significantly cheaper than the alternative.

Security and compliance: the cost that becomes a crisis

Building software that handles payment data, personal data, or health information in Indonesia means operating in a regulatory environment that's actively evolving. OJK has specific requirements for fintech players. PDPA-style data protection obligations are tightening. If you're serving customers in Australia, Japan, or Europe, you're operating in multiple regulatory frameworks simultaneously.

Compliance isn't a one-time cost. It's an ongoing one. Audit preparation, security assessments, penetration testing, data residency requirements that affect where infrastructure can run — these all have direct costs. The indirect cost is the engineering time required to build compliance-aware features from the start rather than retrofitting them later.

Building privacy controls into a system after the fact is significantly more expensive than building them in from the beginning. The same is true for audit logging, data retention policies, and access controls. The cost of getting this wrong — a breach, a regulatory finding, a data incident — is an order of magnitude higher than the cost of getting it right upfront.

This category is where working with engineering partners who understand the Indonesian regulatory environment, and the markets you're selling into, pays the clearest dividend.

Building a more complete cost model

When a CTO or technical founder is planning the cost of building scalable software, the spreadsheet should have more rows than "engineering team." A more complete model looks at:

Build-phase costs: Engineering (internal or partner), architecture design and review, infrastructure setup, security review, compliance assessment for the markets you're entering.

Operational costs (ongoing): Cloud infrastructure (compute, storage, networking, egress, support tier), monitoring and observability tooling, CI/CD pipeline and deployment infrastructure, security tooling, database costs at projected data volumes.

People costs beyond developers: DevOps or SRE capacity for operational management, technical leadership for architectural decisions, the cost of documentation and knowledge management practices.

Risk-adjusted costs: The probability-weighted cost of an architectural migration at 3x current scale, the cost of a security incident, the cost of a key engineer departure, the cost of a significant outage in terms of customer trust and revenue.

The last category is the one most founders skip. It's also the one that most often determines whether a company's infrastructure investment compounds or corrodes.

FAQ

Q: How much should a startup budget for cloud infrastructure beyond the development cost?

A: It varies significantly with architecture and traffic, but a useful starting heuristic for a Series A-stage company is to budget cloud infrastructure at 15 to 25% of your annual engineering payroll as a floor, then model upward based on data volume and traffic projections. More importantly, designate someone to own cloud cost optimisation before the bill grows — not after. The teams that manage cloud spend well do it proactively, with regular right-sizing audits and attention to unused resources.

Q: Is it cheaper to build scalable software or to start simple and scale later?

A: Almost always start simple. Premature scalability is one of the most expensive mistakes in software development. 74% of SaaS businesses overspend due to premature scaling. The pattern that works: build the simplest architecture that handles your current and near-term load, invest in the foundations that make future scaling cheaper (good data models, clean service boundaries, observability), and redesign when real constraints appear — not imagined ones.

Q: What's the most underestimated cost in building software for Indonesian startups specifically?

A: Two things tie for first place. The first is the cost of building compliance-aware infrastructure for a regulatory environment that's actively tightening — particularly for fintech and health-adjacent products dealing with OJK, BI, and emerging data protection requirements. The second is the cost of knowledge concentration in small engineering teams where one or two people carry critical system knowledge. Both are solvable. Neither is usually in the initial budget.

Q: How do you calculate the cost of technical debt?

A: The most useful frame is opportunity cost: for every engineer-week spent on technical debt remediation or working around a broken system, that's an engineer-week not spent on product features. Track it explicitly. If your engineering team is spending more than 15 to 20% of capacity on debt-related work — firefighting, workarounds, migrations of decisions made in haste — you have a debt problem that's worth quantifying and addressing deliberately rather than absorbing as background noise.

Q: When does it make sense to pay for an architectural review before building?

A: When the system you're planning to build will be difficult to change once live. This is almost always true for anything that handles financial transactions, has significant data volume projections, or will be built by a team that will grow significantly in the next 12 months. A proper architecture review typically costs a fraction of one bad architectural decision. It's one of the clearest ROI-positive investments available before a build, and one of the most consistently skipped.

The mistake we see most often isn't a company that spent too much on software. It's a company that budgeted for the visible costs, absorbed the invisible ones without tracking them, and eventually found themselves in an infrastructure situation that was costing far more than it needed to — in engineering time, cloud spend, operational burden, and slowed product velocity.

The full cost of scalable software is knowable before you commit. It requires asking better questions than "how much will the developers cost?" — and the answers are worth having early.