Buy software for commodity work, the things every business does the same way, like accounting, payroll and email. Build when the software would capture how your business works differently, when bought tools leave your team doing the rest by hand, or when your systems need to talk to each other. AI-assisted engineering has made custom software much faster and cheaper to build than it was a few years ago, so the line has moved. For most small businesses the answer is in the middle: buy the core system, build the edges.
The old rule of thumb was simple: never build what you can buy. For a small or mid-sized business, custom software meant a long project, a large invoice and a developer you'd depend on forever. That rule made sense when it was written. It's worth checking again.
What changed about building custom software?
The cost of writing software dropped.
AI-assisted engineering means a capable engineer now gets much more done in a day. Reading an old system to understand what it does, writing the code that moves data between two products, building a set of screens, writing tests, producing documentation: all of that is faster than it was a few years ago. Projects that once needed a team for months can now be handled by a much smaller one.
What didn't change is the hard part: knowing what to build. Understanding how your business actually runs, which exceptions matter, and what people will really use still takes time with the people who do the work. And software you own still needs looking after.
So custom software isn't free, and it isn't always right. But a lot of projects that didn't make sense in 2020 make sense now.
When should you buy software?
Buy when the work is the same for you as for everyone else.
Accounting, payroll, email, calendars, file storage, video calls: these are commodity functions. The vendors spread their costs across thousands of customers, keep up with tax rules and security patches, and integrate with everything. Building your own payroll system would be expensive, risky and pointless. Nobody chooses your company because of how you run payroll.
Buying is also right when the product fits your process with configuration, not custom code, and when you can get your data back out. If you're choosing between products, our guide to choosing business software without getting sold walks through how to compare them on your own terms.
When does custom software win?
Custom wins where your business is different, or where the products you've bought leave gaps.
- The process is how you compete. The way you quote, schedule, price or serve customers is part of why they choose you. Bending it to a generic product gives that away.
- Your team works around the tools. The purchased system does most of the job, and people fill the rest with spreadsheets, retyping and email.
- You pay a lot for a little. A large platform with per-user pricing, used for one narrow workflow.
- The problem lives between systems. No vendor owns the gap between your CRM, your ERP and your documents. Someone has to build the connection.
- You've outgrown a homegrown tool. An old database or spreadsheet that runs something important. We wrote about replacing a Microsoft Access database, which is often where this starts.
How do you decide, factor by factor?
| Factor | Favors buying | Favors building |
|---|---|---|
| How common the work is | Every business does it the same way | It's specific to how you operate |
| Competitive value | Nobody picks you because of it | It's part of why customers choose you |
| Fit | Works with configuration | Needs heavy customization or workarounds |
| Regulation and upkeep | Rules change often (payroll tax, compliance) | Rules are yours and change on your schedule |
| Integration | Has solid connectors to your other systems | The gap between systems is the problem |
| Users and pricing | Small team, predictable per-user cost | Per-user costs grow faster than the value |
| Ownership | Vendor roadmap is fine with you | You want to own the code and the data model |
| Support | You need a vendor's help desk | You have a builder or partner who knows the system |
If most of your answers land in one column, you have your answer. If they split, read the next section.
What is the middle path between building and buying?
For most small and mid-sized businesses, the best answer to build vs. buy is both, in a specific order: buy the core system, then build the edges. Use proven products for the heavy, common work, such as your ERP, CRM, accounting and email, because the vendors maintain them, keep them secure and spread their cost across many customers. Then build small, owned pieces where those products stop: the integration that moves orders from the CRM to the ERP without retyping, the report that combines data from three systems, the internal tool that fits the one workflow no product handles well, the archive of an old system's history. These pieces are where most of the daily friction lives, and they're now much faster and cheaper to build than they used to be. You keep the reliability of bought software and get the fit of custom software, without betting the business on a full rebuild.
That's the kind of work we do most: integrations and internal tools built inside the stack you already run.
What does it take to own custom software?
Owning software is a commitment. Plan for it up front.
Custom software needs hosting, security updates, occasional fixes when a connected product changes, and small improvements as your business changes. None of it is large if the software was built well, but it's not zero. Someone should own it on your side, even if a partner does the technical work.
Compare that honestly with what you'd pay to buy. Subscriptions also cost money every year, often rise with headcount, and come with their own upkeep: admin time, workarounds and the occasional forced upgrade. The question isn't whether owning software has a cost. It's which cost buys you more.
What should you ask whoever builds it?
Before any custom work starts, ask:
- Do we own the code? In a repository your business controls, with hosting in your own accounts.
- Is it documented? In plain language, so another developer, or your own staff, can follow what it does and why.
- Is it built inside our stack? Using the systems and common tools you already have, not a framework only the builder knows.
- What's the first piece that goes live? Something small and useful, so you see value before committing to more.
- What happens if you're not available? The answer should be "someone else picks it up," and the first three answers should make that true.
We give clients that answer by default. If you're weighing build vs. buy for a specific problem, in Cedar Rapids, Iowa City or elsewhere, see how we approach custom software and integrations.