Build, buy, or use what you already own
Four numbers. See whether building pays off, and what the decision is worth.
When does building pay for itself?
Four numbers and one question about fit. It gives you the answer and what it is worth.
Everyone who would hold a license.
List price is fine.
Whatever the estimate says today.
Usually a fifth of the build, every year.
The answer
Fill in the numbers
What this is worth
0
Do this next
Show the numbers
Before the estimate gets signed
Want the build quote pulled apart first?
We reply within one business day.
What this usually leads to
If the answer is build, website development and app development are what that looks like here, with the code and the accounts owned by you at the end. If it is buy the platform and build the gap, the tool overlap check is the next question, because a gap is usually a connection rather than a product.
Saved in this browser, nowhere else. See all your answers together · All twenty-five tools
Buy anything that is not how you win. Configure what you already own before buying anything new. Build only where the process is yours and the products would force you to give that up. The common mistake is choosing before anybody has written down what the process is.
Sounds like this?
“It does almost everything except the one thing we need”
Price the workaround over a year before you price the build.
“We are paying for ninety features and use four”
Fit is the question, not the feature count.
“The workaround has become the process”
That is the moment building starts paying.
Is it a fit?
How you win
The process is part of why customers choose you.
What you own
Tools you already pay for cannot be configured to do it.
Written down
Somebody has written the process down before anyone went shopping.
The six real options
Buy off the shelf
The default, and it should be.
Configure what you already own
The most overlooked option by a wide margin.
Build a thin layer
Keep the bought systems and add a small piece of glue that does the one thing they cannot.
Build the whole thing
Correct only where the process is a real advantage and every product on the market would force you to abandon it.
Why both options fail for the same reason
Almost every build versus buy argument is really an argument about a process that nobody has described. One side argues that no product fits. The other argues that products obviously exist. Neither can be right yet, because the requirement is still a feeling rather than a specification.
A product not fitting is a specific claim, and it should be possible to name the three things it will not do and roughly what each of those costs per month. When a team cannot produce that list, the honest position is that evaluation has not happened yet, whatever the calendar says.
See alsoZapier or a custom integration who owns the code a custom website or a template backend and API development contract negotiation
Before custom or off the shelf, there is an earlier question: fix the process or buy software, and one test separates them.
Build, buy, or switch on what you already have
Seven factors, read across. The second row decides most of these arguments, and it is the row that usually gets skipped because it is the least enjoyable to answer.
| Factor | Buy off the shelf | Configure what you own | Build |
|---|---|---|---|
| Is this how you win? | No. It is table stakes: payroll, accounting, email, standard CRM. | Mostly not, but the way you run it is somewhat yours. | Yes. The process is a real advantage you would have to give up. |
| How well is the process understood? | Well enough to evaluate vendors against it. | Well enough to name what is missing from what you have. | Written down completely. Anything less and you are paying to discover it. |
| Time to working | Days to weeks, plus migration. | Days. The license is already paid for. | Months, and longer than the estimate, in every study and every anecdote. |
| Ongoing cost | A subscription, and it rises over time. | Nothing new, plus somebody's time to configure it. | Maintenance forever. It does not stop when the build does. |
| Who can change it later? | The vendor, on the vendor's roadmap. | You, within the limits of the product. | Only whoever built it, unless it was documented while it was built. |
| Main risk | You inherit the vendor's priorities and whatever terms they set later. | You hit a ceiling and have to make this decision again. | The person who built it leaves and takes the understanding with them. |
| Reversibility | High. Export the data and move. | Very high. Nothing structural changed. | Low. This is where the decision quietly becomes permanent. |
The middle column wins far more often than anybody expects. It is worth an honest afternoon before a purchase order or a build estimate, because it is the only option with no new commitment attached to it.
Five questions before anybody writes code
These take about a day between them. A day spent here regularly removes a purchase or shrinks a build by an order of magnitude.
- Have you written the process down?Not a diagram.
- What does the system you already own do?Read the feature list of the product you are paying for and compare it to what is switched on.
- Is this a differentiator or is it table stakes?If a competitor could buy the same capability tomorrow.
- Who maintains this in year three?Name the person or the team.
- What is the smallest thing that would work?Ask what could be shipped in two weeks that removes the worst part of the problem.
Questions we get
How do we know whether a product does not fit?
Name the three things it will not do, and what each one costs you per month in time or lost work. If that list cannot be produced, the evaluation has not happened yet.
Is a no code tool building or buying?
Both, and it inherits the risks of each. You are buying a platform and building on top of it, which means you carry the maintenance of your logic and the vendor carries the roadmap under it.
We were told a custom build works out better over time. Is that true?
Sometimes, and the comparison is usually done unfairly. A one off build gets compared against years of subscription, while maintenance, the cost of change, and the risk of the builder leaving are left out of the build column.
What is the smallest useful build?
A thin layer between two systems you already pay for, encoding one rule that is specific to how you work. Weeks rather than months, and small enough that one person can hold all of it.
More in the guides and every answer in one place.
Your results so far
Kept in this browser, sent nowhere.
By Shaheer Shaikh, technology and operations consultant · Updated October 3, 2026
Read next
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built