Once a founder has settled on a stack, the next decision arrives before a single feature does, and it is the one that quietly decides how long the whole build takes: what to write and what to rent. Every product needs authentication, payments, email, file storage, search, and a dozen other capabilities that are not the reason the product exists. The temptation is to build them, because building is what engineers do and because owning your own auth feels like a badge. It is almost always the wrong call. The stack decision is about the substrate you build on, which we covered in how we choose a tech stack. This is the decision one layer up: how much of the product you should build at all.
Build only the thing that is the reason the product exists
There is exactly one part of a first product that has to be yours: the part that is the actual bet, the thing a founder can describe in a sentence and that nobody can buy off the shelf. Everything else is plumbing. The whole job of scoping an MVP is to spend your build budget on that one differentiator and to rent the rest, because the rest is not where you win or lose. A founder who spends three weeks hand-rolling a login system has spent three weeks not building the reason anyone would want the login in the first place. We ask one question of every capability on the list: is this the thing we are here to prove. If the answer is no, we are looking for something to rent.
The commodity layer is cheaper to rent than the meeting to discuss it
A whole class of problems has been solved so thoroughly, by companies whose entire business is solving them, that rebuilding them is not thrift, it is waste. Authentication, payments, transactional email, error monitoring, and file handling are the obvious ones. These are not hard because someone was lazy. They are hard because they have deep edge cases, security surfaces, and compliance obligations that a small team cannot staff and should not try to. The provider who does this all day has already survived the outages and the audits you have not imagined yet. Renting that is not a shortcut around the work. It is buying a team of specialists for the price of a subscription, and the alternative is being your own worst specialist on your slowest timeline.
Buying is not free, and pretending it is causes the mess
The honest version of this argument admits that buying has a real cost, just a different one. A rented service is a dependency: it has a price that can change, an API that can break, limits you will eventually hit, and data that lives somewhere other than your database. The failure mode is not renting, it is renting carelessly, wiring a vendor so deep into the product that swapping it later means surgery. So we buy behind a seam. The payment provider sits behind our own thin interface, the email service behind a function we own, so that the product talks to our code and our code talks to the vendor. That way a price hike or a shutdown is a bad afternoon, not a rewrite. Renting well is a discipline, not an absence of one.
The trap is the thing that is almost your product
The hard calls are never the obvious ones. Nobody agonizes over whether to build their own email delivery. The trap is the capability that sits right next to the differentiator and feels like part of it. A team building a scheduling product will be tempted to build their own calendar sync, because scheduling is the point and sync feels close to the point. It is not. Calendar sync is a brutal, well-mapped commodity that a specialist API does better than a first-time team ever will, and the actual product is the scheduling logic on top. Draw the line precisely: your differentiator is usually narrower than it feels, and the ring of things around it that feel essential is mostly rentable. Getting that boundary wrong is how a six-week MVP becomes a six-month one.
Reversible decisions get made fast, not perfectly
A build-or-buy call does not have to be right forever, it has to be right for now, and most of these are cheaply reversible if you build the seam. That changes how much deliberation each one deserves. If renting a search service today lets you ship this month, and moving to your own search later is a contained project behind an interface you already own, then renting now is not a compromise, it is the correct sequencing. Build the thing you cannot easily change later, which is usually your differentiator and your data model, and rent the things you can swap when you have the evidence to justify the effort. Most founders invert this: they agonize over the reversible calls and rush the ones that actually lock them in.
One set of rented tools compounds across projects
Because we make this decision the same way every time, we end up renting from a small, deliberate set of providers we know cold. We know their failure modes, their limits, and how to wire them behind a clean seam on the first try, so the commodity layer of a new build is close to solved before it starts. That is the same argument we make about the stack in operational consistency is the real moat: the advantage is not any one clever choice, it is making the unglamorous choices the same proven way on every project so we can spend the saved time on the part that is actually different.
The best code in a first product is the code you did not write
The instinct that building more is building better is exactly backward for an early product. Every capability you rent is a capability you do not have to maintain, secure, and debug at two in the morning, and every line you do not write is a line that cannot break. The measure of a well-scoped MVP is not how much of it the team built, it is how little: a sharp, owned differentiator surrounded by boring, rented infrastructure that just works. That is also the instinct behind knowing which builds should not happen at all, which we get into in when not to build. If you are staring at a feature list and cannot tell which parts are your bet and which are plumbing, tell us what you are trying to prove and we will help you draw the line.