Build vs Buy Software: The Mid-Market Decision Framework
Here is the leak most operators never put a number on. You are paying a monthly subscription to run the one workflow that is supposed to set you apart from your competitors. That workflow lives inside a generic tool that 40,000 other companies use the same way. You are paying to look identical to the people you are trying to beat.
That is the quiet cost of getting the build vs buy software decision backwards. Most mid-market teams get it wrong in both directions at once. They buy generic SaaS for their differentiator. Then they burn engineering capital building a commodity tool that already exists for 99 dollars a month.
This post gives you the decision framework, the math you should run, a comparison table, and the named answer that wins for most operators with a real P&L. Then the honest part: who this is not for.
The leak: you are renting your edge and building your commodity
Two mistakes drain mid-market budgets. They look opposite. They share one root cause: deciding on sticker price instead of where the value lives.
Mistake one is buying generic SaaS for your core differentiator. Off-the-shelf software encodes the average way every customer works. That is its whole business model: sell the same workflow to as many companies as possible. When you run your competitive edge inside that average shape, you flatten yourself into your competitors silhouette. The pricing logic, the routing rules, the way you score a lead or quote a job, the parts that should be uniquely yours, now match everyone else who pays the same vendor.
Mistake two is building commodity tooling. A team decides subscription fees feel like waste, so they build their own CRM, their own email engine, their own ticketing. They spend 6 months and a quarter-million in salary rebuilding a solved problem, then spend forever maintaining it. They saved 200 dollars a month and lit a fire under their capital.
Both mistakes ignore total cost of ownership. The sticker price is the smallest part of the bill. SaaS waste is real and well documented. Industry research consistently finds a large share of software spend goes to underused or duplicate licenses across the average company. Gartner and others have tracked how shadow IT and seat sprawl inflate the real number well past the line item finance sees.
So the first move is not build or buy. It is this: stop looking at the monthly price and start modeling the 3-to-5-year total cost of ownership.
Model TCO, not the sticker price
The sticker price is the trap. Here is what belongs in the model, on both sides of the decision.
What buying really costs
The subscription is the opening bid. Add per-seat creep as you grow. Add the integration work to make the tool talk to the rest of your stack. Add the data you cannot easily export when you want to leave. Add the workflow concessions: every time your team bends their process to fit the tool, that is a cost you pay in efficiency forever. Add the switching cost the day a better option appears, because by then your data and habits are locked in.
What building really costs
The build cost is the opening bid here too. Add maintenance, which never stops. Add security and compliance, which are now your problem. Add the opportunity cost of the engineers who built it and now babysit it instead of shipping product. Add key-person risk when the one developer who understands it leaves. We covered the real ranges in how much business automation actually costs, and the pattern holds: the build number is rarely the build number.
When you put both columns over a 3-to-5-year horizon, the decision stops being about price. It becomes about value and control. Which brings us to the test that matters most.
The one test: is this workflow your competitive advantage?
Forget cost for a second. Ask one question of every workflow: does the way we do this make us pick-able, or is it just plumbing?
If the workflow is your edge, the reason a customer chooses you, the source of your margin, the thing competitors cannot easily copy, you build it. You own it. You never hand your differentiator to a vendor who sells the same shape to your rivals.
If the workflow is a commodity, payroll, email, accounting, calendar, generic CRM contact storage, you buy it. Being standard there is fine. Nobody wins a deal because their payroll software is bespoke. Building it would be vanity spend.
The clearest public example is Netflix. Its recommendation engine is not a feature it bought. It is the core of the business, and the company has reported that personalized recommendations drive around 80 percent of viewing hours, a figure covered widely by outlets like Harvard Business Review. Netflix would never run that on an off-the-shelf tool. That workflow is the company. Meanwhile, Netflix happily buys commodity infrastructure where being different earns nothing.
That is the whole heuristic. Build where the workflow is the advantage. Buy where it is plumbing. The mistake is treating every system the same.
How to spot the edge in your own business
Three questions cut through it fast. First: if a competitor copied this exact workflow tomorrow, would we lose a real advantage? Second: do customers feel this workflow, or is it invisible back-office? Third: is the value in the data and logic we have accumulated, or in the generic function? If the answers point to we would lose something real, customers feel it, and the value is in our logic, that is a build. Everything else is a buy.
The named answer: the API-first hybrid
Most operators do not face a clean binary. You have one or two real edges and a dozen commodity functions. The answer is not build everything or buy everything. It is the API-first hybrid: buy the commodity, build the edge, and wire them together through APIs.
Concretely, that looks like this. You keep your commodity systems off the shelf. A HubSpot for CRM, a Twilio for telephony, a GoHighLevel for marketing plumbing, whatever fits. You stop trying to rebuild solved problems. Then you build the single workflow that is your differentiator as a custom layer that owns the logic, the data model, and the decisions. The two halves talk through APIs and an orchestration layer.
This is the same architecture pattern behind every modern stack: composable pieces connected through clean interfaces, standardized around clean data conventions and documented APIs. You are not choosing build or buy. You are choosing what to own and what to rent, then connecting them so the seam is invisible to your team and your customer.
The reason this wins for mid-market is sharp. You stop paying to rebuild commodity software, and you stop paying to rent your differentiator. The capital goes only to the workflow that earns it. That is the move luup builds custom platforms around, and the platforms ship in days, not the 6-to-18-month timeline most operators dread. They are owned by the client. Not licensed back to you. Owned.
Build vs buy vs hybrid, side by side
Here is the decision in one view. Run your own workflow against each row.
| Dimension | Build | Buy (generic SaaS) | API-first hybrid |
|---|---|---|---|
| Upfront cost | High | Low | Medium, build only the edge |
| Time to live | Weeks to months, days with modern methods | Days | Days to weeks |
| 3-5 year TCO | High if you build commodity, justified if you build the edge | Hidden seat creep, integration, switching costs add up | Lowest blended cost, capital only on the differentiator |
| Control and ownership | Full, you own code and data | Low, vendor owns the roadmap and your data export | You own the edge, rent the commodity |
| Fit to your workflow | Exact | Average, you bend to the tool | Exact where it matters, standard where it does not |
| Maintenance burden | Yours forever | Vendor handles it | Small custom surface to maintain |
| Best for | Your single core differentiator | Pure commodity functions | Most mid-market operators |
Read the table and one thing jumps out. The hybrid column is not a compromise. It is the only column that puts your money where the value is and keeps it off where it is not.
The decision framework, step by step
Run this in order. It takes an afternoon and saves you a year.
Step 1. List every software-backed workflow. Sales, support, ops, finance, the lot. Be granular. CRM is too broad. How we score and route inbound leads is a workflow.
Step 2. Tag each one edge or commodity. Use the 3 questions above. Most operators find they have one or two real edges and a long tail of commodity. That is normal and it is the point.
Step 3. For every commodity workflow, buy. Pick the cleanest tool with the best API. Do not build here. Building commodity to save a subscription is the most expensive way to be cheap.
Step 4. For every edge workflow, model build vs hybrid over 3 to 5 years. Put the real TCO in both columns. Include maintenance and opportunity cost on the build side. Include integration and switching cost on the buy side.
Step 5. Build the edge, wire it to the commodity via APIs. The orchestration layer is where the hybrid lives. Tools like Make.com and n8n handle the wiring for automation-grade workflows, and we broke down the trade-offs in our Make vs n8n vs Zapier comparison. For the differentiator itself, a custom platform owns the logic.
Step 6. Measure the leak before and after. Quantify what the wrong setup was costing you in dollars and hours. The open-loop tax calculator puts a number on the workflows leaking value right now, which is the fastest way to see whether the edge is worth building.
Who this is NOT for
The hybrid is the default answer, not the universal one. Be honest about whether you are in one of these cases.
You have no real differentiator yet. If no single workflow makes you pick-able, do not build anything. Buy clean commodity tools, run the business, and find the edge in the market first. Building before you have an edge is building a monument to a guess.
You cannot or will not maintain custom code. A custom platform is an asset, but an unmaintained one rots. If you have no path to maintenance, in-house or through a partner, the buy column is safer even for parts of your edge. Honesty here beats ego.
The function is pure commodity and you are tempted anyway. Accounting. Payroll. Email delivery. Calendar. If you catch yourself wanting to build these to save fees, stop. The payback is negative once you price in security, compliance, and the engineers you pulled off real work.
You need it live this afternoon and the edge can wait. Sometimes speed beats fit. Buy the generic tool now, prove the workflow matters, then build the edge later when you have evidence. Sequencing is a strategy, not a failure.
If none of those fit you, if you have a clear edge, can maintain it, and the commodity is genuinely commodity, the API-first hybrid is your answer. Build the edge, buy the rest, wire them together.
Where to start
The framework is easy to state and easy to get wrong under pressure, because every vendor demo and every just-build-it engineer pulls you toward an extreme. The discipline is holding the middle: own the edge, rent the commodity, model the 3-to-5-year number, and put capital only where value lives. Most teams who run this exercise find 2 or 3 commodity tools they were about to rebuild, and one real edge they were about to rent. Both decisions get reversed in an afternoon.
If you want the leak quantified before you decide anything, the free Closed Loop Audit maps where your stack is buying your differentiator and building your plumbing, the exact inversion this post is about. You can see how that plays out in real stacks in our case studies, and when you are ready to scope what to build, tell us what your edge is and we will tell you straight whether it is worth building or whether you should keep buying.
Frequently asked questions
How do I decide between build vs buy software for my business?
Run one test first: is this workflow your competitive advantage or a commodity? Build the edge, buy the commodity, and connect them through APIs. Then model 3-to-5-year total cost of ownership for each path, not the monthly sticker price, because integration, seat creep, and switching costs dominate the real number.
Why is buying generic SaaS risky for my core workflow?
Generic SaaS encodes the average way every customer works. When you run your core differentiator inside it, you inherit your competitors shape and lose the thing that made you pick-able. Buying is right for payroll or email, where being standard is fine. It is wrong for the workflow your margin depends on.
What is an API-first hybrid and why does it win?
An API-first hybrid means you buy commodity systems like CRM, payments, and telephony, build only the workflow that is your edge, and wire them together through APIs. You stop paying to rebuild solved problems and stop renting your differentiator. It is the default answer for most mid-market operators with one real edge.
How long does a custom platform actually take to ship?
With modern build methods, the timeline is days to weeks, not the 6-to-18-month projects most operators fear. luup ships custom platforms in days, client-owned, scoped to the single workflow that is your edge. The risk is scope creep, so the discipline is building one differentiator well rather than rebuilding your whole stack.
When should I just keep buying SaaS instead of building anything?
Keep buying when no single workflow is your differentiator, when your team cannot maintain custom code, or when the function is a pure commodity like accounting or email. Building commodity tooling to save subscription fees almost never pays back once you price in maintenance, security, and the opportunity cost of your engineers.
Still unsure where your edge ends and your plumbing begins? Start with the free Closed Loop Audit and get the leak quantified before you spend a euro on build or buy.