Lakshmi Narasimhan
ESSAY

How to Build a SaaS with Claude Code in a Weekend (Not a Quarter)

I caught up with one of my mentees last weekend. Just talking shop. He’s a solid developer, he’s got the itch to build a side project, and he’s brand new to agentic coding. Somewhere in that conversation I realized I was reciting an entire playbook off the top of my head — so I’m writing it down. If you can write code and you’re staring at Claude Code wondering how to actually build and ship a SaaS with it, this is for you.

A quick word on why now, before the how. Two reasons, and you’ve heard at least one:

  1. AI is eating the jobs. You can’t open your phone without someone reminding you. Enough said.
  2. The AI subsidy is going to end. Right now you’re building on frontier models that cost the labs more than they charge you. That window closes. I wrote about this here

Maybe both happen. Either way the move is the same: build the muscle now, while it’s cheap and you still have an edge.

1. What to build

Scratch your own itch. Do not spend three weeks “researching the market” to discover what people want. If you have a problem an app would fix, give yourself permission to build it. We’ll worry about market size after it ships.

Market research used to be load-bearing because building was expensive and being wrong was catastrophic — months of work, real money, dead on arrival. That math is gone. You can ship an app over a weekend now. The cost of being wrong is one wasted Saturday.

Paul Graham makes the sharper version of this point: build what you want, because — as he writes in How to Earn a Billion Dollars — “your own needs are uniquely valuable, because your needs predict future demand.” You’re not guessing what strangers want. You’re scratching an itch you can actually feel.

I’ve written about finding an idea and shipping it in a single sitting — here.

2. Know where you’re standing

Be honest about your starting point: do you have real development experience, or do you need to ramp up first? Here’s what I’d master before letting AI build for you

Yes, there are people on the internet shipping apps with zero coding background. Maybe. But if you can’t read what Claude Code writes, you can’t steer it — and you’ll feel that the first time it confidently drives into a wall. You don’t need a CS degree. You need enough of a mental model to call BS. The good news: you can learn development from Claude Code while you build with it. Learning and building at the same time is completely legitimate — it’s how I pick up half the things I use.

3. How I actually build

There’s no one true way. This is what works for me; your mileage may vary.

First, the unglamorous part: get the Claude Code Max plan. The $100 tier, or the $200 one if you can swing it. You cannot build anything meaningful on the cheap plans, and you’ll discover exactly why about four hours into your first real session. Don’t flinch at the price — it’s still cheaper than a tutor or a freelancer, and it doesn’t take lunch breaks. Plus the quality is consistently good.

Why Claude Code and not [the benchmark-topping model of the week]?

Because building a startup is already exhausting, and you do not have spare energy to spend benchmarking models and sharpening tools instead of shipping. Pick what works and stick with it.

Codex is a close second — genuinely good, and I keep it around. But Claude Code stays a step ahead for actually building apps, and after working with both, I reach for it first. Use both if you like. Just don’t turn tool selection into the project.

Boring choices win

Freeze your stack early — backend, frontend, database. 80% of it is identical across every app you’ll ever build, so stop re-deciding it every time. And don’t obsess over scale and optimization. Those are problems you earn by being successful. Good problems. You don’t have them yet.

4. Specs and context engineering: the part that decides everything

Two things determine whether you get your money’s worth out of Claude Code:

  1. The specification
  2. Context engineering

The spec

The more specific you are, the better the output. “Build a to-do app” gets you slop. “Here’s the auth flow, here’s the data model, here are the exact features” gets you something you can use. Spend real time here, before a single line of code gets written. More on this

The move that works best: make Claude Code interview you about the spec. If you can’t answer its questions, you can’t articulate the feature — and if you can’t articulate it, you can’t build it. By the time the spec is done, the MVP should have zero grey areas.

Context engineering

Even the best frontier model starts coding like it’s three drinks deep once the context fills up. So you manage it.

This takes me back to my assembly-language days — limited registers, limited memory, every instruction written with one eye on the resources you didn’t have. LLM context is that same constraint in new clothes. You get roughly 200k tokens, and that’s nowhere near enough to hold your whole app in its head at once.

So: one task per session. Two at the absolute most. Which means breaking the spec into session-sized tasks and tracking what’s done, what’s in flight, what’s blocked, and what depends on what.

A markdown to-do file is a terrible way to do this and a worse use of your time. I use beads. Adopted it early, still on it. It’s the fix for an agent that wakes up every morning with no memory of what you did yesterday.

This practice is also a lot kinder for your token limits.

Two flavors:

Use either. I landed on beads-rust. Pick your poison.

You also need memory across sessions. You’ll remember you fixed a bug two weeks ago; the model in today’s session won’t, and it’ll cheerfully hand you a wrong answer when you ask “did we already fix this?” I use claude-mem for that — thedotmack/claude-mem.

Point a Claude Code session at both repos and it’ll install them for you. (Yes, these work with Codex too — but again: shipping or tuning? The clock is running.)

Remember that spec? Hand it to your beads skill and it breaks down into a clean task list. Ask Claude to pull the high-leverage beads and start there — never more than two in flight.

Your CLAUDE.md matters

Treat it as a compass, not a second spec. The practices that matter (write the tests first), how the app deploys, the handful of goals you’re aiming at. Keep it light — cramming a novel into CLAUDE.md is the fastest way to make Claude dumber.

One more tool

ccstatusline. Configure it to show your remaining context percentage. It’s the fuel gauge that tells you whether to keep driving or pull over and start a fresh session.

Then it’s rinse and repeat: feed beads to Claude, do the manual QA yourself, close the bead, next one. A few sessions in, a sliver of a working MVP starts to emerge. When you’re happy with it, you ship.

5. Deploying it (without the Kubernetes tax)

I was a Kubernetes guy for years. Deployed everything on it. I no longer recommend it for solo developers — I explain why here. It still has its place and time; your weekend project is neither.

Use Kamal instead. Think of it as the compromise between Docker Compose and Kubernetes — Compose’s simplicity, enough of Kubernetes’ robustness, none of the YAML despair.

I’m also building VMKit to make this part disappear entirely — deploy without learning the nitty-gritty unless you want to.

Then there’s the wiring you don’t think about until it bites: monitoring and ops (I run mine through MCPs — the $30 stack), payments (Stripe; if you’re in India, Dodo Payments), and distribution — marketing and positioning, which is a beast all its own. Each of these deserves its own post.

TL;DR

  • Build for your own itch. Shipping is cheaper than market research now.
  • Get the Claude Code Max plan ($100, ideally $200). Don’t tool-shop.
  • Spend your time on the spec — let Claude interview you until there are no grey areas.
  • Engineer your context: one task per session, tracked with beads, remembered with claude-mem.
  • Keep CLAUDE.md light. Watch your context gauge.
  • Deploy with Kamal, not Kubernetes. Wire payments and monitoring last.
  • The whole thing is a weekend, not a quarter.