Build, buy or borrow: deciding fast without the regret.

A four-person team spent six weeks building their own email-sending infrastructure. It worked. It was also six weeks they did not spend on the product only they could build, solving a problem a twelve-dollar-a-month service had already solved better than they ever would. The code was a trophy for a race nobody was running.

Every week, engineers at startups face the same fork: build it ourselves, buy something off the shelf, or borrow open source. Get this decision right repeatedly and you move at a pace larger competitors cannot match. Get it wrong and you drown in maintaining things that were never your advantage.

Start with one question: is this our edge?

The cleanest filter is whether the thing is core to why customers choose you. Your unique product logic, your special algorithm, the experience that sets you apart: build those, because they are the company. Authentication, email, payments, logging, analytics plumbing: almost never your edge, almost always better bought. If a vendor's entire company exists to do this one thing, you will rarely beat them at it as a side quest.

The hidden cost of building is not building

Founders compare the price of a tool against the cost of a few days of engineering and conclude building is cheaper. They forget that you do not build software once. You maintain it forever. Every system you own is a system you patch, secure, scale, debug at 2am, and explain to the next engineer. The sticker price of "buy" looks expensive next to a weekend of work and cheap next to three years of ownership.

When buying, guard against lock-in

Buying is usually right, but go in clear-eyed. Favour tools with clean ways to export your data and standard interfaces you could swap out. The danger is not paying a vendor. It is building so deeply around one that leaving becomes impossible when their price triples or their quality slips. Borrow the leverage without handing over the keys.

Borrowing open source is a real commitment

Open source feels free, and the licence often is, but adopting a library is still a decision with a cost. You inherit its bugs, its security issues, its maintenance pace and its licence terms. Choose well-maintained projects with active communities, and understand the licence, especially how it interacts with your own product. Our IP and copyright guide covers why the licence in your stack matters more than founders expect.

The fastest startup teams are not the ones who build the most. They are the ones who are honest about where their advantage actually lives, pour their energy there, and refuse to spend their scarce engineering time rebuilding what the rest of the world has already solved.