There's a specific moment every technical founder hits: staring at a pricing page for an auth provider or a payments platform, doing the mental math on the monthly fee, and thinking — I could just build this. It's a login form and a database table. How hard can it actually be?
Hard enough that entire companies exist doing nothing else, employing hundreds of people, for years, to keep doing it correctly. The instinct to build it yourself is strongest exactly where it's most expensive to be wrong, because the parts that look simple from the outside — a password field, a charge button, a batch email — are the parts where someone else has already paid for a decade of mistakes you haven't made yet. The revenue-side version of what should a technical founder not build themselves is something writes about in more operational detail than I go into here. The revenue-side version of what should a technical founder not build themselves is something XenGrowth writes about in more operational detail than I go into here.
What Rob Walling's own numbers actually said
In 2008, before 'build vs buy' was a startup cliché, Rob Walling wrote out his own math for deciding whether to build a software product from scratch or buy an existing one. His estimate for a typical build: 348 hours, roughly two months, with a fully loaded cost — design, development, a marketing site, documentation, initial SEO and paid acquisition — landing north of $40,000 once you price labor at market rates rather than 'free because it's my own time.' He then bought DotNetInvoice, an existing invoicing product, for about 20% of what building an equivalent from scratch would have cost him, and got existing paying customers and search rankings bundled in with the code. Reasoning through exactly this kind of cost comparison, on the revenue-operations side, is a chunk of what writes operator guides about.
That 20% figure is doing a lot of work in this argument and deserves a caveat: it's one deal, from one founder, in one product category, in 2008. It is not a universal exchange rate between building and buying. What generalizes isn't the specific percentage — it's the finding underneath it, which shows up again and again in every founder's actual accounting once they do it honestly: building something a market has already solved is close to always more expensive than the sticker price on the alternative makes it look, because the sticker price doesn't include your own hours.
The recurring list, and why it's the same three things every time
Ask working engineers what a founder should never build themselves and you get the same short list with remarkable consistency: payments, authentication, and transactional email deliverability. A widely-discussed Hacker News thread on exactly this question converged on those three within the first dozen replies, and it's worth being honest about what that convergence is — anecdotal agreement among practitioners, not a controlled study — while also taking it seriously, because it's the kind of consensus that only forms when enough people have independently hit the same wall. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Category | Looks like | Actually is |
|---|---|---|
Payments | A charge button and a database row | PCI compliance, chargeback handling, fraud scoring, multi-currency settlement, a decade of edge cases in how cards fail |
Authentication | A password field and a sessions table | Credential-stuffing defense, breach-list checking, MFA, account recovery that doesn't become a social-engineering hole |
Transactional email | An SMTP call | IP and domain reputation management, spam-filter relationships, deliverability monitoring most founders don't know exists |
Basic analytics | Logging events to a table | Retroactive schema changes, funnel definitions, a UI nobody but you will ever look at twice |
Notice what these four have in common: none of them are things a customer is choosing you for. Nobody signs up for your product because you rolled your own auth system. They sign up despite it, if it works, and they leave because of it the one time it doesn't.
Basic analytics belongs on that list for a different reason than the other three — it isn't adversarial or regulated, it's just a time sink disguised as a small task. 'Just log events to a table' turns into retroactive schema changes once the first real question comes in, then a homemade dashboard nobody but the founder ever opens, then a slow drift into maintaining a reporting tool instead of the product. It rarely causes a security incident. It just quietly eats a week a month for a year, on something a $20-a-month tool already does better. Deciding which parts of a revenue stack are worth that kind of build effort is exactly what walk through, category by category.
Why the pull to build is strongest exactly where it's most expensive
There's a psychological reason this keeps happening to competent engineers, not just inexperienced ones. Payments and auth are genuinely interesting problems — token expiry, idempotency keys, webhook retries, session fixation — the kind of thing that reads like a systems-design interview question, which is exactly why building them feels like real engineering in a way that gluing together a vendor's SDK does not. The vendor's problem is more interesting than your product's problem, and that's the trap: interesting and valuable aren't the same axis, and a founder's first year only has room to optimize for one of them. There is a longer treatment of AI agents and marketing automation in . There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
There's also a cost asymmetry that rarely gets named directly. When a vendor's payments system has an edge case, it's the vendor's incident, the vendor's on-call, and usually the vendor's compliance team that absorbs it. When your own from-scratch system has the same edge case, it's your 2am, your support ticket, and — if it involves card data or credential leakage — potentially your company's legal exposure. Buying doesn't just save the 348 hours. It moves the tail risk to an entity that's staffed to handle it. The same logic applies to how a founder buys distribution rather than builds it from scratch, which cover in more detail.
Signal you're weighing | Points toward build | Points toward buy |
|---|---|---|
Would a customer notice or care who built this? | Yes — it's visibly the product | No — it would look identical either way |
What breaks if it's briefly wrong? | An annoying bug, recoverable in an afternoon | Money movement, leaked credentials, legal exposure |
How specific is the requirement? | Documented, unusual, genuinely unmet by any vendor | A preference, an annoyance, or 'we might need this later' |
How long would it actually take? | Days, and the cost of being wrong is small | Weeks to months, per Walling's own 348-hour estimate |
The Stripe Checkout instinct, and why it's correct
Pieter Levels, who has shipped and sold more small profitable products solo than almost anyone publicly documenting the process, has described a consistent pattern in interviews: wire in a Stripe Checkout button rather than build billing infrastructure, and treat almost everything that isn't the product's actual differentiator as something to buy, borrow, or bolt on. That's not laziness. It's the same math Walling did with a spreadsheet, done instinctively, at a pace that only works because he isn't spending two months building a payments system nobody is paying him for. The XenGrowth resource library covers this same buy-versus-build calculus for the marketing stack specifically, at .
The exception that actually proves the rule
It would be a weaker argument if it had no real counter-example, so here's the honest one. Ciphera, a smaller identity-focused vendor, built its own authentication system from scratch rather than buying Auth0 or Clerk — and says so directly, stating plainly that buying 'is almost always the right answer.' Their reason: they needed a specific guarantee, that operators with database access cannot read users' passwords or emails, built on the OPAQUE protocol. No hosted identity platform sells that guarantee, because standard account-recovery flows require holding both pieces of information. That's not a preference. It's a documented, specific requirement that genuinely isn't for sale anywhere, which is exactly the condition under which building the thing yourself is the right call. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
The question is never build versus buy in the abstract. It's whether this specific piece is the reason a customer pays you, or just a wall standing between you and the reason.
Most founders who talk themselves into building auth from scratch don't have Ciphera's situation. They have a minor annoyance with how a vendor's dashboard looks, or a vague sense that owning the whole stack is more 'real' engineering, or — the honest version — they simply find building it more interesting than configuring someone else's SDK. That's a legitimate personal preference. It is not a business reason, and conflating the two is how a two-week distraction turns into a two-month one.
A working test, not a rule
Ask whether this is the reason a customer pays you. If removing it wouldn't change why someone chose your product over a competitor's, it's plumbing, not product
Ask what happens when it's briefly wrong. A bug in your core feature is bad. A bug in your auth system that lets one account read another account's data is a different category of bad, with legal exposure a startup rarely has the runway to survive
Ask if the requirement is documented and specific, or just a feeling. 'I don't like how their dashboard looks' is not the same claim as 'no vendor supports the exact data guarantee our customers require,' even though both feel like reasons to build
Price the real hours, not the imagined ones. Walling's 348-hour estimate from 2008 is a reasonable floor for a genuinely full build today; multiply that by your own real hourly value, not the number that makes building sound free
Revisit the decision at scale, not before it. The point at which owning your own payments or auth stack becomes economically sane is real — it's just almost never in year one, and 'we'll need this eventually' is a bad reason to build it now
The uncomfortable part of this argument for a lot of technical founders is that it says the most satisfying engineering work — the kind with real architecture decisions, real edge cases, real craft — is frequently the work you shouldn't be doing yet. That's not a knock on the craft. It's a reminder that a company's first year has exactly one job, which is proving someone will pay for the thing that's actually yours, and every hour spent perfecting someone else's already-solved problem is an hour not spent proving that.
When the answer actually flips later
None of this is permanent. Companies that reach real scale frequently do end up building their own version of something they bought early — payments infrastructure at a large enough transaction volume, or an internal identity system once a vendor's per-seat pricing outgrows what it once saved. That transition is real and sometimes correct. The mistake isn't building it eventually. It's building it in year one, before there's a company, a customer base or a revenue number large enough to justify the hours against, on the theory that you'll need it someday so you might as well start now. 'Eventually' is not 'now,' and the gap between the two is exactly the runway a fragile company can't afford to spend on infrastructure nobody is paying for yet.
Further reading from XenGrowth
Where this work meets go-to-market
The build-versus-buy question doesn't stop at engineering infrastructure — it runs straight into how a company measures and grows revenue too. publishes operator guides on the go-to-market side of that same discipline.
Further reading from XenGrowth
Where this work meets go-to-market
If what should a technical founder not build themselves is part of a growth programme rather than a standalone build, is the companion reading.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If what should a technical founder not build themselves is part of a growth programme rather than a standalone build, XenGrowth's growth operations team is the companion reading.
Walk through a piece of infrastructure you're considering building in-house. The outcomes aren't a strict ranking — ties break toward whichever fits first, so the order below is a real decision, not decoration.
