I Can Build It With Claude Code. Should I? A Build-vs-Buy Calculator for Founders

Problem: You've read the whole Claude Code blog. You know headless mode, model selection, tool calls. There's an internal problem staring at you, a pipeline of deals to track, a reporting job, a proposal generator, and the honest answer to "can I build this?" is yes, this weekend. So you're asking the wrong question.

Quick Win: The question isn't can I, it's should I, and the answer is a number most founders never calculate. True cost = (build hours + lifetime maintenance hours) x your true, all-in hourly cost. The trap is the second term: roughly 60% of a software system's lifetime cost is upkeep, not the initial build (a pattern known as the O'Reilly 60/60 rule), so the weekend you can see is usually a fraction of the bill. And internal AI builds succeed only about one-third as often as bought solutions (MIT NANDA, 2025).

---

The Build Cost You Can See

Start with the part your brain already priced. You estimate the build at, say, 40 hours: a weekend to connect Claude to a couple of other systems (APIs), plus a week of polish. Feels like a rounding error. It isn't, because you're pricing your time at zero, and your time is the most expensive input you have.

Put a real, all-in number on your time. A person's true cost to a business runs 1.25 to 1.4x their base salary once you count taxes, benefits, and overhead, a formula from MIT's Joseph Hadzima that finance teams use for hiring math (Glencoyne). For a founder, your true hourly cost is worse than that: your hour isn't billed at cost, it's billed at opportunity, the roadmap feature or the deal you didn't work on instead.

So the visible build cost is simple:

Build hours x your true, all-in hourly cost.

If you value your time at $150 an hour, that 40-hour build is $6,000. Real money, but survivable. This is the number that makes founders say "I'll just build it." It's also the number that's wrong, because it's the tip.

The Cost You Can't See: Breakage, Change, and the On-Call Tax

Here's the line every DIY build forgets. Software isn't a purchase, it's a lease you pay forever. Across industries and system types, upkeep reliably eats 60 to 80% of the full cost of owning a system over time, and what's called the "60/60 rule" says roughly 60% of a software system's cost is maintenance, and maintenance itself runs about 60% of the total lifecycle cost (O'Reilly 60/60 rule, Leobit cost-of-ownership analysis). Flip that around: the build you can see is a minority of what the system will actually cost. Your $6,000 weekend is really a five-figure commitment before it earns a dollar.

And AI tools change out from under you faster than normal software, because there are more moving parts underneath them:

• Models get retired. The AI model your tool was built and tested against gets discontinued or updated, and the behavior you tested for quietly changes.
• Connections to other systems change. Every outside system you connect to (an API) is a dependency that can break on someone else's schedule, not yours.
• Prompts quietly get worse. The prompt that scored 9/10 in the demo degrades as AI providers update their models, and nobody notices until the output is wrong in a way a customer sees.
• The on-call tax. When the agent breaks at 6pm on a Friday, the pager goes to exactly one person: you.

This isn't a hypothetical drag, it's already how software teams spend their time. Stripe's Developer Coefficient study, a survey of more than 1,000 developers, found engineers spend an average of 17.3 hours a week, about 42% of the work week, on upkeep and fixing bad code rather than building new things (Stripe). You are not adding a tool to an empty schedule. You're adding it to a pile that already eats a third of every builder's capacity.

That's why the demo lies. A demo tests the slice you can see. Actually running it for real bills you for the upkeep you can't see.

Where DIY Genuinely Wins

None of this means "never build." It means match the build to the job. There are two places where building it yourself is clearly the right call, and they share one trait: no long stretch of upkeep afterward.

Throwaway and one-time jobs. A data migration you run once. A scraper for a report you need this week and never again. A script that reshapes a CSV. These have a lifetime of days, so the upkeep cost never builds up. Build these with Claude Code all day. The calculator says go.

The tool that is your product. If the AI capability is the thing customers pay you for, or it touches private data and workflows no outside party can see, you build it, because owning it is the point. A reliability failure here is core to your business, so the maintenance you're signing up for is the work, not a distraction from it.

The test is how long the upkeep lasts. Short and finite, or strategic to your product: build. Long and ongoing on something that isn't your product: keep reading.

Where Buying the Outcome Wins

The expensive mistake is building the third category: repeating internal plumbing that a department depends on daily. The pipeline tracker. The competitive brief. The proposal generator. The follow-up tracker. None of these are your product. All of them will run every day, break on someone else's schedule, and page you when they do.

This is exactly where the data turns against building it yourself. MIT's NANDA initiative reviewed 300-plus publicly disclosed AI initiatives, ran 52 structured leader interviews, and surveyed 153 senior leaders, and found that 95% of enterprise generative AI pilots delivered no measurable return, while purchased solutions from specialized partners succeeded about 67% of the time, roughly twice the rate of internal builds (MIT NANDA via Fortune). The gap wasn't model quality. It was the ongoing learning and upkeep work that a bought, already-running solution absorbs for you and a weekend build does not.

When you buy the outcome, you're not paying for code you could have written. You're paying for the upkeep to be someone else's job forever.

A Worked Example: The Same Agent, Built vs Bought, Over 12 Months

Here's the calculator with numbers in it. This is an illustrative model, not client data: plug in your own true hourly cost and hours. The point is the shape, not the digits.

Take one sales-signal tool that watches for new hires and funding at target companies, then drafts a tailored pitch document for each one. Assume a founder's true hourly cost of $150/hour.

The row that decides it isn't a dollar figure, it's "what you spend it on." The build doesn't cost you $15,000. It costs you $15,000 and the attention you needed for the thing only you can do. That's the line the invoice never shows.

If you want the org-scale version of this same math, with the full iceberg of hidden components, we wrote it up separately: stop building internal AI tools, buy the outcome.

The Founder's Real Bottleneck Is Time, Not Skill

Notice what this calculator quietly proves. Your bottleneck was never skill. You clearly can build it. The bottleneck is that every hour you spend building and then maintaining internal plumbing is an hour not spent on the one or two things that actually move the company: the product, the customers, the deals.

That's a bottleneck-diagnosis problem, not a coding problem. The highest-leverage founders we work with aren't the ones who build the most internal tools. They're the ones who ruthlessly protect their own hours for the work nobody else can do, and route everything else, the recurring plumbing, to someone whose job is to keep it running.

If you're not sure which of your own recurring tasks are quietly eating your best hours, that's the thing to map first. A ranked map of where your time actually leaks is the whole starting point: see how we diagnose the bottleneck.

When Your Own Build Is the Right Call (And When It Quietly Is Not)

Honest failure modes, because the calculator cuts both ways:

Buying can be the wrong call, too. If the outcome you'd buy is genuinely your differentiator, outsourcing it hollows out the thing customers pay for. Buy plumbing, never buy your moat.

"I'll maintain it myself" is a promise you break by month three. Every founder believes they'll keep the tool healthy. Then a launch happens, the tool quietly starts producing wrong results as things change around it, and you find out from a customer. The upkeep doesn't get skipped, it gets deferred until it's a fire.

The sunk-cost trap. You built it, it half-works, and now you defend it because you made it, not because it earns its place. A build you'd never buy at its true cost is a build you should retire.

Vendor lock is real. Buying the outcome without owning the output is its own trap. The version worth buying hands you something that keeps producing whether or not you keep the relationship. If it stops working the day you leave, you rented a hostage.

For the deeper pattern on why internally-built department automation stalls even when the code is good, we broke it down here: why companies fail at AI department automation.

Frequently Asked Questions

How do I actually calculate build vs buy for my own tool?

Three terms. First, visible build: your honest hour estimate times your true, all-in hourly cost (base salary x 1.25 to 1.4 per the MIT/Hadzima formula, or your true opportunity cost as a founder). Second, lifetime upkeep: assume it's at least 1.5x the build again, since upkeep is roughly 60% of lifecycle cost (O'Reilly 60/60 rule). Third, the real-odds discount: internal AI builds only actually run for real about a third as often as bought ones (MIT NANDA), so weight your estimate by the real odds it ships and keeps working. Compare that total to the buy price. Most founders stop at term one.

Isn't buying always more expensive per month?

On tokens and licenses, sometimes. On total cost, rarely. A build that never actually gets used for real, or that quietly starts giving wrong answers, costs infinitely more per unit of value than a bought outcome that works. Counting only the monthly subscription is measuring the cheapest line item and ignoring most of the cost hidden underneath.

I'm an indie hacker with more time than money. Doesn't that flip the math?

It changes your true hourly cost, not the shape of the math. If your time is genuinely your cheapest input and the tool is throwaway or strategic, build it. But "more time than money" is usually a story people tell right up until the upkeep starts and the time they thought was free turns out to be the exact time they needed for growth. Cheap time is still spent time.

What should I build myself, then?

The throwaway (one-time scripts, migrations) and the strategic (the tool that is your product or touches data no one else can see). Everything in the repeating-internal-plumbing bucket is where buying the outcome usually wins, because that's where the upkeep cost lives and where the data on internal builds is worst.

---

You can build it. That was never in question. The question is whether the next 12 months of things quietly breaking, changing, and paging you at 6pm is the best use of the one resource you can't buy more of, your own attention. For the repeating plumbing that a team depends on but that isn't your product, we install the outcome and keep it running, so your hours go back to the roadmap. See what we build for companies →