The real cost of custom development

Custom development is sold on flexibility. "We can build it exactly the way you need it." That sentence is true and incomplete. The complete version is: "We can build it exactly the way you need it, and you will own the maintenance, the upgrades, the security patches, the documentation, the dependency churn, the developer onboarding, and the eventual rebuild — for as long as the system runs."

The price tag in the proposal is the down payment. The recurring cost over the life of the system is usually two to three times the build cost. Most teams discover this in year three.

Custom is justified for three reasons, and only three:

• Differentiation. The thing that makes your product yours, that nobody can buy off the shelf, that customers come to you specifically for. The 5–15% of the surface area that defines the company.
• Integration. The glue that connects systems no SaaS will glue for you, usually because the combination is unique to your business.
• Constraint. Regulatory, security, sovereignty, latency requirements that genuinely rule out SaaS.

Everything else — auth, payments, search, email, CMS, analytics, error reporting, feature flags, support tooling, marketing automation — has a category leader you can buy. The custom version of any of these is more expensive in five years than the SaaS subscription will ever be, and it is worse than the SaaS at every turn.

The wrong way to ask the question is "can we build this?" The answer is always yes. The right way to ask it is: "is this the differentiation, the integration, or the constraint that justifies us owning the maintenance for five years?"

The five-year framing changes the math. A 30.000 DKK/year SaaS subscription is 150.000 DKK over five years. A custom replacement that takes two engineers three months to build at Danish rates is roughly 800.000–1.000.000 DKK in build cost, plus 15–25% per year in maintenance. The custom version is more expensive even if you only count engineering, and that's before you count the features the SaaS shipped while you were busy maintaining yours.

Every custom system reaches a moment, usually around year four or five, where the team looks at it and says "this would be easier to rebuild than to maintain." Sometimes that is true. Often it is the same trap that built the system in the first place — a preference for new code over the harder, less rewarding work of understanding what is already there.

A rebuild costs the original build, plus the migration, plus the parallel-running cost, plus the bugs that the original system had already fixed and the rebuild has not yet. The honest version of "let's rebuild" is "let's pay for this twice." Sometimes that is the right call. It should never be the default call.

When you do build custom, the cheapest version is the one that wraps existing tools rather than reimplementing them. Use the SaaS for the 80%. Build the 20% on top of it. Treat the SaaS as the operating system, not as the competitor.

• Use the auth provider's SDK; build only the user-facing flow that's specific to your product.
• Use the CMS; build only the content models and the renderers that are unique to your editorial workflow.
• Use the analytics provider; build only the schema that ties your events to your domain.
• Use the payment provider; build only the order model that ties payments to your business logic.