Build vs buy
Buy when your requirement is ordinary and a mature software category already serves it. Expense management, e-signature, appointment scheduling, help desk, payroll and multi-channel inventory are all well-served. A $40-a-month product will beat a $12,000 custom build on cost, features and reliability.
Build when the work is the connective tissue between products you already own, when your logic is genuinely unusual, or when no product can reach a system you depend on. That gap between tools is where custom automation earns its money — and it is a gap no vendor is incentivised to fill.
The six categories where buying almost always wins
If your requirement sits here, we will tell you to buy rather than quote you for a build.
- Expense management. Receipt capture, policy checks, approval routing. Mature category, cheap per user.
- E-signature. Solved, cheap, and carrying legal weight a custom build would not.
- Appointment scheduling. Availability, buffers, reminders, rescheduling. Genuinely fiddly to build and inexpensive to buy.
- Help desk and ticketing. Queues, SLAs, macros, reporting. Do not rebuild this.
- Payroll and benefits. Regulated, changes constantly, and the compliance burden alone rules out building.
- Multi-channel inventory. Mature category, hard problem, and the products have solved edge cases you have not met yet.
The common thread: a large addressable market, so the products are good; and a well-understood problem, so your requirements are probably not special.
The four cases where building wins
- Integration between products you already own. Every vendor builds their product; almost none build the bridge to their competitor's. This is the largest category of legitimate custom work and it is structurally underserved.
- Genuinely unusual logic. Not "we do it differently" — actually different. Unusual commission structures, non-standard pricing, industry-specific compliance workflows.
- A product cannot reach your system. The scheduling tool is excellent and cannot write to your 2009 practice management system. The gap is the project.
- Per-seat pricing has broken. Occasionally a product's licensing makes it absurd at your shape — 200 occasional users who each need one action a month. Rare, and real when it happens.
The comparison people get wrong
Most build-vs-buy analyses compare the build cost against the subscription cost and stop there. Both sides have costs that get left out.
| Buy | Build | |
|---|---|---|
| Up front | Setup and configuration time | $8,000–$35,000 |
| Recurring | Per-seat or per-usage, rises with growth | $0–$150/month platform |
| Usually forgotten | Data migration in, integration to your stack, per-seat growth, the exit cost if you leave | Maintenance when an API changes, the person who owns it, documentation nobody wrote |
| Improves over time | Yes — vendor ships features you did not ask for | No, unless someone changes it |
| Fits your process | Approximately; you adapt to it | Exactly; it adapts to you |
| Risk | Vendor raises prices, deprecates, or is acquired | It breaks and nobody knows how it works |
The row that decides more cases than any other is improves over time. A product you buy gets better while you sleep. A custom build is frozen at the moment it shipped, and every subsequent improvement is a change request. Over three years that gap compounds heavily in the product's favour — which is exactly why buying wins whenever the category is mature.
The answer is usually both
Framing this as binary is the actual mistake. Most good outcomes buy the products and build the connections.
An example. A business needs expense management. It buys a product at $8 per user per month — correct, the category is mature. The product cannot push to its specific accounting system, and it has an approval rule based on project codes the product does not understand. So a $9,000 build handles those two gaps.
Total: a good product doing what it does well, plus a small amount of custom work doing what no product will. That beats both "build it all" and "accept the product's limitations."
Buy the product first and live with the gaps for a month. You will discover that some of the gaps you predicted do not matter, and that a gap you did not anticipate does. Then build against what you actually learned. Building the integration before using the product means guessing at the requirement.
Questions to ask before deciding
- Is there a software category for this? If several vendors compete on it, the problem is well understood and yours is probably not special.
- How unusual is your requirement, honestly? Most businesses believe their process is distinctive. Most are not. Ask what would break if you adopted the product's way.
- What does the product cost at three times your current size? Per-seat pricing that is fine now can be painful later.
- Can the product reach your other systems? If not, you are buying and building. Cost both.
- Who maintains the build in two years? If there is no answer, weight the decision toward buying.
- What is the exit cost either way? Getting data out of a product, or rebuilding an undocumented automation.
Our position
We are paid to build things, which makes "buy it instead" the recommendation that costs us money. We make it regularly, and we charge for the audit as a standalone fixed-fee engagement precisely so that advice does not depend on a build being sold afterwards.
If your automation partner only earns money when you build, weigh their build-vs-buy advice accordingly.
Weighing a product against a build?
A $1,500 second opinion gets you a written recommendation. Sometimes it says buy the product.