The wrong reasons to build custom software
Every year we get inbound requests from businesses that want to build custom software and, on closer inspection, do not need to. The pattern is familiar. A founder is frustrated with an off-the-shelf tool. The current system does not do exactly what they want. They believe a custom-built solution would solve the frustration. They have not fully evaluated the cost of building, owning and maintaining that custom solution over time.
Custom software is expensive. Not just in the initial build. In the maintenance, the security patches, the framework upgrades, the browser compatibility, the team you need to support it forever. If an existing SaaS tool covers eighty percent of what you need, and you can adapt your process to the twenty percent gap, that is almost always a better decision than building your own. The economics of buy versus build have shifted dramatically in the last decade because the quality of off-the-shelf tools has improved so much.
That said, there is a legitimate set of problems where custom software is the right answer. This post walks through how to identify those problems, how to scope the build, how to choose a team, and how to maintain the system after launch. It is drawn from the custom systems we have shipped for clients across manufacturing, healthcare, education, agri-tech and financial services.
When custom is actually the right answer
Custom is the right answer in a small set of well-defined situations.
Your workflow is genuinely unusual. Not a minor variation on standard ERP or CRM patterns. A workflow shaped by domain-specific constraints that no vertical SaaS product exists for.
The workflow is core to your business. If the process is what makes you different from your competitors, running it on the same generic tool everybody else uses is a strategic mistake. Custom software here is an investment in defensible advantage.
You have hit real ceilings on off-the-shelf. You have already tried the two or three market-leading tools in the category. You have used them for at least six months. You have documented the specific ways they fall short. And the workarounds have started to cost more time than the tool saves.
You have scale that justifies the investment. Custom software is rarely worth building for a team of five. It is often worth building for an operation with fifty or five hundred people whose productivity depends on the workflow.
If you cannot check at least three of those boxes, keep buying off the shelf and negotiate harder on the price.
Scoping: the phase that decides everything
Scoping is where most custom software projects succeed or fail. A well-scoped project can be delivered by an average team. A badly-scoped project cannot be delivered by any team.
The scoping process we run with every custom software client has three phases.
Discovery. Two to five days of interviews with the people who will actually use the system. Not just the leadership. The operators, the front-line staff, the folks whose job the software is meant to make easier. What is the current workflow. What breaks it. What would make it faster. What are the edge cases. What are the exceptions the current tool does not handle. Every custom system is built on a foundation of specific, real-world detail, and discovery is where you collect that detail.
Definition. From the interviews, we produce a written specification — user roles, key workflows, data model, key screens, integrations, non-functional requirements. Not a wireframe. A written document a non-technical stakeholder can read and argue with. The specification is what everybody agrees on before building starts, and it is the reference for scope negotiations later.
Estimation. Only after the specification is agreed. Any estimate produced before the specification is a guess and will be wrong. The estimate includes the initial build, a launch buffer for the inevitable surprises, and a plan for ongoing maintenance after launch.
The technology decision
For most custom internal software today, the right stack is one of a small handful of options. A modern JavaScript or TypeScript framework on the front end — React with a full-stack framework like Next.js or TanStack Start, or SvelteKit for smaller applications. A modern backend — Node, Python or Go — running on managed infrastructure. A managed Postgres database. A managed authentication provider. Cloud object storage for files. A serverless deployment model that scales down to zero when nobody is using the system and scales up automatically when they are.
Two things to avoid. Bleeding-edge technology choices for internal software. You are not building a public product where a novel framework might attract engineers. You are building a system that has to run for five years with minimum drama, and boring, battle-tested choices are dramatically cheaper to maintain.
Second, avoid the temptation to over-engineer for scale you do not have. A workflow used by fifty people does not need microservices, Kubernetes, event streaming and horizontal sharding. It needs a well-organized monolith on a managed platform. When you have grown to the point where the boring architecture starts hurting, you will have the resources to break it apart. Until then, boring is a feature.
Choosing a build partner
The considerations for choosing a custom software partner are similar to the ones for choosing a mobile development partner, with a few extras.
Ask for references from projects that are three or more years old. Anybody can ship a project that looks good at launch. The real test is whether the system is still running smoothly three years later, or whether it has been rebuilt from scratch because the original code was unmaintainable.
Ask how they handle ownership of the code. You should own the source code. You should own the deployment infrastructure. You should be able to hire a different team to maintain the system if the relationship ends. Any arrangement that traps you with a specific vendor is a bad arrangement long term.
Ask how they handle security. Custom systems handle real customer or business data. Ask about how they handle authentication, authorization, data encryption at rest and in transit, backup and restore, secret management, and dependency vulnerability patching. If the answer is vague, keep looking.
Ask how they handle the handover to your internal team. At some point, the folks who built the system are going to be less involved. Ask what the documentation looks like, whether the code has tests, and whether a new engineer could ramp up on the system inside a week. If the answer is "yes, we will train them," but you cannot see any actual documentation, the answer is really no.
Launching: the part most people underestimate
Launching a custom system is not flipping a switch. It is a coordinated migration from whatever the team was using before to the new system. In most cases, that migration is more disruptive than the team expected and has to be managed carefully.
Plan the migration in phases. Not all users on day one. A small pilot group. Then a broader rollout. Then a complete cutover with a clear window during which the old system is still available in read-only mode in case something is missing from the new one.
Plan the data migration in advance. Getting historical data out of the old system, cleaned, and imported into the new one is often the single hardest technical task in the launch. Do not leave it until launch week.
Plan the training. Every new tool is initially harder than the tool it replaced, because the team knows the old tool by muscle memory and has to consciously think about the new one. Great training — recorded videos, live sessions, cheat sheets — dramatically reduces the productivity dip during the transition.
Maintenance: the permanent line item
A custom system is not a project. It is a product. It requires ongoing engineering time for the rest of its life. Bug fixes as edge cases surface. Small feature additions as the business evolves. Framework and library updates every quarter. Security patches. Browser and operating system compatibility as the world moves on.
The rule of thumb we use is that annual maintenance on a mature custom system runs about fifteen to twenty percent of the original build cost. Some years it is less, some years — when a major framework release forces a coordinated upgrade — it is more. Budget for it as a permanent line item. Custom systems that go unmaintained visibly rot within a couple of years and eventually have to be rewritten from scratch, which is far more expensive than sustained maintenance would have been.
The internal team you need
At some point, every organization running a custom system needs an internal engineering presence. Even if most of the ongoing work is outsourced, you need at least one internal person who knows the system well enough to make small changes, evaluate vendor proposals, and coordinate incidents. Without that person, the vendor becomes a single point of failure and every small change becomes a slow, expensive negotiation.
That internal person does not need to be a full stack ninja. They need to be a competent generalist who understands the specific system, has the credentials to change it in an emergency, and speaks the vendor's technical language well enough to keep them honest.
When to sunset
Every custom system eventually gets replaced. The question is when. The right answer is usually driven by one of three triggers. The workflow it supports has fundamentally changed and adapting the existing system would cost more than rebuilding. The framework it is built on has been abandoned by its community and updates have become impractical. Or a new off-the-shelf tool has emerged that now covers what only custom could cover five years ago.
Do not sunset because the system feels old. Systems that work should be maintained, not replaced on aesthetic grounds. Do sunset when one of the three triggers is real, and then plan the replacement with the same discipline you used for the original build. Custom software done well is a strategic asset. Custom software done casually is a liability. The difference is almost entirely in the discipline of scoping, building, launching and maintaining. Every one of those steps rewards seriousness and punishes shortcuts.
