When business owners hear custom software, most picture something slow, risky and expensive: a long project, a big invoice and a system only one developer understands. That picture was fair a decade ago. It is out of date now, and the reason is a piece of jargon worth demystifying: the SDK.
SDK stands for software development kit. In plain English, it is a box of ready-made, heavily tested building blocks that a platform publishes so others can build on top of it. The payments company publishes one so developers can take payments without touching the terrifying parts. The accounting package publishes one so other systems can create invoices in it safely. Modern software is mostly assembled from these blocks, with custom work reserved for the part that is genuinely unique to you.
Why this changes the maths
Building from scratch meant reinventing solved problems: logins, payments, calendars, document handling, security. That is where the old horror-story budgets went. Building with SDKs means those solved problems arrive pre-solved, maintained by companies with far more engineers than any small project could afford.
The practical effect is that a custom internal tool, client portal or quoting flow is now a matter of weeks, not years. The custom part of custom software has shrunk to the part that should be custom: the way your business actually works. Everything underneath is standard, proven plumbing.
The case for off the shelf
Off-the-shelf software deserves a fair hearing, because for standard processes it is genuinely hard to beat. If your invoicing works the way most invoicing works, a mature accounting package will be better than anything built for you: cheaper, constantly updated and supported by someone else.
The honest rule: when your process is standard, buy standard. Off the shelf earns its keep wherever your business does something the same way thousands of other businesses do.
Where off the shelf quietly gets expensive
The cost appears when your process is not standard and you bend the business to fit the software. The workarounds are so familiar they become invisible: the spreadsheet that patches over what the system cannot record, the double entry between two tools that refuse to talk, the pricing structure flattened because the software only supports three tiers, the report assembled by hand every Friday because the built-in ones almost fit.
Each workaround costs a few minutes. Multiplied across a team and a year, they add up to real money, and they show up nowhere as a line item. That is the moment the maths flips: not when off the shelf breaks, but when the sum of the workarounds outgrows the cost of a system shaped around how you actually operate.
What a modern custom build looks like
Because of SDKs, a well-run custom project today looks nothing like the old caricature:
- Scoped in writing first, with a fixed price, after the workflows are mapped.
- Assembled from mature, proven components rather than written from a blank page.
- Integrated with the tools you keep, instead of demanding you replace them.
- Tested and signed off by you before anything goes live.
- Handed over with plain-English documentation, and owned by you at the end.
A worked example
Consider a trades business that quotes from a spreadsheet: prices in one tab, job history in another, and a partner who is the only person who knows how the formulas work. Off the shelf offers plenty of quoting tools, but none of them handle the two-visit jobs, the supplier price lists or the margin rules that make this particular business profitable.
A custom quoting flow for that business is not built from nothing. Logins come from one proven kit, document generation from another, the connection to the accounting package from a third. The genuinely custom part is a few screens and the pricing rules, which is exactly the part that makes the tool worth having. The result lands in weeks, does the job the spreadsheet could not, and does not collapse when the partner goes on holiday.
How to decide, in one afternoon
List the workarounds. Every spreadsheet that patches a gap, every piece of double entry, every report built by hand, every rule your team keeps in their heads because the software cannot hold it. Put a rough number of minutes per week beside each one.
If the list is short, your tools fit and you should keep them. If the list is long, you are already paying for custom software in wages and errors. You are just not getting the software. That is the point where a scoped, fixed-price build on modern building blocks stops being a luxury and starts being the cheaper option.
The jargon is doing less work than it seems. An SDK is a box of proven parts, and modern custom software is assembly plus judgement rather than heroics. Once you see it that way, the custom versus off-the-shelf question stops being about bravery and becomes what it always should have been: a comparison of costs you can actually count.