Buy vs. Build: Technical Choices That Save Startups Months

There is a question I often get asked by founders and developers: "But you build these things in-house, right?"

No. Or rather: not all of them. And the most important part of my job as CTO is deciding which ones not to build.

In a studio like ours, where we develop multiple products in parallel, development time is the most expensive resource we have. Every week spent rewriting something someone else has already solved (and solved better than we would in a month) is a week taken away from the only thing clients pay us for: the value of the product.

The "Homemade" Myth

In tech culture, a stubborn prejudice persists: building everything internally is synonymous with seriousness, control, and independence. Buying, on the other hand, sounds like a shortcut. Almost an admission of inability.

The reality is the exact opposite. A non-core component built in-house is not an asset: it is a debt that accrues interest every day. Security updates, compatibility, scalability, those edge cases you only discover when you have real users in production (and always at the worst possible time). An authentication system written from scratch isn't written once: you maintain it forever.

So the right question isn't "are we capable of building it?" (almost always yes), but "is this component the reason customers pay us?". If the answer is no, the best code is the code we don't write.

And AI Has Made Everything Harder

Up until a couple of years ago, this decision was relatively simple because building was expensive and it was obvious to everyone. Not today.

With AI coding tools, a good developer achieves in an afternoon what used to take weeks. And so the temptation becomes very strong: why pay a monthly fee to Clerk if Claude can generate an authentication system for me in an hour? Why integrate an external provider when "the prototype already works"?

The problem is that AI has slashed the cost of writing code, not the cost of owning it. The authentication prototype done in an afternoon works, sure. Then comes token refresh, rate limiting, key rotation, the user who registers with Google and then tries to log in with email and password, the penetration test asking how you handle sessions. All stuff that a specialized provider has already gone through, and that you just brought into your own house.

Paradoxically, therefore, the easier AI makes it to build, the more discipline is needed in deciding what not to build. The technical barrier has lowered; the economic one (maintenance, security, opportunity cost) has stayed exactly where it was. It's just easier not to see it now.

How We Decide at Startup Bakery

The criterion we apply to every new startup in the portfolio can be summarized in a few lines:

• We build what differentiates: business logic, user experience, domain-specific intelligence. That is where competitive advantage is born, and you don't outsource your competitive advantage.

• We buy what is a commodity: authentication, email delivery, notifications, integrations with external providers. Problems already solved by companies that do only that, with dedicated teams and years of edge cases behind them.

• We evaluate the total cost, not the price: An external service has a fee visible on the invoice. An internal component has a cost you don't see anywhere: hours of maintenance and, above all, everything else you are not building in the meantime.

It sounds trivial written like this. Applying it with discipline is anything but, because the "come on, let's just do it ourselves, it'll take a little while" is always around the corner. And "a little while" is never a little while.

Two Concrete Examples: Authentication and Notifications

Take the most classic case: authentication. Login, sessions, Google or Microsoft access, password recovery, two-factor authentication. It's a domain where mistakes cost dearly and where, frankly, there is nothing to invent: platforms like Clerk or Auth0 have been doing only this, for years, with dedicated security teams. Building it in-house means becoming responsible for life for one of the most attacked pieces of any application. In our products, we don't write authentication: we integrate it, and in a day we have something that internally would take weeks just for the first version (the naive one, which then has to be rewritten).

Same goes for notifications. It seems like the classic "easy" component: you send an email, at most a message. Then the real problems arrive: deliverability, multi-language templates, the user who wants to receive alerts on one channel and not another, retries when a provider is down. Orchestration platforms like Courier have already solved all this. We just need to decide what to tell the user and when, which is the only part where our product comes into play.

And what do we build, then? Everything else: the domain logic, the reason the customer chooses our product and not another. The criterion is always the same: the team's talent goes where no supplier can reach, because no supplier knows our customers' problem better than we do.

The Unexpected Benefit: Compliance

There is also an advantage to this approach that is rarely seen in tech posts, but for those in B2B, it's worth its weight in gold.

One of the startups in our portfolio accesses its users' email data using the most sensitive Gmail scopes. To do this, Google requires CASA (Cloud Application Security Assessment) certification: security questionnaires, application scans, documentary evidence. A serious process, as it should be.

Now, facing such a certification with an entirely homegrown stack means proving the security of every single piece: how you store credentials, how you manage sessions, how you encrypt data. With a stack of specialized providers, a good part of that perimeter is already covered by companies that live and breathe security, and that passed those audits at the highest levels before we did.

Result: we obtained CASA in timeframes that would have been unthinkable on our own. And without CASA, no access to Gmail data; without data, no product. In short, buy vs. build choices don't just decide how fast you develop: they decide how fast you can hit the market.

When Building Actually Makes Sense

This is not an apology for total outsourcing, let's be clear. Building remains the right choice when the component is the product: outsourcing it would mean outsourcing your differentiation. Or when dependence on a supplier becomes a concrete risk: costs growing faster than revenue, or someone else's roadmap constraining yours. And then there are volumes: what makes sense to buy for 100 customers might make sense to build for 10,000. But that is a good problem to have, and you face it when it arrives. Not before.

Even the exceptions, however, confirm the method: the decision must be made explicitly every time, looking at the numbers. Not out of inertia, nor out of engineering pride.

The Best Code is the Code You Don't Write

At Startup Bakery, every startup is born from a recipe, and in every recipe, there are ingredients we prepare ourselves and ingredients we choose from the best suppliers. No serious pastry chef mills their own flour: they choose it well, and put their talent where it makes a difference.

The same goes for a CTO. Technical maturity is not measured by how much code you write. Today less than ever, given that AI is increasingly taking care of writing it. It is measured by how much value you deliver. And sometimes the fastest way to deliver it is having the courage not to write a single line.