Picture the newest person on your team, three days in, asking a simple question. "Where do I log a new job?"
And you hear yourself say: "Okay, so first you put it in the scheduling tool. Then you copy the address into the spreadsheet. Oh, and don't use the notes field in the CRM, we use the other one. I'll send you the login for the invoicing thing."
If you have ever given that speech, you already know the real subject of the build vs buy software question. It isn't about technology. It's about whether your tools work the way your business works, or whether your people spend part of every day translating between the two.
This article is a walkthrough of how to make that call. We build custom software for a living, so you'd expect us to push you toward building. We won't. Plenty of the time, buying is the right answer, and we'll say so plainly. The goal here is that by the end you can look at your own tools and decide with a straight face.
Build vs buy software: what you are really choosing
Buying means subscribing to a product built for thousands of businesses. It's off-the-shelf software: you adopt its way of working, you pay monthly, and the vendor handles hosting, updates and security.
Building means commissioning software designed around how your business operates. You own the result, it does what you tell it to, and you take on the responsibility of paying for it up front and looking after it over time.
Both are legitimate. The mistake is treating one as the smart choice and the other as the vanity project. A bakery that commissions custom payroll software is wasting money. A company with a unique delivery process that squeezes itself into a generic tool is also wasting money, just in smaller pieces that are harder to see on a statement.
Here's the useful reframe. You aren't choosing between "software" and "no software." You're choosing where you want to adapt. With bought software, you adapt to the tool. With built software, the tool adapts to you. Neither costs nothing. The question is which adaptation is cheaper and less painful for your particular business, and that depends on where the work actually creates your money.
When buying is the right call
Let's start with the good news for the buy side, because it's a long list.
Buy when the task is a commodity. Payroll, email, calendar, video calls, basic bookkeeping, file storage, form builders. Everybody does these roughly the same way, and a product used by millions has been polished by millions. Building your own is like building your own electric grid.
Buy when you're still figuring out the process. If you started this quarter and your workflow changes every month, don't build around it yet. Use a flexible tool, learn what you actually do, then decide. Software cast in concrete around a process you haven't found yet is expensive to break.
Buy when the tool fits most of the way and the leftover gap is tolerable. Almost nothing fits perfectly. If the gap is a minor annoyance rather than a daily tax, live with it.
Buy when you don't have anyone to own the thing. Custom software isn't a one-time purchase, it's a small asset that needs a steward. If nobody on your side can make decisions about it and you don't have a builder you trust for the long run, a subscription that someone else maintains is safer.
Buy when the vendor's roadmap is going your way. Good products keep improving, and you get those improvements without lifting a finger. That's a real advantage that custom work doesn't have unless you keep investing.
If your situation looks like most of these, close this tab and go sign up for something. Seriously. The cheapest, fastest software decision is often the boring one.
The real cost of renting software
So why do we spend our days building instead? Because the cost of renting software hides in places that never show up on a subscription invoice. Here are the five we see most often.
Per-seat fees that grow with you
Most tools price per user per month. That feels reasonable at three people. Then you hire, you add a part-timer who needs access to just one screen, a contractor, a bookkeeper. Each seat multiplies across every tool in the stack, so a hire costs you not one license but five or six. Growth gets taxed at every step, and the better your business does, the more the stack costs.
Custom software usually isn't priced by the head. You pay to build it and then to host and maintain it. Adding the tenth user costs about the same as adding the second.
Workarounds that nobody counts
This is the big one. When a tool almost does what you need, your team invents a workaround. A color-coded spreadsheet beside the app. A naming convention. A checklist taped to a monitor. A recurring reminder to "remember to update the other system."
Each one costs a few minutes. Nobody tracks those minutes because they're spread across people and days. But add them up: a few minutes, several times a day, across everyone on the team, every working day of the year. That's a real number, and it's usually bigger than the subscription.
Data stuck in silos
Your customer's name lives in the CRM. Their invoice lives in the accounting software. Their project status lives in the project app. Their support history lives in your inbox. Ask "how is this client doing, all in?" and nobody can answer without opening four windows.
Silos also make decisions slower and worse. You can't see which kinds of clients are most profitable if the revenue is in one place and the hours are in another. We cover this in more depth in our piece on all-in-one business management software.
Features you pay for and never touch
Big products are built to appeal to everyone, so they carry hundreds of features. You use maybe a tenth. The rest still shapes the interface, still adds menus, still adds training time for new hires, and still shows up on the bill in the form of higher tiers.
Terms you don't control
The vendor can change pricing, retire a feature you rely on, restructure their plans, or get acquired by a company with different priorities. You can leave, but leaving means exporting your data and retraining your team, and the more your business runs through the tool, the harder that becomes. This is rarely a crisis. It's a quiet loss of leverage.
None of these appear as a line item. They show up as a business that works harder than it should.
The real cost of building
Now the honest part for the other side, because custom software has genuine downsides, and anyone who tells you otherwise is selling.
It costs more upfront. Subscription software spreads cost over time and lets you start small. Custom software asks for a bigger commitment at the start. What drives the number is scope: how many kinds of users, how many workflows, how many outside systems it has to talk to, and how polished the experience needs to be. Our Price Guide walks through those drivers so you can see what moves the cost up and down.
It takes longer to start. You can sign up for a subscription in an afternoon. A build takes weeks or months, depending on size. For something that is hurting you this week, that's a real cost.
You have to know what you want. A product on a shelf shows you what it does. A custom build starts with a blank page, and the quality of the result depends on how well the process was understood first. Good builders help you work that out, but it does require your time and your honest answers.
Someone has to look after it. Software ages. Libraries need updating, hosting needs watching, small changes come up every month. A custom system with nobody maintaining it slowly rots. Plan for ongoing care from day one, and ask any builder what that looks like before you sign.
Scope can wander. The classic failure is a project that grows by a feature here and a feature there until it's twice the size and half-finished. The fix is a clear scope, a phased plan and fixed pricing, so both sides know what "done" means.
You can end up with a builder problem. If one freelancer built everything and then vanished, you now own something nobody understands. Insist on owning the code, having it documented, and working with a team that will still be around.
Everything on this list is manageable. None of it is free. The point of listing it is that a fair comparison counts these costs honestly instead of comparing a subscription price to a fantasy. If you want those costs laid out side by side, our quick comparison of custom software vs off the shelf cost does exactly that.
A decision framework: seven questions
Here's the build vs buy software framework you can use on a napkin. Go through these in order and keep a rough tally of which way each answer points.
- Is this process how you make money, or just something you have to do? If it's central to what makes your business different, such as your quoting method, your delivery workflow or the experience your clients get, lean toward building. If it's a utility, lean toward buying.
- How often does the current tool force a workaround? Count them for one week. Daily workarounds point toward building. Occasional ones point toward buying.
- How many tools does one piece of work pass through? If a single client or job touches four or five systems, the handoffs are the cost. That points toward consolidating, which usually means building.
- What happens to your costs when you double in size? Add up what you'd pay in seats and tiers. If the number scares you, the per-seat model is working against you.
- Do your clients or partners need to see into your process? Portals, approvals, status updates and self-service are painful to bolt on to generic tools. If clients are part of the workflow, building gets more attractive. (We wrote about this in the benefits of a client portal.)
- Is the process stable enough to write down? If you can describe it clearly and it hasn't changed much in a year, it's ready. If it changes monthly, wait.
- Do you have an owner and a long-term builder? If yes, building is safe. If not, you need that settled before anything else.
If you get four or more answers pointing at "buy," buy. If you get four or more pointing at "build," have a serious conversation about it. If it's split, read the next section, because the split is exactly where the best answer usually lives.
Most owners who come to us don't want custom software. They want the tools to stop getting in the way.
Three businesses, three different answers
Frameworks are easier to trust when you watch them work. Here are three made-up businesses, clearly examples, run through the same questions.
The two-person bookkeeping practice. Their process is standard, their clients expect a familiar experience, and they have no one to look after a custom system. Every answer points at buying. The right move is a good subscription, a clean setup and a tidy folder structure. Spending on a build here would be a mistake, and any builder who says otherwise isn't being straight with them.
The regional home services company. Calls come in, jobs get quoted, crews get scheduled, invoices go out and customers want updates. They've stitched together four tools and a whiteboard. The quoting logic is theirs: it depends on materials, distance and crew size in a way no generic tool understands. Here the answers split. The sensible plan is to keep payroll and accounting rented, and build the quoting-to-scheduling flow that everything else hangs off.
The growing consultancy with a client-facing process. Every project involves approvals, file handoffs and recurring invoices, and clients keep asking for status updates. The process is how they win work, clients are part of the workflow, and the seat count is climbing. Almost everything points at building, probably starting with the part clients see.
Notice what these have in common. None of them started with "should we build software?" They started with "where does the work hurt?" and let the answer decide.
Mistakes we see on both sides
A few patterns show up often enough to warn you about.
- Buying the biggest tool because it has the most features. More features means more setup, more training and more things nobody uses. Pick the smallest tool that does the job.
- Building before writing the process down. If two people on your team describe the same workflow differently, software won't settle the argument. Sort that out first.
- Treating the subscription price as the whole cost. The tool is the cheap part. The time spent working around it is the expensive part.
- Treating the build price as the whole cost. Hosting, maintenance and small improvements are real, and a good proposal shows them up front.
- Skipping the exit plan. Whether you rent or build, ask how you'd get your data out. If the answer is vague, that tells you something.
The middle path: buy the commodity, build the core
The cleanest answer to the build vs buy software question for most businesses isn't a pure build or a pure buy. It's a hybrid.
Keep the commodity tools that do their job and don't touch how you win: email, calendar, payroll, file storage. Those stay rented. Then identify the one or two places where the work is genuinely yours, and build only those.
This works because the hard part of custom software is mostly about scope, and a smaller scope is cheaper, faster and safer. A phased approach looks like this:
- Phase one: build the single piece that causes the most pain. Often it's the place where information gets re-entered, or the client-facing part that currently runs on email.
- Phase two: connect it to the tools you're keeping, so data flows in and out without anyone copying it by hand. This is what integrations are for.
- Phase three: as it proves itself, absorb more of the neighboring work and retire the tools it replaces one at a time.
Each phase should stand on its own and deliver something useful. If you stop after phase one, you still have a working improvement, not half a building.
The hybrid also protects you from the biggest build risk, which is guessing wrong about the process. A small first phase teaches you what you actually need before you commit to the rest.
What it looks like when a business builds
We went through this ourselves, so we can give you a real example instead of a hypothetical.
Running Stack Mode used to mean a CRM, a proposal tool, a project manager, an invoicing app, accounting software and a client portal. Six tools. None of them talked to each other, every handoff was manual, and the experience for clients was scattered across email threads. We could have kept patching it, and for a while we did.
We decided to build one system around the life of a client: win the work, deliver it, get paid, look after their sites and keep them happy. That became StackOS, and it replaced all six tools with one login. Staff see a dashboard of what needs attention. Clients get a portal with progress, files, approvals and invoices. The books stay in sync with every invoice and payment. It runs Stack Mode every day.
That's the case where building was right. Our work is the process, no off-the-shelf product matched the way we deliver it, and we had the skills to own the result. We still rent plenty of tools. We didn't build our own email or our own video calls. The point is that we built the part that is ours.
Not every business has a reason to go that far, and that's fine. But it shows what the decision looks like when you take the framework above seriously and follow it to the end.
How to make the decision this week
You don't need a six-month study. You can get most of the way there in an afternoon.
First, list every tool your business pays for, who uses it and what it costs per month. This is surprisingly eye-opening on its own. Our article on SaaS sprawl has a simple way to do it.
Second, for one week, keep a tally of every workaround and every time someone copies information from one tool to another. A tally mark on a sticky note is enough.
Third, pick the single most painful spot and ask the seven questions above about that one spot, not about your whole company.
Fourth, if the answer leans toward building, talk to someone before you commit to anything. A good builder will tell you honestly if what you have is fine. The U.S. Small Business Administration also has practical guidance on planning and budgeting that's worth a skim before you set a budget for any big project.
If the answer leans toward buying, go buy it, and be glad you didn't overbuild.
And if you land somewhere in the middle, with a business that has outgrown the tools but isn't ready for a large project, that's the most common place we meet people. Application development done in phases exists for exactly that. Start small, prove it, and grow it when it earns its place.
Whichever way you go on build vs buy software, the takeaway is the same. Your software should make your business easier to run, not give you another job. If it's doing the second thing, it's worth asking why.