Custom software is a significant investment, and most of the time the right answer is buying something that already exists. But there are specific situations where off-the-shelf software genuinely can’t do the job, and recognizing those situations early saves a lot of money in both directions.

The Default Should Be Buy, Not Build

I’ll say this plainly even though I build custom software for a living: most businesses should exhaust the options for buying or licensing before commissioning a custom build. The software industry has produced good tools for most standard business workflows. If what you need is CRM, accounting, project management, HR, or standard e-commerce — buy it. The ecosystem, support, and ongoing development you get with established software is hard to replicate.

The comparison of custom vs. off-the-shelf software lays this out in more detail if you want the full framework.

Signals That Justify a Custom Build

Your Workflow Has Logic That No Product Handles

Not ‘our workflow is a little different’ — most workflows are a little different and can be adapted. The signal is: you’ve evaluated the available tools and the core logic of how your business operates genuinely can’t be configured into them without breaking how you work. Regulatory-specific industries, highly specialized services, or businesses with pricing or scheduling logic that’s genuinely complex often hit this wall.

You’re Doing Manual Work to Bridge Software Gaps

If your team spends time every day moving data between systems by hand, re-entering information, or doing steps that a system ‘should’ handle automatically but doesn’t — that’s a cost. Quantify it: hours per week times average hourly rate times 52 weeks. If that number is larger than the cost of a custom build amortized over three years, the math probably works. If it’s not, it probably doesn’t.

You Have a Genuine Competitive Advantage to Protect or Build

If your pricing model, your service delivery process, or your customer experience depends on something proprietary, putting it inside a platform you don’t control is a risk. Software vendors discontinue features, raise prices, change APIs, and get acquired. If the capability is core to how you compete, owning the software gives you control you can’t have otherwise.

The Integration Tax Is Too High

Some businesses are running four or five platforms and paying to integrate them with tools like Zapier or custom API integrations. At a certain point the total cost of licensing, integration maintenance, and workarounds exceeds the cost of a single purpose-built system. This threshold is higher than most people estimate, but it’s real.

You’re in a Niche the Software Market Hasn’t Served

There are entire industries — specialty contractors, specific healthcare niches, unusual professional services — where the available software is genuinely bad because the market is too small for major vendors to care about. These are legitimate candidates for custom builds.

Signals That Don’t Justify a Custom Build

  • ‘We want our logo on it’ — branding is not a reason to build software
  • ‘We don’t like the interface’ — interface preferences don’t justify five-figure builds
  • ‘We want to own our data’ — you can get data portability from most SaaS tools; this alone isn’t sufficient
  • ‘We want to sell it to others someday’ — this changes the entire economics and is a separate conversation

The Discovery Phase: How to Know Before You Commit

One of the riskier things a business can do is commission a full custom build without a proper scoping phase. Discovery — a structured process of documenting the workflow, mapping the data, identifying integrations, and producing a specification — typically runs 10-15% of total project cost and is the single best investment in making the rest of the project go well.

What a good discovery phase produces:

  • A data model that captures what the business actually needs to store and query
  • User flow documentation for each role that uses the system
  • A list of external systems that need to integrate and what data moves between them
  • The five or six most important reports the system needs to produce
  • A scope document specific enough that you can get a fixed-price quote, not just a time-and-materials estimate

Businesses that skip discovery tend to end up mid-project discovering that the requirements were underspecified, the integrations were more complex than estimated, or the data model needs to be restructured. The discovery cost is far less than the cost of those mid-project surprises.

Build-vs-Buy for Internal Tools Specifically

Internal tools — dashboards, admin interfaces, workflow automation, reporting systems — are a different category from customer-facing applications. The market for internal tooling has improved substantially: platforms like Retool, Appsmith, and Bubble can produce functional internal tools faster and cheaper than a full custom build. Before commissioning a custom internal tool, it’s worth evaluating whether one of these platforms handles the logic involved. They’re worth it until the business logic is complex enough that the visual editor becomes a liability rather than an asset — which happens more often than their marketing suggests, but less often than I used to think.

The no-code vs. custom software post covers this trade-off in more depth.

How the Scoping Conversation Actually Goes

When someone comes to me thinking they might need custom software, the conversation doesn’t start with pricing — it starts with the problem. I want to understand what’s breaking, what the workaround costs, and whether the workflow is stable enough that building against it makes sense. A workflow that’s changing every quarter is a poor candidate for a custom build; you’d be engineering against a moving target.

The questions I ask early:

  • What specifically doesn’t work about what you have now, and how do you know it’s a software problem rather than a process problem?
  • What have you already tried — what tools did you evaluate and why did they not fit?
  • Who uses this system, how many people, and what do they need it to do that nothing currently does?
  • What does the data look like — where does it live now, and what needs to move where?
  • What’s the consequence when the current workaround breaks or someone forgets a step?

Those questions usually surface either a clear case for a custom build or a reason to try one more off-the-shelf option first. Most of the time, an hour of this conversation is worth more than a written spec produced without it. The goal isn’t to sell a project — it’s to get to the right answer fast, even if the right answer is ‘not yet’ or ‘buy something else.’

What Custom Software Actually Costs

My custom software projects start at $9,500 for focused, well-defined builds. Complex applications with multiple user roles, integrations, and reporting are higher. A full website audit to understand what you have before deciding what to build is $1,500. Strategy time is $500/hr.

The ongoing cost after delivery matters too. A custom application needs maintenance: dependency updates, security patches, handling API changes from connected services, and occasional feature work as the business evolves. Budgeting 10-15% of the initial build cost annually for maintenance is a reasonable baseline. A system that never gets maintained eventually becomes a liability rather than an asset.

The decision framework here feeds directly into the broader question of what the software development process looks like once you’ve decided a custom build is the right call. If you’re at the evaluation stage, that’s the right next read.