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 need to sign up and log in. Someone has to pay. The app has to send emails: a welcome mail, a password reset, a receipt. None of this is what 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 wired together.

What “solved problem” really means

Login sounds simple until you build it properly. Password reset, email verification, social login, sessions that expire, someone who signs up twice with the same address. Each one is small. Together they’re days of work.

Payments are the same. With Stripe, a subscription is not a single “pay now” button. Most of what happens to a subscription happens later, in the background: a renewal, a failed card, a trial that ends, someone who cancels. Stripe tells your app about these events through webhooks, and its own docs say a subscription integration needs to handle them, because most subscription activity is asynchronous. If you get this wrong, people keep access after they stop paying, or lose access while they’re still paying. Both are bad.

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

Where the saved weeks go

The point isn’t to work less. The point is to spend the time on the part that actually decides whether the product works:

The core feature. The one thing users come for. This is where we want our best thinking.
Talking to users early. A working login and payment flow means we can put a real product in front of real people sooner.
Polish where it counts. Onboarding, empty states, the first five minutes. That’s where people decide to stay or leave.

The honest downsides

Boilerplates aren’t free money. A few things we’ve learned to watch for:

You inherit someone else’s choices. Database, framework, folder structure. If the kit uses a database you don’t want, moving away later costs real work. We pick the starter based on the stack we’d choose anyway.
You still have to understand it. Code you didn’t write is still code you have to debug. Before a boilerplate goes into a client project, someone on the team reads through the auth and billing parts.
Kits get old. Dependencies move fast. A starter that hasn’t been updated in a year can cost more than it saves.
Everything looks the same. The default landing page is the first thing we throw away.

How to pick one

This is a big part of why I started BoilerplateHub, a directory where you can compare starters by stack and features. My short checklist:

Does it use the stack you’d pick anyway?
Is it actively maintained? Look at the last few updates.
Read the auth and payment code before you buy. If you can’t follow it, that’s a warning sign.
Check the license, especially if you build for clients.

A boilerplate won’t make your product good. It just clears the way, so the hard and interesting part gets the time it deserves.