Killer SaaS: the method to clone any SaaS in a single day

📺 This article is based on the full video. Watch it here: https://mkc.sh/killer-saas

A few weeks ago I recorded a video announcing the end of single-feature SaaS products. Those small tools a developer would ship over a couple of weekends to generate some side income. Today anyone with a coding agent can rebuild them, so that model is over.

We assumed the more advanced SaaS products were safe. They are not. With the right method, you can reproduce almost any type of SaaS. That is what I show in this video.

The trigger: 1,800 dollars a year for nothing

I have a platform hosting my courses, the ones you know: Next Mastery, React Mastery, and the others. It costs me more than 1,800 dollars a year.

The problem is that I gave those courses away for free. They no longer generate any revenue, but they keep costing me 1,800 dollars every year.

That is exactly the kind of situation where rebuilding the tool in-house becomes profitable.

The goal is not to compete with Podia

Let me be clear about the intent. The goal is not to build a SaaS and go head to head with Podia or Teachable on their market.

The goal is to have internal tools that save money. The distinction matters: an internal tool needs no customer support, no marketing, no multi-currency billing, no compliance at scale. It only has to do the job you need, for you.

Why I built a dedicated method

I have tested many agentic methods. Super Power, Every Single Code, Matob, GStack, Spec Kit, agency-style systems. I talk about them often on the channel.

They are very good methods, and they enable real engineering. But they are general purpose. None of them is built for one precise goal: reproducing an existing SaaS, fast, at production quality.

That is why I built Killer SaaS, a method that reproduces almost any type of SaaS in roughly one day.

The workflow, step by step

The method works per user story. For each one, the agent runs the same phases:

1. Research: it looks for what the story needs. Routes, components, exact field details, data structure.
2. Design: it produces the matching screens.
3. Detailed planning: it breaks down the implementation.
4. Execute: it writes the code.
5. Review: it reviews its own work.
6. Ship: it opens the pull request, merges it, and the change goes to production.

At any point in the workflow, one command tells you where things stand:

ks status

ks for Killer SaaS. You immediately see the progress of every story.

Breaking work into user stories

The first step goes through a dedicated skill, agentic-stories, which turns the requirement into usable user stories. Each story is written in the classic format, "as a trainer, I want to…", with its acceptance criteria.

Commands, not prompts

I work a lot through commands. The method is built on Claude, but it is adapted for Codex: every command exists with a different target. Claude is the default, and you get the Codex variants, per project or global.

The boilerplate, what actually saves the day

Speed does not only come from the agent. It mostly comes from the technical foundation already being there. What the boilerplate includes:

• Payments: the Stripe SDK
• Authorization: CASL
• Validation: Zod
• Internationalization: i18n with next-intl
• Forms: React Hook Form
• Image storage: Supabase
• Jobs: Inngest
• Unit tests and end-to-end tests

End-to-end tests, the part I was underestimating

I used to write end-to-end tests out of professional conscience. I told myself it was good to have them, nothing more.

What changed: once end-to-end tests are in place, Claude knows exactly how to use them. It can log in, create data, run a full journey. They become a verification tool for the agent itself, not just a box to tick.

The layered structure

The repo follows a classic but strict split, under src/app:

• the services layer, split by authentication, authorization, facades, validations and validators;
• the DB layer, with models and repositories.

When the agent implements a story, it does go through the service layer and the facade, exactly as the boilerplate specifies. It does not get to decide the architecture: the architecture is already set.

Parallelism

This is what changes your relationship to time. Research and design phases are not run story after story: all user stories run in parallel.

While the agent works on one story, it is also working on the others. That is what makes a day possible instead of a week.

The result

By the end of the cycle, more than 20 pull requests had been merged, generated automatically by Claude.

The application runs: light and dark theme, course catalogue, profile page, and course purchase straight through Stripe. With the Stripe test card, payment works end to end.

What is not perfect

I would rather say it. The result is not finished in the product sense of the word.

Visual work remains: images are not in place, displayed data is still test data, and some screens deserve another design pass. The design system phase should go further on the mockups.

One methodological point I would do differently: it is better to handle the design system and each screen separately rather than launching everything at once. Without the research phase upstream, the agent does not know the exact field details, and it produces approximate mockups.

What to take away

Reproducing an advanced SaaS is no longer a matter of months of development. It is a matter of method, of a prepared technical foundation, and of an agent allowed to work in parallel on well-split stories.

The real calculation is not "can I beat Podia". It is "is this annual subscription still worth the day of work it would take me to replace it".

In my case, at 1,800 dollars a year for a service I only use a fraction of, the answer was no.

Going further

📺 The full video: https://mkc.sh/killer-saas