Field notes / Product Strategy
Custom software is not automatically better. Off-the-shelf software is not automatically cheaper. The right choice depends on where the real value lives.
Igniter Studio · 2 Oct 2026 · 5 min read
At some point, most growing businesses hit a software decision that looks something like this:
Do we buy something that already exists, or build something around the way we work?
There is no universal answer.
“Always buy” ignores workflows that genuinely need customisation.
“Build everything” is expensive and unnecessary.
The useful answer depends on what problem you are actually trying to solve.
If thousands of businesses have almost exactly the same requirement, there is usually a good reason to use an existing product.
Payroll is a good example.
So is accounting.
Email marketing.
Video calls.
Cloud storage.
These are mature categories with complex requirements that have already been solved repeatedly.
Building your own version would create enormous maintenance responsibility without creating much strategic value.
In these cases, buying software is not a compromise.
It is the sensible engineering decision.
Custom software becomes more interesting when the process itself is distinctive.
Imagine a company has developed a specialised way to:
That workflow might be part of why customers choose the business.
If the company has to distort the process to fit generic software, the tool may be limiting something valuable.
Custom software can preserve the workflow instead of forcing it into someone else's model.
Subscription price is only one cost.
Suppose Product A costs $300 per month.
That sounds expensive.
But a custom replacement costs $30,000 to build.
At first glance, buying seems obvious.
Now suppose Product A still requires two employees to spend ten hours every week fixing exports, reconciling records and preparing reports.
The comparison changes.
Likewise, custom software has ongoing costs that are easy to ignore:
A realistic decision considers the total cost of operating the workflow, not just the invoice.
Off-the-shelf products often solve 80% of a requirement brilliantly.
The question is what happens in the other 20%.
If the remaining 20% is minor inconvenience, buy the product.
If the remaining 20% contains the most important part of the business process, custom software may deserve serious consideration.
That distinction is important.
Missing dark mode is probably not strategic.
Being unable to represent the company's core approval workflow might be.
Build vs buy sounds binary.
In reality, many good systems do both.
You might buy:
and build:
This approach keeps commodity infrastructure with specialist providers while concentrating custom development on the parts that differentiate the business.
It is often the most sensible architecture.
Another useful question is:
How stable is the process?
If the team changes the workflow every two weeks, custom development may be premature.
You may still be discovering what the product needs to be.
Spreadsheets, low-code tools and manual processes can be excellent during that stage because they are cheap to change.
Once the process stabilises and the pain becomes clearer, custom software becomes easier to design well.
Building too early can encode assumptions that should never have survived.
Sometimes the decision is not primarily financial.
Control matters.
A business may need:
These can be legitimate reasons to build.
But control creates responsibility too.
If you own the system, somebody also owns its maintenance.
There is no free independence.
One of the simplest frameworks is to ask two questions.
How important is this capability to the business?
How well do existing products solve it?
If the capability is not strategically important and existing software solves it well:
Buy.
If it is strategically important and existing software solves it poorly:
Build becomes interesting.
The difficult cases are the middle.
That is where prototypes, integrations or partial customisation can help before committing to a large project.
This is one of the weakest reasons to commission custom software.
A $100 monthly subscription may feel annoying.
But spending $15,000 to avoid it gives you more than twelve years of subscription fees before maintenance is even considered.
Custom software should create value beyond avoiding a bill.
It should improve the workflow, enable something unavailable elsewhere, reduce significant operational cost or support a capability that matters strategically.
The opposite mistake also happens.
A business keeps stacking tools because custom software feels like a huge undertaking.
CRM connected to forms connected to Zapier connected to Airtable connected to another dashboard connected to a spreadsheet.
Eventually nobody knows which system is authoritative.
At some point, a smaller purpose-built application may actually simplify the technology rather than complicate it.
The useful question is not:
Is custom software better?
It is:
Where should we own the experience and where should we rely on existing products?
Buy the things that are already solved well.
Build the things that genuinely make the business work differently.
And when possible, connect the two.
That usually produces better software than treating build vs buy as an ideological choice.
Your next chapter starts here
Tell me what you’re working on. I’ll help you find a practical way forward.
Let’s talk about it