There is a pattern in custom software development that we see over and over: an organization gets a proposal for a platform build, and the proposal is thorough, but only about the build itself. It covers tech stack, milestones, deliverables, and the timeline. What it says nothing about is what happens after launch. No hosting estimates. No infrastructure costs. No maintenance plan. No line item for what it costs to keep the lights on once the dev shop moves on to their next engagement.
Build price gets all the attention. But price is rarely the real problem. The real problem is the hidden costs that nobody has surfaced: what the platform will cost to run, maintain, and support for every year of its life.
After the Final Payment
Most development proposals scope the build. They describe what gets built, how long it takes, and what it costs. Sometimes that engagement ends at launch, maybe with a brief warranty period, and the client assumes the final invoice is the last check they will write. Nobody is being dishonest, but the full picture is rarely in the proposal.
The build is the down payment. Ownership is the mortgage. And most dev shops sell houses without mentioning property taxes, insurance, and the ongoing maintenance.
Sometimes the shop genuinely has not thought about it, which is arguably worse. Sometimes the omission is strategic. Either way, the client is the one who pays for the gap.
What Ownership Actually Costs
Total cost of ownership for a custom software platform goes well beyond the build. The costs that show up after launch are predictable, but only if someone takes the time to predict them.
- Hosting and infrastructure is the most obvious one. A platform running on AWS, GCP, or Azure has a monthly bill that might scale with usage. That bill at launch with 100 users looks nothing like the bill at 10,000 users. Both numbers matter, and a responsible partner should estimate growth expectations accordingly.
- Third-party services add up quietly. Email delivery (SendGrid, Postmark), SMS notifications (Twilio), authentication (Auth0), file storage (S3), error tracking (Sentry), monitoring (Datadog), search (Algolia). Each one has a free tier that works during development and a volume-based pricing model that kicks in after launch. A platform with seven integrations can easily carry $500 to $2,000 per month in third-party costs alone, depending on scale.
- Maintenance is not optional. Dependencies need updating. Security patches need applying. Framework versions reach end of life. SSL certificates expire. Database performance degrades as data grows. None of this is glamorous, and none of it can be ignored. A reasonable estimate for ongoing maintenance on a mid-complexity platform is 15 to 25 hours per month of developer time, whether that comes from an internal team or a retained partner.
- Support and incident response is the one that catches people off guard. Something will break: a third-party API will change without warning, a user will find a bug that only manifests with a specific browser. The question is not whether this happens; it is who responds and how fast. If you have not budgeted for on-call support or at least a retainer with your development partner, the answer is "whoever is available, eventually," and eventually can turn into lost revenue.
Architecture Is a Financial Decision
The right architecture is the one that solves the problem, at the appropriate scale, without introducing complexity.
Every technical decision in a software build is a financial decision wearing a technical disguise. Kubernetes or a single server. Microservices or a monolith. Multi-cloud or a single provider. Each choice has implications for the team you will need, the tools you will pay for, and the complexity you will manage for the life of the product.
Simpler is not just cheaper to build. It is cheaper to own. A well-architected monolith on a managed platform like Render or Fly.io can serve tens of thousands of users for a fraction of the cost of a Kubernetes deployment, and it can be maintained by a smaller, less specialized team. The right architecture is the one that solves the problem at the appropriate scale without introducing complexity you will pay for every month going forward.
This extends to the tech stack itself. If you build a bespoke platform on a modern stack (Node, Next.js, serverless functions, cloud infrastructure), who is updating dependencies in 18 months? That is a hiring decision disguised as a technology decision. The stack your dev shop prefers may not be the stack your organization can maintain, and a good partner will raise that question before writing a single line of code.
Build vs. Buy
Sometimes the honest answer is "do not build this." A $50K per year SaaS platform that covers 80% of your needs might beat a $300K custom build that covers 100% but costs $60K per year to maintain. The math is not complicated, but the conversation rarely happens because the firm writing the proposal has a financial incentive to build.
This is where alignment matters. A consultancy that raises the build vs. buy question before discovery, that walks a client through what off-the-shelf options exist and where the gaps are, is a consultancy that is optimizing for the client's outcome rather than their own revenue. The build vs. buy analysis should happen before the proposal, not after the client sees a number that makes them uncomfortable.
For organizations without a dedicated development team, this is especially critical. A custom-built platform requires ongoing technical stewardship. If you do not have (and are not planning to hire) the people to provide that stewardship, you are building a dependency, not an asset. Sometimes the right answer is a managed platform with an integration layer, not a ground-up build.
Who Runs This After You Leave
This question hits hardest for organizations without an in-house development team. Startups that contracted out their MVP. Small businesses that funded a custom platform. Nonprofits that used grant money for a one-time build. In each case, the engagement ends and the org is left holding software that needs ongoing care from people they do not employ.
The dynamics vary but the result is the same. A startup burns its seed round on the build and has nothing left for maintenance. A small business approves a one-time project cost without realizing it will become a permanent line item. A nonprofit secures grant funding for the capital expenditure but has no budget for the monthly costs to keep the platform running. In every case, someone approved a project without understanding they were also approving an increase to opex.
Within a year, dependencies are out of date. Within two, security vulnerabilities go unpatched. Within three, the platform is a liability. The org either finds money to maintain it, finds a new partner willing to do triage work, or quietly lets it decay. None of those outcomes are what anyone intended when the project was approved.
A good development partner surfaces this reality before the project starts. That might mean designing a simpler architecture with lower ongoing costs. It might mean budgeting a maintenance retainer into the project plan itself. It might mean recommending a managed platform instead of a custom build. Whatever the path, the conversation needs to happen before the first line of code is written, not after the money runs out.
What to Ask Before You Sign
If you are evaluating a development proposal, especially as an organization without a deep technical bench, some questions will tell you whether your potential partner is thinking long-term or just about the build.
Before you sign, ask your development partner:
- What is the monthly cost to keep this running?
- What breaks if nobody touches the codebase for six months?
- What does year-two support look like, and what does it cost?
- Can our team realistically maintain this stack, or do we need ongoing support?
- What if we need to switch vendors?
- Which third-party services are in the stack, and what do they cost at our expected volume?
- Is there a simpler architecture that would cost less to own, even if it costs more to build?
If the answers are vague, if the response is "we will figure that out later" or "maintenance and support available upon request," that is a signal. Not necessarily that the firm is bad, but that they are not thinking about your problem the way you need them to.
A Conversation Worth Having
We are not arguing that every dev shop is hiding costs. But the industry has a structural incentive to scope builds and leave ownership as someone else's problem. The proposal process rewards specificity about what gets built and vagueness about what happens next. Clients, especially those without technical leadership, don't know what to ask because they don't know what they don't know.
The fix is straightforward. A good proposal includes a total cost of ownership estimate alongside the build estimate. It covers hosting at the current and projected scale. It lists third-party services and their costs. It describes what maintenance looks like. It addresses who will do that maintenance and what happens if the engagement ends. It raises the build vs. buy question, honestly, even when the honest answer is "maybe you should not build this with us."
That is a conversation worth having.
If you are evaluating a development proposal and want a second opinion on total cost of ownership, build vs. buy, or long-term sustainability, we can help. Get in touch, and we will give you an honest assessment.
