MakerKit's Philosophy: Foundations Over Features

Someone asked on X this week how MakerKit stacks up against a newer SaaS boilerplate. The pitch for the competitor was the usual: a long list of pre-built features.

My reply was:

More features = more bloat. The lack of features in MakerKit is very, very intentional.

This article is the longer version of the tweet, because the philosophy behind them is the reason MakerKit exists and the reason customers stay.

The pitch most boilerplates make

Look at almost any SaaS boilerplate marketing page and the pitch is the same. A grid of icons. Twenty checkmarks. Multi-LLM, RAG, agents, token credits, referrals, affiliates, GDPR, PWA, i18n, an admin panel, an analytics dashboard, a blog module.

The implied promise: the more you get out of the box, the closer you are to launch.

That promise made sense for a long time. Writing code was the bottleneck, and a boilerplate that wrote thousands of lines of code for you was genuinely valuable. The math worked.

The math does not work anymore.

Code is cheap. Conviction is not.

In 2026, code is the cheapest thing in your stack. Claude, Codex, and Cursor will write a referral system, an affiliate dashboard, or a GDPR consent flow in an afternoon. A boilerplate that ships those features pre-built is selling you something you can now generate yourself in a few hours.

What stays expensive is everything else.

The shape of your data model. The decisions about how tenants are isolated. The pattern your team and your AI agents will repeat thousands of times across the codebase. The vendor you tied yourself to before you knew what your business actually needed. The 200 lines of someone else's affiliate logic that you have to either rewrite or live with.

A SaaS boilerplate's job in 2026 is not to write code for you. Its job is to make the decisions you cannot afford to get wrong, and stay out of the way on everything else.

That is what MakerKit is. The foundations are deliberate. The features are not.

Restraint is the new skill

Here is the thing nobody tells you when you start a SaaS product in 2026.

I could ship ten features a day with AI. What matters is choosing what NOT to ship.

It is genuinely too easy to get carried away. You can ship features faster than you make coffee. Open Claude Code, describe a feature, accept the diff, ship it. Repeat until the codebase is a swamp and you are not sure which half of the product anyone actually uses.

I do this myself, and I have to consciously stop. The dopamine of shipping is real, and AI multiplies it. The pull request lands in minutes. Tests pass. You feel productive. And three months later you are maintaining a feature nobody asked for, in code nobody remembers writing, that an AI agent now has to navigate every time you ask it to change something else.

Every feature you add is a permanent decision. A surface area you maintain. A piece of code your future self has to read, your agents have to reason about, and your customers have to navigate. Adding features used to be hard, so the discipline of saying no came naturally — you just ran out of hours in the week.

That governor is gone. The cost of shipping a feature has collapsed. The cost of having a feature has not. It still has to be designed, debugged, supported, documented, and integrated with the rest of the product for as long as it exists. Multiply that by the speed at which AI can produce them and you get codebases that grow faster than anyone can hold them in their head.

The founders who win in this era will not be the ones who ship the most features. They will be the ones with the taste and the discipline to ship the right ones. And the boilerplate that helps with that is the one that hands you a foundation and trusts you to add only what your product actually needs.

MakerKit ships what we believe every SaaS needs. We deliberately leave the rest to you. That is not a gap in the product. That is the product.

An afternoon, not four weeks

Here is something the AI hype tends to skip: understanding your codebase still matters.

You can have Claude write every line of your application and it still has to be your codebase. You will debug it at 2am. You will explain it to a new hire. You will decide what to change when a customer reports a bug. You cannot do any of that if the codebase is a 200,000-line maze you bought from someone else and never read.

This is the part of feature-stuffed boilerplates that nobody warns you about. The more they ship, the more you have to learn. Every pre-built module is code you did not write but are now responsible for. Every "free" feature is a chapter you have to read before you can confidently change anything next to it. Onboarding to a maximalist boilerplate is a multi-week project, and most teams quietly give up halfway through and just hope the parts they did not read keep working.

MakerKit is small enough that you can learn the whole thing in an afternoon.

That is not an accident. That is a feature.

You read the monorepo layout once and it stays in your head.
You learn one way to write a Server Action and you have learned all of them.
You read one feature package and you understand the shape of the rest.
Your new hires are productive on day two, not week four.
Your AI agents have a small, consistent prompt to learn from, which means their first attempt is usually the right one.

I do not want you to spend four weeks figuring out what you bought. I want you to spend an afternoon reading the kit, a week building the parts of your product that are actually yours, and the rest of the year shipping to customers. That is what a foundation lets you do. A feature catalog gets in the way.

This is also the part that compounds with AI. A codebase you understand is a codebase you can review. When Claude opens a pull request, you need to know whether the diff is right. If half the codebase is a black box you never internalized, you are reduced to trusting the model. If you actually know the patterns, you catch the wrong call in seconds. Comprehension is the new code review skill, and it requires a codebase small enough to hold in your head.

Features are not a moat

This is the part most boilerplate authors will not say out loud. A long feature list is not a defensible advantage anymore.

Five years ago, "we ship Stripe billing, multi-tenancy, and an admin panel out of the box" was a moat. Replicating that took weeks. Today, any competent developer with Claude Code can reproduce most of those features in an afternoon. The cost to ship has collapsed, and the value of any individual feature collapsed with it.

When code gets cheap, what is left? The decisions code cannot fix.

The wrong schema choice that compounds for the life of the product.
The auth pattern that turns every new resource into a security audit.
The vendor lock-in that means you cannot switch billing providers without a rewrite.
The inconsistency that makes every new file a coin flip.

None of these show up on a feature grid. All of them are what you are actually buying. The features on the marketing page are a distraction from the choices that will determine whether your product is still maintainable in two years.

If a boilerplate's pitch is "we have more features," it is selling you the cheap thing. The expensive thing is the foundation underneath it.

Pick your stack. We give you the wiring.

Here is the part of MakerKit I am proudest of, and the part that almost never makes it onto a feature comparison table: modularity.

Most feature-rich boilerplates lock you into the author's stack. The pre-built RAG only works with OpenAI. The billing only works with Stripe. The auth only works with Clerk. The emails only work with Resend. If your business calls for a different vendor, you are either rewriting the integration or fighting the codebase forever.

MakerKit is built the opposite way. You choose the SaaS providers. We give you the wiring.

You want Stripe? Polar? Same interface, same UI, same Server Actions. Switching is a config change, not a refactor. You want Supabase Auth or Better Auth? Both ship as first-class kits. You want Resend, Postmark, or your own SMTP? The transport is swappable, the templates are not. You want PostHog or Umami or Google Analytics? Behind the same hook. You want to host on Vercel, Fly, Railway, or a VPS? Portable by default.

The principle is the same at every layer. We do not pick the vendor for you. We define the seam, ship adapters for the common ones, and let you swap when you outgrow the default.

This is what the marketing page of a feature-stuffed boilerplate cannot offer. The more deeply a pre-built feature is wired to a specific vendor, the harder it is to leave. That is the hidden cost of "free" features and it shows up the moment your business stops looking like the boilerplate author's assumptions.

Build what you want, the way you want

This is what foundations buy you that features cannot.

When the affiliate system you need does not match anyone else's affiliate system (and it almost never does), you build the one your business actually has. When your pricing model is not three-tier per-seat SaaS, you ship the model that fits. When your AI feature is not a generic chatbot, you build the product you have in your head, not the product the boilerplate author had in theirs.

A feature-stuffed boilerplate is making a bet on your behalf. It has decided what your commission structure looks like, what your AI product does, what your pricing page contains, what your settings flow assumes. Some of those bets land. Most do not. And when they do not, you are not saving time — you are paying interest on someone else's product decisions.

MakerKit takes the opposite bet. The foundations are opinionated. The product on top is yours. That is the only way I know to build something durable in a world where AI agents can generate code faster than most teams can review it.

What this means for your AI agents

Worth saying directly, because it is the under-discussed half of this argument.

Your AI agents are now a permanent part of your engineering team. Claude Code, Cursor, Codex — they read your codebase, learn its patterns, and reproduce them. That means the codebase itself is now a prompt, repeated thousands of times across thousands of generations.

A clean, consistent codebase with one way to do common things is a prompt that produces clean, consistent output. A feature-stuffed codebase with five different patterns for handling a mutation is a prompt that produces five different outputs, and your team spends its time picking up the pieces.

This is why MakerKit is intentionally boring. One way to write a Server Action. One way to fetch data on the server. One way to handle a form. The repetition is the feature. Your agents will thank you. Your future self will thank you more.

What we ship, and what we don't

To be concrete about where the line sits:

We ship the things that are expensive to get wrong. Multi-tenancy. Account membership and team invitations. Authorization helpers. A billing gateway. Email primitives. The UI kit. The monorepo structure. The patterns. The wiring.

We do not ship the things that encode a business decision you have not made yet. Pre-built AI features (chat, RAG, agents). Referral systems. Token credit ledgers. A built-in CMS that assumes a content model. Pricing pages with hardcoded tiers.

The rule is simple. If the feature encodes your business, do not ship it pre-built — it will be wrong for half the customers. Ship the foundation that lets each customer build the right version of it cheaply.

The honest pitch

Most SaaS boilerplates sell you a long list of features. That sells well, because a long list looks like value.

MakerKit sells you a foundation, a set of opinions about what good looks like, a modular architecture that lets you pick your own stack, and a codebase your AI agents can extend without breaking. That is a harder pitch on a landing page, because it does not photograph well next to a grid of icons.

But it is the pitch that holds up in month six, when you need to ship the feature your business actually needs, with the vendor your business actually picked, in the shape your customers actually want.

If that is the kind of product you are trying to build, MakerKit is built for you. If you want a feature checklist, there are cheaper places to get one — and you will pay for them later.

This is a bloat free place

If you remember nothing else from this article, remember the two lines from the tweet that started it.