What a Custom Node.js Platform Really Costs: Build, Launch and Three Years of Ownership

Someone has quoted you a number to build a custom platform. It is a large number, and you are trying to work out whether it is the right one. The uncomfortable answer is that the build figure — whoever produced it — is roughly half of what the platform will cost you over three years, and the missing half is not hidden. It is simply not what a statement of work describes.

This is the model we use when a client asks us to help them budget properly, including for work they might not give us.

Year Zero: The Build

The visible number. It usually breaks down more predictably than merchants expect:

• Discovery and architecture: 8–12% of build cost. Skimping here is the most reliable way to overspend later.
• Core application: 40–50%. The features in the brief.
• Integrations: 15–30%. Almost always underestimated — see below.
• Non-functional work: 10–20%. Authentication, permissions, rate limiting, file handling, transactional email, logging, error handling. Invisible in a demo, load-bearing in production.
• Testing and hardening: 8–15%.
• Deployment and infrastructure setup: 5–10%.

For a genuinely custom platform with real integrations, a realistic build lands between £120,000 and £450,000. Below about £80,000 you are buying an MVP, which is a legitimate thing to buy as long as everyone says so out loud.

Why Integrations Blow the Estimate

Integrate with the ERP is one line in a brief and three to eight weeks of work. The variance comes from things nobody can know at quoting time: whether the API is documented, whether a sandbox exists, whether the vendor's rate limits allow your volume, whether the data model matches, and whether the person who understands the system still works there.

Price integrations as a range with a named assumption for each, and re-price after a technical spike. An integration quoted as a fixed price before anyone has seen the API is a guess wearing a suit.

Year One: Launch and Stabilisation

The year most budgets treat as maintenance and which is nothing of the sort.

• Post-launch stabilisation: 15–25% of build cost. Real users find what testing did not, every time.
• Infrastructure: £500–£5,000/month depending on scale and redundancy.
• Third-party services: monitoring, error tracking, email delivery, search, authentication. £200–£2,000/month and it grows quietly.
• The change backlog: everything the business wanted but agreed to defer. Budget 20–35% of build cost for year one, or watch the platform fossilise the day it launches.

Years Two and Three: Ownership

Here is where custom software differs fundamentally from licensed software, and where most business cases quietly stop modelling.

Dependency Maintenance

A Node.js application carries a large dependency tree, and it does not hold still. Node's own release cadence retires versions on a schedule; frameworks and libraries publish breaking changes; security advisories arrive whether or not you have capacity.

Budget 5–10% of build cost annually simply to stay current. Skip it and you are not saving — you are accruing a debt that is paid in one lump, usually when a security advisory makes it urgent and the upgrade path has become a chain of five major versions.

Operations and On-Call

Someone answers when it breaks at 3am. That is a service with a price, and the price varies by an order of magnitude depending on what you actually need:

• Business hours, best effort: £1,500–£4,000/month
• Extended hours with a response SLA: £4,000–£10,000/month
• True 24/7 with a rota: £10,000+/month, because it requires enough people to make a rota humane

Decide what you need honestly. Buying 24/7 for a platform whose users are all in one timezone is waste; buying business hours for something processing overnight orders is a false economy you will discover in the worst way.

Continuous Development

A platform that does not change is a platform being outgrown. Most successful custom builds settle into 15–30% of the original build cost per year in ongoing development. This is not a failure of the original scope; it is what owning software looks like.

Key-Person Risk

The hardest line to price and the easiest to ignore. If one person understands the platform, you have a liability rather than an asset. Mitigating it — documentation, pairing, a second engineer who genuinely knows the system — costs money and is cheaper than the alternative. Price it explicitly, or you will pay it unplanned.

The Three-Year Picture

Take a £200,000 build. A realistic three-year total, with a moderate ongoing roadmap and business-hours support, lands somewhere around £520,000–£700,000 once stabilisation, infrastructure, dependency maintenance, operations and continued development are all counted.

That is not an argument against building. It is the number to compare against the alternative, which is the point of doing the exercise at all.

When You Should Not Build

We turn down custom builds regularly, and these are the reasons:

• A configurable product covers 80% of it. The remaining 20% almost never justifies owning everything forever.
• Nobody internal can own it. Custom software without an internal owner degrades into an unmaintained liability, however well it was built.
• The requirements are still moving. Build against a moving target and you will pay to build it twice. Prototype on something cheap first.
• The three-year total exceeds the value it unlocks. Do this arithmetic before the build starts, not during year two.
• It is not your differentiator. Build the thing that makes you money; buy the thing everyone needs.

The strongest case for building is the inverse: the software is the business, or it encodes a commercial advantage nobody sells off the shelf. That was the shape of both Hotelogix's hotel management SaaS and Dad.Live's platform — in each case the product was the thing, not a support function for it.

Questions to Put to Any Quote

1. What is excluded? The most informative question you can ask, and the answer tells you how experienced the team is.
2. Which integrations have you actually seen the API for? Anything unseen is an estimate, not a price.
3. What does the handover include — documentation, runbooks, architecture decision records, a working local environment for a new engineer?
4. Who owns the code, the repositories, the cloud accounts and the domains? Ask before you sign, not when you want to leave.
5. What is the support model after launch, and what does it cost?
6. What would you build differently if the budget were 30% smaller? The answer reveals what they consider essential.

If you want the three-year model built against your own requirements, that is work our Node.js and full-stack teams do before a project rather than during one, and our full-stack development practice covers the ownership side that the build quote does not.

Model It Before You Commit

Send us the brief and we will build the three-year picture — including the cases where the honest recommendation is to buy something instead. Talk to our team; we reply within a business day.