Why every MVP we ship starts on a boilerplate

Almost every product we build at FeatherFlow needs the same things in the first week. People have to sign up and log in, someone has to pay, and the app has to send emails like a welcome mail, a password reset and a receipt. None of that makes a product special, but all of it has to work and all of it takes time.

So we don’t start from an empty folder. We start from a boilerplate, a starter project where these parts are already built and connected.

Why these parts take longer than you’d think

Login sounds simple until you build it properly. You need password resets, email verification, social login, sessions that expire, and some way to deal with someone signing up twice with the same address. Each of these is small, but together they’re several days of work.

Payments are similar. A Stripe subscription is a lot more than a “pay now” button, because most of what happens to it happens later: it renews, a card gets declined, a trial ends, someone cancels. Stripe tells your app about these events through webhooks, and its own docs say a subscription integration has to handle them because most subscription activity is asynchronous. If that goes wrong, people either keep access after they stop paying or lose it while they’re still paying.

A good boilerplate has already run into all of this. Someone else found the edge cases, and we don’t have to find them again on a client’s budget.

“But Claude Code can just write all that”

This is what I hear most often now, and it’s partly true. Claude Code can write a login flow or a Stripe integration in an afternoon, and it usually looks fine. We use it every day ourselves. I still start on a boilerplate, for a few reasons.

Generated code is new code. Nobody has run it in production yet, nobody has hit its bugs, and nobody has paid for its mistakes. A popular boilerplate has been used by hundreds of projects before yours, and the problems with renewals, failed payments or duplicate accounts have mostly been found and fixed. With auth and payments, that difference matters, because the bugs there cost money or leak data.

The AI also only builds what you ask for. It will handle the cases you mention, and it often won’t handle the ones you didn’t think of, like a webhook arriving twice or a trial ending while the card is expired. To ask for those, you have to already know them. And to check whether the generated code gets them right, you need the same knowledge you’d need to write it yourself. A boilerplate puts the cases in front of you, already solved, so you only have to read and understand them.

Then there’s time. Building and debugging auth and billing with an AI still takes days of prompting, testing and fixing. With a boilerplate, that part is running in an hour, and we spend the AI sessions on the core feature, where they actually make a difference.

The biggest reason is that the two work best together. Claude Code is much better in a codebase that already has clear structure and conventions than in an empty folder. A boilerplate gives it that: a database layer, a way to do API routes, components it can copy from. New features then look like the rest of the code instead of a different style in every file. So for us the question isn’t boilerplate or AI. We start on the boilerplate and build everything on top of it with Claude Code.

What we do with the time

We don’t save the weeks to work less. We put them into the parts that decide whether the product works.

Most of it goes into the core feature, the thing people actually come for. A working login and payment flow also means we can show a real product to real users earlier, and we use that. The rest goes into onboarding, empty states and the first few minutes in the app, because that’s when people decide whether to stay.

The downsides

You take on someone else’s decisions about the database, the framework and the folder structure. If the kit uses a database you don’t want, switching later is real work, so we only pick starters built on the stack we’d choose anyway.

You also still have to understand the code. Code you didn’t write is still code you’ll be debugging, so before a boilerplate goes into a client project, someone on the team reads through the auth and billing parts.

Kits also get old. Dependencies move fast, and a starter that hasn’t been updated in a year can cost you more than it saves. And they all look the same out of the box, so the default landing page is the first thing we delete.

How to pick one

That’s a big part of why I started BoilerplateHub, a directory where you can compare starters by stack and features. When I look at one, I check whether it uses the stack I’d pick anyway and whether it’s still being updated. Before buying, I read the auth and payment code, and if I can’t follow it, I keep looking. If you build for clients, check the license too.

A boilerplate won’t make the product good. It just means we spend the first weeks on the product instead of the login form.