It usually starts with a workaround. The scheduling tool almost fits how you book jobs, so someone keeps a side spreadsheet to cover the gap. Then the spreadsheet gets a second tab, then a macro, then a rule only Dana understands. Somewhere around the fourth subscription that does most of the job but not all of it, the thought lands: maybe we should just have something built.
Sometimes that's the right call. Most of the time it isn't, and getting the decision wrong in either direction is expensive — one side drowns in subscriptions and duct tape, the other maintains a half-finished system that ate the budget. The line between them is more visible than people think.
Buy first — that's the honest default
Off-the-shelf software exists because thousands of businesses share the same problems. A subscription to an accounting package or a CRM splits the cost of a full engineering team — developers, security patches, uptime monitoring, support — across every customer. No custom build competes with that for a problem lots of companies have.
So if the need is invoicing, payroll, email, file storage or standard project tracking, buy the mainstream product, configure it properly and move on. (Choosing between the two big office suites is its own decision — see Microsoft 365 vs Google Workspace.) The moment to think about building is not when a tool annoys you. It's when the signs below start stacking up.
When buying stops working
The spreadsheet that runs the company
It started as a list. Now it's a database with no backups, no access control and one employee who understands the formulas. When that spreadsheet schedules your crews or prices your quotes, it is load-bearing — and a spreadsheet is a terrible thing to load. If Dana leaves or the file corrupts, part of the company stops. That's a real build signal, because what you'd be replacing isn't software you bought; it's software you accidentally wrote.
Per-seat pricing at real headcount
SaaS pricing is per person per month, and it's designed to feel small. Multiply the seat price by your actual headcount, then by five years, and set that against a build. For ten people the subscription nearly always wins. At fifty or a hundred seats on a tool where you use a fraction of the features, the arithmetic can genuinely flip — especially for internal tools, where you only ever needed one workflow.
The workflow no product matches
Most software assumes you work the way most companies work. If your process genuinely differs — and sometimes that difference is exactly why customers pick you — every packaged tool will fight you, and bending to fit it sands off what made you distinctive. When the workflow is the competitive advantage, custom software is how you keep the advantage.
Integration duct tape
Count the places where a human re-keys data from one system into another, or where a chain of automations shuttles CSV files between products that were never meant to meet. A little glue is normal. When the glue needs its own maintenance rota and snaps every time a vendor changes something, you're already paying custom-software money — in wages and errors — without getting custom software.
What building actually costs
A build quote is a start price, not a total. Custom software is less like buying a van and more like taking on a small permanent payroll: after launch there's hosting, security updates, libraries going stale, browsers and operating systems moving underneath, and the changes your own business keeps generating. Software nobody maintains doesn't stay finished — it decays quietly until it fails loudly.
So budget two lines: the build, and a yearly line for keeping it alive. What sets the size of both is scope — how many screens, how many integrations, whether outside customers log in. They're the same forces that set the cost of building a mobile app. If you already pay for ongoing IT, supporting the new system belongs in that conversation — here's what managed IT services cost in 2026.
The middle path most businesses skip
Between suffering with the packaged tool and commissioning a build sits a wide, cheap middle: make what you already have fit better. Most businesses run their software on default settings. In rough order of cost:
- Configure properly. Custom fields, templates, roles and automations already exist inside the products you pay for. An afternoon of setup fixes a surprising share of "this doesn't fit us".
- Integrate what you have. Most business products can talk to each other through their APIs. A small piece of connecting code can end the re-keying without replacing anything.
- Build only the missing piece. Keep the accounting package and the CRM, and build the one thing nothing sells — the customer portal, the quoting tool, the dispatch board. Smaller build, smaller maintenance, and the boring parts stay someone else's problem.
Six questions that predict whether a build succeeds
Ask these before you talk to any developer. Projects rarely fail in the code; they fail in the answers nobody wrote down.
- Which single process does version one replace? If the answer is a list, the scope hasn't been examined. Successful builds start narrow.
- What does version one deliberately leave out? A plan with nothing cut is a plan nobody has stress-tested.
- Who owns it internally? One named person who answers questions weekly and says no to feature creep. No owner, no project.
- Where does the existing data go? Ten years of spreadsheet history has to be cleaned and migrated, and that is often a project of its own.
- What does doing nothing cost? Put a yearly figure on the wages, errors and lost jobs of the current mess. That's the number the build has to beat.
- Who maintains it in year two? If the answer is a shrug, stop here.
Red flags when you're choosing a developer
The quality of a dev shop shows before any code is written. Slow down when you see:
- A price without discovery. Anyone quoting a firm figure from a paragraph of description is guessing, and you'll pay for the guess in change orders.
- Yes to everything. A good developer argues with you. If nobody asks what happens when a customer cancels mid-booking, nobody is thinking about your edge cases.
- Silence about maintenance. A proposal that ends at launch day is a plan for abandoning you at launch day.
- Vague ownership. If the contract doesn't plainly say the code, accounts and data are yours, assume they aren't.
- All the money up front. Milestones tied to working software you can actually try protect both sides.
Ownership and the handover test
Insist, in writing, that you own the source code, and that the hosting, domain and every third-party account are registered to your business — not the developer's. Repository access and documentation are deliverables, not favours. Then apply the handover test: if this shop vanished next month, could another competent developer pick the system up from what you hold? If not, you don't own software; you have a subscription with extra steps, and the renewal terms are whatever the shop decides later.
Getting a straight answer on your own case
Koadi builds custom software — booking systems, scheduling, customer portals, internal tools — and the scoping is the honest kind: discovery first, and if the right answer is a product you can buy, that's the answer you get. Projects are scoped and quoted end to end, then supported afterwards. For the smaller jobs — connecting two systems, rescuing the load-bearing spreadsheet — post the problem free, set a fixed price or take bids from vetted technicians, and payment sits in escrow until you approve the work. Remote help covers every US state; on-site is there when hands are needed.