Build vs buy: a non-technical founder’s decision framework

Build vs buy is rarely the right question. Here’s a four-question checklist that early-stage founders can run in fifteen minutes before they sign a SaaS contract, hire a dev, or open a Notion doc called “MVP spec.”

The founder I was on the call with had a clean question and a messy answer. He had raised a seed round eight months earlier, signed two enterprise pilots, and was now staring at a spreadsheet with eleven SaaS subscriptions on it. “I think we need to build our own,” he said. “Or maybe consolidate. I’m not sure which. Honestly, I don’t know how to even decide.”

We talked for an hour. He had not, in fact, framed the right question. He thought he was deciding between custom software and SaaS. The real decision tree was wider, his constraints were tighter than he realized, and the answer to “build or buy” depended almost entirely on three variables he hadn’t named out loud yet. He left the call with a four-question checklist. Two weeks later he canceled four of the eleven tools, signed two more, and put exactly one workflow on the build list.

That conversation, in some form, happens at Pixel Breeders almost every week. The build vs buy question is the most common decision a non-technical founder asks us about. It is also the most consistently mis-framed.

This is the framework we use.

What “build vs buy” actually means

Build vs buy is the decision between building custom software for a workflow and purchasing an off-the-shelf product that solves a similar problem. The textbook framing is binary: write the code yourself (build), or pay a vendor for finished software (buy).

In 2026, the framing is wrong before you even start. There is a third option that quietly handles the majority of workflows for early-stage companies: stitch a few SaaS tools together with no-code glue (Zapier, Make, n8n, Airtable, a Retool app on top). It is neither pure build nor pure buy. It is the default reality for almost every pre-Series A startup we work with, and ignoring it produces bad decisions.

So the actual question is:

• Build: custom software written for your specific workflow.
• Buy: one off-the-shelf product that owns the workflow end-to-end.
• Stitch: assemble two or more existing products with light glue (automations, internal forms, a dashboard).

Most founders default to buy, sometimes overspend on stitch, and underestimate how rarely build is the right answer at their stage. The four questions below are designed to surface which of the three actually fits.

The four questions

Run these in order. Each one is a gate. If a question kills the build option, stop there. You don’t need to ask the next one.

1. Is this workflow core to how we make money?

The first gate is whether the workflow is load-bearing for revenue.

A workflow is core if it is one of the following:

• A product surface your paying customers touch directly.
• A workflow your team executes thousands of times per month that has a measurable effect on conversion, retention, or unit economics.
• A regulatory or trust-critical workflow (KYC, custody, claims) where a vendor outage or limitation would meaningfully hurt the business.

A workflow is not core if it is internal coordination (project management, scheduling, expense reports), early customer communication (CRM, email), or anything where “good enough” beats “exactly right.”

If the workflow is not core: buy or stitch. You should not be building software for problems that are solved adequately by a $40-per-seat product that 50,000 other companies are using. The advantage you get from a generic tool is real, the time saved is real, and the maintenance cost of a custom version compounds against you for years.

If the workflow is core, move to question two.

2. Does any off-the-shelf product actually fit our workflow?

Most founders skip this step or do it half-heartedly. They look at two competitors, find one they hate, and conclude “nothing fits.”

The honest version of this question is: spend a real afternoon mapping your workflow as it exists today, then take that map to three actual products and run it through. Not the demo. The real workflow, with your real edge cases.

You’re looking for the gap between what the product does and what you need. A 10% gap is acceptable; you’ll learn to live with it, and the product will probably ship the missing 10% in two quarters. A 40% gap is fatal. You’ll spend the next year doing manual work around the limitations, training people on workarounds, and explaining to your team why “this is just how the tool works.”

The trap here is the demo gap. Sales demos are tuned to make the product look like it handles every case. They do not. The workflow map is the only way to see where the product actually breaks down.

If a product fits with a tolerable gap: buy. Stop the analysis. Move on. There’s no badge of honor for building what someone else has already built.

If no product fits, move to question three.

3. Can we get there by stitching what already exists?

This is the question that has changed the most since 2022, because the SaaS surface area has doubled and the integration layer has matured.

Stitching means: take two or three products that each handle part of your workflow, connect them with automations, and add the thin layer of custom logic that gets you the last mile. A typical stitched workflow at an early-stage startup looks like this:

• HubSpot owns the contact record.
• A typeform or custom intake form pushes new leads into HubSpot.
• An n8n or Make automation routes high-value leads to a Slack channel and a Retool dashboard.
• The Retool dashboard pulls the contact and shows the sales rep a custom view, calls a couple of internal APIs, and writes back a status.

That is “stitched” software. It is neither pure custom code nor pure off-the-shelf. It is the workhorse pattern of the modern early-stage stack.

Stitch wins when:

• The workflow is core but the building blocks already exist as products.
• The custom layer needed is shallow (a form, a dashboard, a few automations).
• You expect the workflow to change every quarter for the next year. Stitched layers are cheap to rip out. Custom code is not.

Stitch loses when:

• The custom layer has grown to half a dozen automations and three Retool apps and nobody can describe how it works.
• Performance starts to matter (n8n queues backing up, Zapier rate limits hitting, Airtable view loading slowly).
• The integration points themselves become a maintenance burden bigger than what owning the code would cost.

This is the failure mode worth naming explicitly: the stitch trap. Stitched systems are cheap to start and expensive to inherit. The founder who built it knows where every piece lives; the next employee opens the Make canvas and sees forty-seven nodes connecting eleven products and quits inside of a month. We’ve seen this enough times that we now treat “we have a stitched system nobody else can read” as an active hiring liability.

If stitching works for the next twelve months: stitch, then check back at that horizon.

If stitching is already breaking, or the system has reached the complexity threshold, move to question four.

4. Is the workflow stable enough to encode?

The last gate is whether the workflow has stopped changing weekly.

Custom software is most valuable when you write it for a workflow you understand. If you’re still iterating on what the workflow even looks like (which steps exist, who does them, what the inputs are), building software for it is expensive insurance against your own indecision. You’ll build the wrong thing, throw it out, build a second version, and discover that the third version is the one you actually wanted. That’s a real cost.

The signal that a workflow is stable enough to encode is operational, not philosophical. You can describe the workflow to a new hire in fifteen minutes without saying “well, that depends.” The exceptions have rules. The edge cases are named.

If the workflow is still in flux: stitch for another quarter. Don’t build yet.

If the workflow is stable, the existing tools don’t fit, the gap is too wide to stitch, and the workflow is core to revenue: build.

That is the only path to “build.” It is narrower than most founders think.

What “build” actually costs at startup scale

The reason this decision matters is the cost difference, and the numbers most founders quote to themselves are off by an order of magnitude.

For an early-stage startup, building custom software with a small studio or partner (not a generic offshore agency, not an in-house team you don’t have yet) typically lands like this:

• A small internal tool that replaces one stitched workflow: $20K–$60K, four to ten weeks. Think a custom dashboard with a few writes back to your database, one external integration, and a clean UI.
• A v1 of a core product surface customers will see: $80K–$250K, three to six months. Real frontend, authenticated users, a thoughtful data model, an internal admin, a deploy pipeline.
• A v1 of a regulated workflow (KYC, payments, claims): $150K–$500K, six to twelve months. Same as above plus audit trails, compliance flows, and the slow part of doing security right.

These are 2026 numbers for a small partner studio, working in TypeScript, React, Postgres, deploying to a managed cloud. Numbers go up if the team is bigger, down if the team is sharper. They go up faster than founders expect when scope creeps without anyone calling it. We’ve written more on the actual cost of building an app at startup stage and on how the contract structure itself changes the math.

The same numbers in SaaS terms: $20K of custom development is roughly two years of a $100-per-seat tool for a ten-person team. $250K is closer to a decade of the same. That math is what should drive the buy default.

The honest version of “what should we spend on this”: if the workflow is core, the math works out, and the gap is real, $80K–$250K for a v1 that owns a workflow your competitors can’t copy in a quarter is not expensive. It’s the rest of the spectrum that gets founders in trouble.

When buy wins (the default answer)

In the conversations we have with founders, buy wins eight times out of ten. The reasons are boring and right.

Generic tools are mature. HubSpot, Notion, Linear, Stripe, Mercury, Ramp, Pylon, Vanta: each of these has a product team of dozens to hundreds, building exactly the feature you’d be building yourself. They ship faster than you can. Their security posture is better than yours. Their integrations are deeper. Their pricing, even at the higher tiers, is usually less than the loaded cost of one engineer for one quarter.

The founder mistake is overweighting the specific 10% the tool doesn’t do. The 90% it does is the win. Most workflows you think are unique are not. We can usually tell a founder within fifteen minutes whether their “custom” workflow is actually custom or whether it’s an off-the-shelf workflow they haven’t recognized yet. Ben Thompson’s Aggregation Theory is the cleanest read on why this is structural, not accidental.

If a product covers 70% or more of your real workflow, buy. Live with the 30% gap. Revisit in a year.

When build wins (the load-bearing exceptions)

Build wins in a small number of well-defined cases.

The first is product surface. If the software you’re considering is what your customers actually buy from you, building it is not optional. Nobody bought a SaaS subscription to a generic version of your product, because there isn’t one — there’s you. Custom software is the company.

The second is operational workflows that compound. Some workflows are not your product but they generate a measurable advantage at scale. A bespoke matching engine for a marketplace. A claims automation engine for an insurance company. A reconciliation system for a fintech. These are workflows where a 10% improvement in throughput converts to a meaningful change in unit economics. Off-the-shelf vendors can’t tune to that. You can.

The third is integration depth. If the workflow needs to read and write across five internal systems with rules that are unique to your business, and the off-the-shelf product would still need a six-month integration project to do half of what you need, the build cost converges with the buy cost and the build version is yours to evolve. We’ve seen this pattern most often in late-seed and Series A companies that have outgrown a stitched setup.

The fourth is regulatory accountability. When you’re the entity responsible for the audit trail, the encryption, the data residency, and the consent flow, the cost of being wrong about a vendor’s compliance posture is sometimes higher than the cost of owning the code. This is more common in fintech, healthtech, and legaltech than founders realize.

Outside these four cases, the answer is usually not build.

The stitch trap, and why it’s the failure mode of 2026

The build-versus-buy debate of 2015 is not the debate of today. In 2015 the choice was real: there were fewer SaaS products, fewer integration platforms, and the question of whether to write code was meaningful. In 2026, almost every early-stage workflow can be stitched together from existing tools, and the question has shifted.

The new failure mode is the stitched system that nobody can read. A founder buys eight tools, hires a part-time ops person to wire them up with Zapier, layers in two Retool dashboards, and discovers eighteen months later that nobody on the team understands how the customer-onboarding workflow actually works. There is no documentation. The flow chart in their head is the only flow chart. When the ops person leaves, the system becomes a single point of failure that nobody dares touch.

We are now actively warning founders against this. Three signals:

• Your stitched system has more than ten integration points and the dependency map exists only in someone’s head.
• More than one critical workflow goes silent for a day because a Make automation rate-limited and nobody noticed.
• Hiring takes longer because new employees can’t be onboarded onto your tooling without a tour from the person who built it.

When any of those signals are firing, the right answer is usually not “build the whole thing.” It’s “encode the spine of the workflow as code and keep the leaves as SaaS.” A small software studio can usually do this in a six-to-ten-week engagement. The result is a system the team can read, that survives turnover, and that keeps the SaaS investments alive for the parts of the workflow where they still make sense.

What to do this week

If you’re staring at this decision today, the work is not philosophical. It’s an afternoon.

Write down the workflow. List the tools that touch it. Run the four questions, in order. If the workflow is not core, stop and buy something. If a product fits, stop and buy that. If a stitched layer is workable for the next twelve months, stop and stitch, and set a calendar reminder to revisit. If none of those hold and the workflow is stable, build.

The founders who get this decision right are not the ones who agonize over it. They’re the ones who frame the question correctly, decide quickly, and revisit the decision when the business changes. That’s most of the value.

FAQ

What is the difference between build and buy?
Build means writing custom software for your specific workflow. Buy means purchasing an off-the-shelf product that solves a similar problem for many companies. In practice there is a third option, stitching multiple SaaS products together with automations and a thin custom layer, and it’s the right answer more often than founders realize at early stages.

Is it better to build than buy?
For an early-stage non-technical founder, buy is the right answer most of the time. Build is the right answer only when the workflow is core to revenue, no off-the-shelf product fits, stitching isn’t viable, and the workflow is stable enough to encode. Outside those conditions, custom software is more expensive and slower than the alternatives.

How much does it cost to build vs buy?
A small custom internal tool typically costs $20K–$60K and runs four to ten weeks with a small partner studio. A v1 of a customer-facing product surface lands at $80K–$250K. SaaS-equivalent spend for the same workflow is usually $5K–$30K per year. The math favors buy unless the workflow is core and durable.

When should a startup build its own software?
When the software is the product itself, when an operational workflow generates compounding advantage at scale, when integration depth across internal systems is unique to the business, or when regulatory accountability makes vendor risk unacceptable. These are the four cases where building wins. Outside them, buy or stitch.