"We need custom software."
We hear this in almost every first call. Sometimes the client is right. Sometimes they're about to spend six months and a significant budget building something that already exists for $50/month.
Part of our job is knowing the difference — and being honest about it, even when honesty means telling a prospect not to hire us.
This post is the framework we use internally to evaluate build-vs-buy decisions. We're sharing it because if you're asking this question, you deserve a straight answer before you commit.
The default should be buy
This might sound strange coming from an agency that builds custom software. But the starting position should always be: don't build.
Off-the-shelf tools exist for almost everything. Project management, CRM, invoicing, HR, inventory, e-commerce — there are mature products in every category, most of them better than what any agency will build from scratch in a comparable timeframe.
The burden of proof should be on building, not buying. If you can't clearly articulate why an existing tool won't work, you shouldn't be building.
When buying makes sense
Buy when the problem you're solving is generic and well-served by existing products. If your needs map cleanly to what a product already does — even if it's not a perfect fit — buying is almost always the right call.
Specifically, buy when your workflow is standard for your industry and doesn't require unique logic, when the tool's limitations are cosmetic rather than structural, when the vendor has a track record of reliability and active development, and when you'd need less than 20% customization to make it work.
A CRM that doesn't match your exact field labels? Buy it and adapt your process. An invoicing tool that doesn't have one specific report? Buy it and export to a spreadsheet. These are inconveniences, not reasons to build.
The cost of building includes not just development, but ongoing maintenance, hosting, security updates, bug fixes, and feature requests — forever. A SaaS subscription handles all of that for you.
When building makes sense
Build when your competitive advantage depends on software that doesn't exist, or when existing tools force you to break your core workflow.
Here are the patterns we've seen where building was the right call:
The process is your product. If your business runs on a workflow that's genuinely unique — not "unique" as in "we like it different," but unique as in "this is how we create value" — then forcing that into a generic tool means compromising what makes you competitive.
You've outgrown the tool. You started with an off-the-shelf solution, it worked for a while, and now you're hitting walls. The integrations are fragile. The workarounds are multiplying. Your team spends more time fighting the tool than using it. This is the most common and most legitimate trigger for building.
The data is the asset. When you need full control over how data is stored, processed, and connected — for compliance, for analytics, or because the data relationships are genuinely complex — off-the-shelf tools become a liability rather than an asset.
Integration is the core need. You don't need "a CRM" or "an ERP" — you need a system that connects five existing tools into one coherent workflow. No single product does that because it's specific to your stack.
The grey zone: where most bad decisions happen
Most build-vs-buy mistakes don't happen at the extremes. Nobody builds a custom email client. Nobody buys a generic tool when they need a real-time trading platform.
The mistakes happen in the middle. The grey zone looks like this:
"The tool does 80% of what we need, but that 20% is really important." This is the most dangerous sentence in software procurement. Sometimes that 20% genuinely justifies building. More often, it's a preference disguised as a requirement. The question to ask: if the tool did that 20% badly, would it actually hurt your business, or would it just annoy your team?
"We want to own the IP." Ownership is a valid concern, but it's not automatically a reason to build. If the tool you'd build isn't part of your competitive advantage, owning the code doesn't add value — it adds cost.
"We want to avoid vendor lock-in." Also valid, but building custom creates a different kind of lock-in: dependency on the agency or team that built it. One lock-in charges you a subscription. The other charges you maintenance.
If you're specifically evaluating ERP systems and wondering whether to go with Odoo or build custom, we've written a detailed breakdown of the three ERP routes — vanilla Odoo, customized Odoo, and purpose-built.
How we evaluate this with clients
When a prospect comes to us with a build request, we run through a simple checklist before we agree to scope anything:
What exists today? We research what's available. If there's a product that handles 80%+ of the need, we recommend the client try it first. If they've already tried it and hit real limits, we move forward.
What's the actual differentiator? We ask the client to describe, in one sentence, what their software needs to do that nothing on the market does. If they can't, that's a signal.
What's the 3-year cost comparison? We estimate the total cost of building and maintaining the custom solution over 3 years — including development time and ongoing maintenance. Then we compare it to the subscription cost of an off-the-shelf alternative over the same period. The numbers often surprise people.
Are you ready to maintain it? Custom software isn't a one-time purchase. It needs hosting, updates, security patches, and ongoing development as your business evolves. If the client doesn't have a plan for this — either in-house or through a maintenance contract — we flag it as a risk.
We've talked clients out of building
It happens. A prospect comes in ready to commission a full custom platform, and we tell them to start with Notion, or Odoo, or a well-configured Shopify store. We've recommended off-the-shelf solutions that saved clients months and significant budgets.
We'd rather give honest advice and earn trust than take a project that shouldn't exist. The clients we talk out of building today often come back with a real build need later — because they remember the agency that didn't try to sell them something they didn't need.
What this means for you
If you're debating build vs. buy right now, start here:
Can you describe, in one sentence, what your custom software needs to do that no existing product does? If yes, you might have a build case. If you're struggling to articulate it, try an off-the-shelf tool first.
If you decide to build, the next questions are whether to start with an MVP or a full product, how to write the brief, and what to ask the agency before signing. We've written about how we deliver projects when building is the right call and why we chose the tech stack we use. But sometimes the best technical decision is to not build at all.
Not sure whether to build or buy? Let's figure it out together →