Pricing & Ownership11 min read

When to Build vs Buy Software

By Tyler Hall||
Quick take

A practical decision framework for choosing custom software vs off-the-shelf tools: workflow fit, total cost, ownership, and when each is the right call.

At some point, most owner-led businesses hit a wall with off-the-shelf tools. The scheduling app almost fits. The CRM does 80% of what you need. The quoting process still lives in a spreadsheet nobody trusts. And someone — a developer friend, an agency, maybe you at 11pm — floats the idea: what if we just built our own? We build custom platforms for clients when the case is genuinely there, so we have seen this decision from both sides. Our honest answer, most of the time, is: don't build.

The CEO of a 30-person logistics company once told us he spent $180,000 building a custom CRM because "nothing on the market did exactly what we needed."

Eighteen months later, the custom CRM was half-finished, the original developer had left, and the company was maintaining a fragile system that did less than HubSpot's free tier. They eventually switched to an off-the-shelf tool and spent another $15,000 migrating their data.

Total cost of the "nothing does what we need" decision: roughly $200,000 and two years of distraction.

On the other side, we have seen companies force-fit a generic project management tool into a role it was never designed for, creating a mess of workarounds, spreadsheet supplements, and frustrated employees who spend more time fighting the tool than doing their work.

Both mistakes are expensive. Both are avoidable. The difference is having a clear framework for making the decision before emotions and vendor pitches cloud your judgment.

The Default Should Be Buy

Let us get this out of the way: for 90% of software needs at companies in the $1M to $20M range, the right answer is to buy existing software.

The market for business tools has exploded in the past decade. There are thousands of SaaS products covering everything from accounting to warehouse management to employee scheduling. The odds that your business has a truly unique software need — one that no existing product addresses — are much lower than you think.

The case for buying is straightforward:

  • Lower upfront cost. A $200/month subscription is immediately usable. Custom development starts at $50K and goes up from there.
  • Faster time to value. You can be using an off-the-shelf tool within days. Custom software takes months to build.
  • Ongoing maintenance included. The vendor handles updates, security patches, uptime, and bug fixes. With custom software, all of that is your problem.
  • Proven at scale. A product used by thousands of companies has been tested against thousands of edge cases. Your custom build has been tested against your imagination.
  • You can switch. If a SaaS tool stops working for you, you move to a competitor. If your custom software stops working, you are stuck.

When Building Actually Makes Sense

That said, there are real situations where building custom software is the right call. They are rarer than most people think, but they exist.

Reason 1: Your Process Is Your Competitive Advantage

If the way you do something is fundamentally different from your competitors and that difference is why customers choose you, a generic tool might flatten your advantage.

Example: A specialty insurance broker has a proprietary risk assessment methodology that produces more accurate quotes than competitors. Off-the-shelf insurance software forces a standard workflow that would eliminate their differentiator. Building a custom quoting tool preserves their competitive edge.

The test: Would using the same software as your competitors make your offering indistinguishable from theirs? If yes, building might be justified. If no — if your advantage comes from your people, your relationships, or your pricing — buying is fine.

Reason 2: No Product Serves Your Market

Some niches are underserved. If you operate in a specialized industry with unusual workflows and you have genuinely evaluated 10+ products without finding anything close, building might be your only option.

The test: Have you actually tried 10 products? Not glanced at their websites — actually signed up for trials, done demos, and tested them against your real workflows? Most people who say "nothing exists" have tried two things and given up.

Reason 3: Integration Is Impossible

Sometimes you need two or three systems to talk to each other in a way that no existing integration supports. If the data flow between your systems is complex and critical to your operations, a custom integration layer (not necessarily a full custom application) might be necessary.

The test: Have you explored integration platforms like Zapier, Make, or Tray.io? Have you talked to the vendors about their APIs? Many integration problems that feel impossible have standard solutions.

Reason 4: The Math Works at Scale

If you have a software need that will be used by hundreds of employees or touches thousands of daily transactions, the per-user or per-transaction cost of commercial software can add up fast. At some point, the annual subscription cost exceeds the annual maintenance cost of a custom solution.

The test: Calculate three years of subscription costs including all users, all add-ons, and reasonable price increases. Compare that to a realistic estimate of building and maintaining custom software (developer salaries, hosting, security, ongoing development). If building is cheaper over three years even after doubling your development estimate, the math might work.

The Decision Framework

Before you make this call, work through these seven questions in order. Be honest with each answer.

Question 1: What problem are we actually solving?

Write it down in one sentence. Not "we need a better system" — that is not a problem statement. "Our order fulfillment process takes 4 days when it should take 1, because we manually transfer data between our inventory system and our shipping system" — that is a problem statement.

If you cannot define the problem clearly, you are not ready to evaluate solutions.

Question 2: Is this a core or support function?

Core functions are directly tied to how you deliver value to customers. Your product, your service delivery, your unique methodology.

Support functions are everything else. Accounting, HR, internal communication, project management, CRM, marketing.

For support functions, always buy. You are not in the business of building accounting software, and the companies that are have a 20-year head start on you.

For core functions, buying is still usually the right answer, but this is where building becomes worth evaluating.

Question 3: What does the off-the-shelf market look like?

Research thoroughly. Our FAQ page covers some common questions about evaluating technology solutions. Spend at least a week evaluating options:

  • Identify 5-10 products that address your problem
  • Sign up for free trials or demos of the top 3
  • Test them against your actual workflows, not hypothetical ones
  • Talk to other companies your size who use them
  • Read reviews from real users, not just marketing materials

Question 4: What is the true cost of each option?

For buying:

  • Monthly or annual subscription fees (for all users who need it)
  • Implementation and migration costs
  • Training costs
  • Integration costs (connecting it to your other tools)
  • Ongoing customization and configuration
  • Price increases over time (assume 5-10% annually)

For building:

  • Development costs (be realistic — double your first estimate, then add 30%)
  • Project management time (someone internal needs to manage the project)
  • Hosting and infrastructure
  • Ongoing maintenance (plan for 20% of original development cost per year)
  • Security and compliance
  • Future development for new features
  • Opportunity cost (what else could your team or budget be doing?)

Run the numbers over three years. Include everything.

Need budget context?

Review pricing for Website Systems, Growth System modules, Operating Layer work, Platform Builds, and Systems Support.

View Pricing

Question 5: What is the risk?

Risks of buying:

  • Vendor goes out of business (mitigate by choosing established companies)
  • Vendor raises prices dramatically (mitigate by avoiding deep lock-in)
  • Product does not fit your workflow perfectly (mitigate by testing thoroughly before committing)

Risks of building:

  • Project takes longer than expected (this happens about 80% of the time)
  • Project costs more than expected (this also happens about 80% of the time)
  • Key developer leaves mid-project (you are one resignation away from a crisis)
  • The finished product has fewer features than commercial alternatives
  • Ongoing maintenance becomes a burden
  • Security vulnerabilities go unpatched

Be honest about which set of risks you are better equipped to manage. For most small businesses, the risks of building are significantly harder to handle.

Question 6: Can we start with buying and switch later?

In many cases, the best approach is to start with an off-the-shelf tool, use it until you truly understand your requirements, and then evaluate whether building is justified.

Six months of using a commercial tool will teach you more about what you actually need than six months of writing a requirements document. You will discover features you cannot live without, features you never use, and workflows you did not anticipate.

If you eventually decide to build, you will build the right thing because you learned from real usage, not assumptions.

Question 7: Do we have the capability to build and maintain this?

Building software requires:

  • A technical leader who can make architecture decisions
  • Developers who will stick around for the long haul (not just the build phase)
  • A product management function (someone who decides what to build and in what order)
  • Quality assurance and testing capability
  • DevOps and infrastructure management
  • Security expertise

If you do not have at least three of these in-house, you will be dependent on contractors or an agency. That is not automatically bad, but it adds cost, complexity, and risk.

The Hybrid Approach

There is a middle ground that many growing companies overlook: buy the platform, customize the edges.

Most modern SaaS tools offer APIs, webhooks, and customization options that let you adapt them to your workflows without building from scratch. You get 80% of the functionality out of the box and build the remaining 20% as custom integrations or add-ons.

Examples:

  • Buy a CRM like HubSpot. Build a custom integration that automatically enriches new contacts with data from your industry-specific database.
  • Buy a project management tool like Asana. Build a custom dashboard that pulls data from Asana, your time-tracking tool, and your invoicing system into one view.
  • Buy an e-commerce platform like Shopify. Build a custom pricing engine that applies your unique discount logic at checkout.

This approach gives you the reliability and breadth of a commercial platform with the specificity of custom development. And if the platform ever needs to be replaced, your custom pieces are usually small enough to rebuild quickly.

The Wrong Reasons to Build

Before we close, here are the reasons we hear most often for building custom software — and why they are usually wrong.

"It will be exactly what we need." Maybe. But what you need today will change in six months. Commercial software evolves with the market. Custom software evolves only if you pay developers to change it.

"We do not want to depend on a vendor." You are trading vendor dependency for developer dependency. At least the vendor has hundreds of customers funding continuous improvement. Your developer is one person.

"Our process is too unique." We hear this from every company. Very few are actually that unique. Your process might be different, but it is probably not different enough to justify $100K+ in custom development.

"It will be cheaper in the long run." Almost never true for companies under $20M. Custom software has hidden ongoing costs — maintenance, hosting, security, updates, new feature development — that add up fast.

Make the Decision

Write down the problem. Research the market. Run the real numbers. Be honest about your capabilities and risks. Most of the time, you will conclude that buying is the right call. And for the rare occasions when building is justified, you will go in with clear eyes and realistic expectations.

If you are in the middle of this decision right now and want an experienced perspective, book a free call. Custom software is something we actually build — the Platform Build tier on our pricing page exists for the rare cases where the framework above genuinely points to building — which means we can tell you honestly when it doesn't. Most of the time we end up steering people toward off-the-shelf tools or the hybrid approach. And when building is the right call, it gets built as part of a working website system your team runs every day, not a science project. No vendor commissions — just a clear recommendation based on your actual needs and resources.

Ready to scope the right level of help?

Use the pricing page to compare common starting points before you request a build or support plan.

View Pricing

Get field notes like this in your inbox

Practical notes on website clarity, lead follow-up, SEO visibility, and reporting for small businesses. Every two weeks.

Related Articles