I Can Build It With Claude Code. Should I? A Build-vs-Buy Calculator for Founders
You can build the internal AI tool. The real cost isn't the build, it's the drift. A loaded-cost calculator that includes the line founders always forget.
Want this inside your company?
Tell us the outcome you need, and we'll show you what we can build.
Problem: You read the whole Claude Code blog. You know headless mode, model selection, tool calls. There's an internal problem staring at you, a lead pipeline, 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 loaded hourly rate. The trap is the second term: roughly 60% of a software system's lifetime cost is maintenance, not construction (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).
Want this inside your company?
Tell us the outcome you need, and we'll show you what we can build.
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 wire Claude to a couple of 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 loaded rate on it. 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 headcount math (Glencoyne). For a founder, the loaded rate 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 loaded hourly rate.
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: Drift, Breakage, 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, maintenance reliably consumes 60 to 80% of total cost of ownership, and the O'Reilly "60/60 rule" pegs roughly 60% of lifecycle cost to maintenance alone (O'Reilly 60/60 rule, Leobit TCO 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 drift harder than normal software, because there are more moving parts underneath them:
- Models get deprecated. The model your agent was tuned against gets retired or updated, and the behavior you validated quietly changes.
- APIs change shape. Every upstream integration is a dependency that breaks on someone else's schedule, not yours.
- Prompts rot. The prompt that scored 9/10 in the demo degrades as providers update, 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 hypothetical drag, it's already the default state of engineering time. Stripe's Developer Coefficient, 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 maintenance and 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. Production bills you for the maintenance tail you can't.
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 maintenance tail.
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 maintenance tax never accrues. 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 proprietary 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 the maintenance tail. Short tail or strategic tail: build. Long tail on something that isn't your product: keep reading.
Where Buying the Outcome Wins
The expensive mistake is building the third category: recurring internal plumbing that a department depends on daily. The lead pipeline. 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 DIY. 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 learning-and-maintenance work that a bought, operated outcome 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 maintenance tail 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 loaded rate and hours. The point is the shape, not the digits.
Take one lead-signal agent that watches for new hires and funding, then drafts a value asset per account. Assume a founder loaded rate of $150/hour.
| Line item | Build it yourself | Buy the outcome |
|---|---|---|
| Visible build | 40 hrs x $150 = $6,000 | $0 (it's already built) |
| Lifetime maintenance (60/60 rule) | ~$9,000 in your hours over the system's life | Included |
| Drift events (model deprecations, API changes) | Unbudgeted, lands on you, at 6pm | Absorbed by the operator |
| Chance it reaches production at all | ~1 in 3 for internal AI builds | It already runs |
| What you spend it on | Babysitting integrations | Your roadmap |
| True 12-month cost | ~$15,000+ and your attention | A predictable line item |
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 drifts, the output goes subtly wrong, and you find out from a customer. The maintenance 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 loaded rate (base salary x 1.25 to 1.4 per the MIT/Hadzima formula, or your true opportunity cost as a founder). Second, lifetime maintenance: assume it's at least 1.5x the build again, since maintenance is roughly 60% of lifecycle cost (O'Reilly 60/60 rule). Third, the drift discount: internal AI builds only reach production about a third as often as bought ones (MIT NANDA), so weight your estimate by the real odds it ships and keeps shipping. 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 reaches production, or that drifts into 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 the majority of the cost under the water.
I'm an indie hacker with more time than money. Doesn't that flip the math?
It changes the loaded rate, not the shape. 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 maintenance tail arrives 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 recurring-internal-plumbing bucket is where buying the outcome usually wins, because that's where the maintenance tax 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 drift, breakage, and 6pm pages is the best use of the one resource you can't buy more of, your own attention. For the recurring 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 →
Want this inside your company?
Tell us the outcome you need, and we'll show you what we can build.
Stop Building Internal AI Tools, Buy the Outcome
Build vs buy for internal AI tools: a minimal in-house team runs $400–600K/year and ~70% never ship. When to build, when to buy the outcome, and the real line item.
Done-For-You vs SaaS vs Consultants: A Buyer's Guide to Installing an AI Outcome
You aren't choosing a vendor. You're choosing how to get a result: a deck, a login, a hire, or an installed outcome. Each one's worst failure mode, scored.