Build vs buy: a real framework
Stop pretending you're choosing on technical merit. Decide with eyes open.
What you'll have at the end
A decision you can defend in six months — not 'we built it because we could' or 'we bought it because the sales rep was nice.' You know what you optimized for, what you traded away, and what would have to change for you to revisit the call.
01
Who this is for
- Founders staring at a SaaS quote that feels too high — or a build estimate that feels too low
- Operators who keep getting talked into 'we'll just build it' by enthusiastic builders
- Teams that already bought the thing, regret it, and don't want to repeat the mistake
02
How to frame the idea
Build vs buy is almost never a technical decision. It's a question about where your team's attention is best spent, how core the capability is to what you sell, and how much rope you want to give future-you. The honest framework: write down what you're optimizing for (speed, control, cost, differentiation), price the real cost of both paths including the boring stuff (maintenance, onboarding, the person who has to own it), and pick the option whose worst-case you can live with.
03
What people actually build
Auth: build or buy?
Almost always buy (Clerk, Auth0, Supabase Auth, Lovable Cloud). The boring stuff — password reset, session rotation, SSO, audit logs — eats months and isn't your product. Build only if auth IS your product.
Internal admin dashboard: build or buy?
Usually build (and quickly). Retool/Metabase get you 80% in a day, but the last 20% — the workflow that's specific to your business — is why you needed it in the first place. The wrapper around your own data is rarely worth a vendor.
Billing & subscriptions: build or buy?
Always buy (Stripe, Paddle, Lemon Squeezy). Tax, dunning, refunds, chargebacks, regional compliance — every one of those is its own multi-year project. Buy the platform; build the parts that touch your product (entitlements, plan logic).
04
Tool choices, honestly
The 'core vs context' test
If the capability is what customers pay you for (your core), lean build. If it's table-stakes plumbing (context), lean buy. Stripe is context for most businesses; for a payment processor it's core.
The 'who owns it at 2am' test
If you build, someone on your team gets paged when it breaks. If you buy, the vendor does (sort of). Be honest about whether you have that person and whether they want that pager.
The 'real total cost' worksheet
Buy cost = subscription × expected years + integration time + switching cost. Build cost = engineer-weeks × loaded rate + ongoing maintenance (rule of thumb: 25% of build cost per year) + opportunity cost of what they're NOT building.
The reversibility check
Can you switch in three months if it doesn't work? Buying with a clean API is easy to reverse; building on a custom data model isn't. Prefer reversible decisions when you're not sure.
05
Prompts you can lift
Frame the decision honestly
Help me think through build vs buy for <capability>. First, ask me whether this is core (customers pay us for it) or context (it's plumbing). Then ask what I'm optimizing for: speed to market, long-term cost, differentiation, control, or team focus. Don't recommend yet — make me rank those four. Then walk me through the trade-offs of each option given my ranking.
Price both paths realistically
I'm evaluating <buy option> at <price> vs building it in-house. Build me a 3-year total cost comparison. For buy: subscription, integration cost, expected switching cost if we leave. For build: realistic engineer-weeks at <loaded rate>, plus 25%/year maintenance, plus the opportunity cost of what those engineers would otherwise ship. Be skeptical of my build estimate and ask what I'm forgetting.
Stress-test the build case
I'm leaning toward building <capability>. Argue the buy side as hard as you can. What are the boring parts I'm underestimating (auth, audit logs, internationalization, compliance, accessibility, mobile)? What happens to this code when the person who built it leaves? What's the failure mode where in 18 months we're paying both the salary AND the SaaS bill because we gave up?
Stress-test the buy case
I'm leaning toward buying <vendor>. Argue the build side. Where will this vendor's pricing bite us at 10x scale? What features are we one product-pivot away from needing that they don't have? What's our exit plan if they get acquired, sunset the product, or 5x the price? Where does their data model fight ours?
Save and reuse these prompts in PromptlyDo™ with your favorite AI.
- Install the PromptlyDo™ browser extension
- Sign in or create a free account
- Right-click any prompt above and save it to PromptlyDo™
06
What tends to break
- Choosing 'build' because engineers want to build it. The most expensive sentence in software is 'how hard could it be?'
- Choosing 'buy' because the demo was slick. The demo is the product at its best on a curated dataset. Production is messier.
- Comparing build cost (just the first version) to buy cost (3 years of subscription). Compare apples to apples — both paths have ongoing cost.
- Forgetting the cost of NOT shipping the thing your team would've built instead. Engineer-weeks aren't free; they're stolen from your roadmap.
- Building because the vendor 'doesn't do exactly what we need.' 95% of the time, adjusting your workflow is cheaper than building from scratch.
- Buying because building 'distracts the team' — then spending more total time on integration, glue code, and workarounds than the build would've taken.
- Picking based on the loudest voice in the room instead of writing the trade-offs down where everyone can see them.
07
What AI forgot to ask you
- Is this capability core to what customers pay you for, or is it plumbing? Most teams answer 'core' too easily.
- Who specifically owns this thing in 18 months? Name them. If you can't, that changes the math.
- What's the cost of switching off the buy option if it goes sideways — and the cost of replacing the build option if the person who built it leaves?
- What does 10x the current usage look like in each option? Vendor pricing tiers, system limits, team scaling.
- Are you comparing the full lifecycle (build + maintain + replace) or just the upfront cost?
- What's the regulatory or compliance picture? Some 'just build it' answers become 'just build it AND maintain SOC 2 for it' — that's not the same thing.
08
Before real users see it
- I wrote down what I'm optimizing for, ranked, before I evaluated options.
- I have a 3-year total cost number for both paths, with the boring stuff (maintenance, onboarding, opportunity cost) included.
- I know who owns this capability in 18 months — by name, not by team.
- I know what would have to change for me to revisit this decision, and I've put a note in my calendar.
- If I'm buying, I have an exit plan — what I'd do if the vendor sunsets, gets acquired, or doubles their price.
- If I'm building, I've named the person who'll maintain it and confirmed they're on board.
09
Questions to sit with
- 1.Is this capability part of why customers choose us, or is it the kind of thing every business needs and nobody cares how we got it?
- 2.If I build it and the person who built it leaves in a year, what happens?
- 3.If I buy it and the vendor announces a 3x price increase in a year, what happens?
- 4.Am I about to build something because it's actually the right call — or because building is more fun than evaluating vendors?
- 5.Six months from now, what would I need to see to know I made the right call?
Ready to app it?
Take this path into your tool of choice — and when you finish (or get stuck), share what you learned so the next builder doesn't reinvent it.