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:

• the original, by the author — gastownhall/beads
• beads-rust, a simpler, more stable reimplementation of the spec in Rust — Dicklesworthstone/beads_rust

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.

I’d started x-intel as a SuperX clone — essentially a better analytics dashboard for X. Charts, follower graphs, engagement breakdowns, competitor tracking. The kind of thing where you look at a number, decide you feel bad about it, and close the tab.

And then I was chatting with Claude about the onboarding flow, and I said something like: “when I say onboarding, I mean the app gets my context and goals, then charts a strategy, periodically reviews it, and course corrects.”

Claude’s response stopped me: “That’s a fundamentally different product. Less ‘setup wizard’, more ‘AI strategist that lives in your X account.’“

I stared at that for a while. Then I realized I’d been building the audit view and calling it the product.

The dashboard isn’t the product. The dashboard is what humans look at after the AI already figured out what’s happening.

Build the MCP server first. The dashboard ships itself.

The problem is everyone’s still building it the other way.

What Everyone Is Still Building

Claude Code exists. The MCP protocol exists. Power users are already interacting with SaaS products through AI agents — not because you built that integration, but because they built it themselves using whatever API you exposed. They’re writing CLAUDE.md files that say “use the Stacksweller API to schedule posts” and just… doing it.

This is happening whether you designed for it or not.

The default SaaS in 2026 still ships dashboard-first: database → API → React. Users log in, stare at charts, try to draw conclusions. That model made sense when the only consumer of your product was a human looking at a screen.

That is no longer the only consumer of your product.

You can either build for this intentionally, or have it happen to you messily and then spend six months retrofitting.

The Reframe

Here’s what x-intel actually looks like when you build it right:

Intake — Claude asks who you are, what your niche is, what your X goals are, who your competitors are. You answer in plain English. Claude turns that into a structured profile using the set_profile tool.

Baseline — Claude pulls your current stats, analyzes your last 90 tweets, benchmarks against competitors. All MCP tools calling your data layer. No UI step required.

Strategy — Claude generates a content and growth plan: post frequency, best times, content formats, topics to lean into. Stored back in your database via MCP. The strategy exists before you’ve opened a browser.

Periodic review — A cron job runs weekly analysis, compares performance against the strategy, surfaces what’s working and what isn’t. Claude writes a summary. The dashboard shows that summary.

Course correction — Strategy updates based on data. Again, through tools. Again, before a human looks at anything.

The dashboard in this architecture isn’t the product. It’s an audit log. It shows you what Claude already figured out. Charts are passive — you still have to decide what to do. This tells you what to do, and then does it.

That’s a completely different product. “X-intel is your AI X strategist. Tell it your goals once. It watches your account, tracks competitors, and tells you exactly what to do next.”

That pitch destroys “SuperX but self-hosted.”

How to Actually Build MCP-First

The mechanics are simpler than they sound. Embarrassingly so.

Start by designing your tools for Claude, not for humans. Think about what Claude needs to do the job — not what a human wants to click on. Tool names, parameter shapes, return values should make sense to a language model. get_competitor_engagement_trend(handle, days=30) is better than getChartData(config). One of these tells Claude what it’s getting. The other makes Claude guess.

Here’s the part nobody mentions: if you have a data layer, you have an MCP server 70% built already. Wrap your existing queries as tools. The MCP protocol is just a contract — your database doesn’t move.

You don’t need to build an “AI feature.” You need a system prompt that gives Claude the right context, and tools that give it the right data. Claude is the strategist. Your MCP server is the strategist’s interface to your product. The actual work is thinking clearly about what Claude needs to know — not engineering.

Build the dashboard last, or thin. It’s a view layer. It shows stored strategies, weekly reviews, flagged anomalies. A log of decisions that were already made. Not a decision-support tool.

One Build, Two Audiences

Here’s the payoff that makes this worth doing even if you don’t care about being “AI-native.”

A well-designed MCP server makes your product useful to two completely different types of users with almost no additional work.

The first type opens the dashboard, reads the weekly strategy review, clicks to approve the suggested changes, and closes the tab. Normal SaaS behavior. They don’t know or care that Claude is behind it. They just want outcomes.

The second type connects your MCP server to their own Claude Code setup, writes a CLAUDE.md that describes how they want to use your product, and runs it themselves. These are your power users. They’ll do things with your product you never imagined, and they’ll tell everyone.

You still need the dashboard. Trials convert better with a UI. Not arguing otherwise. But the order matters: MCP layer first, dashboard second. The dashboard snaps on top in a weekend once the tools are solid. The reverse — retrofitting agent-friendly APIs onto a human-optimized interface — takes six months and still feels wrong.

Both audiences are real. Both are valuable. You get both by building the MCP layer correctly from the start, instead of bolting on an “AI integration” later when it’s expensive and awkward.

The dashboard-first founders will get there eventually. They’ll build the dashboard, grow slowly, and then spend six months retrofitting an API that was designed for human consumption into something an agent can actually use.

Or you build the MCP server first, ship a thin dashboard on top, and have both audiences from day one.

The dashboard ships itself. The strategist is Claude. The product is the tools you give it.

Stop building audit logs and calling them products.

Not because $29 was a lot. I’ve subscribed to worse. I have a graveyard of forgotten SaaS products auto-renewing somewhere in my credit card statement, silently draining money for tools I used exactly twice.

No, I stopped because I realized something embarrassing.

This tool was literally just a pretty wrapper around Claude. Same AI I already pay for. Same capabilities. They’d added a nice UI, a payment form, and approximately zero additional value.

I was about to pay $29/month to rent something I could build in an afternoon.

So I closed the tab. Opened Claude Code. And two hours later, I had my own version. No usage limits. No subscription. Mine forever.

That was six months ago. Since then, I’ve built six tools. I’ve eliminated $200/month in subscriptions. And I’ve realized something that changed how I think about this whole “AI is coming for your job” panic.

Everyone’s Worried About the Wrong Thing

My LinkedIn feed is a horror show right now. Every other post is either “AI will take your job” or “Here’s how to survive the AI apocalypse” or some variation of “the robots are coming, repent.”

The advice is always the same. Learn to prompt. Adapt or die. Get your finances in order because disruption is coming.

Maybe it is. I don’t know the future any better than you do.

But here’s what I do know: while everyone’s stockpiling survival advice, I’ve been using those same AI tools to eliminate $200/month in software subscriptions. Tools I was paying for six months ago? I own them now. Forever. Zero recurring cost.

Same technology. Completely different mindset.

Let me show you what I mean.

The Batch PDF Processor I Built Instead of Uploading 50 Files

I had 50 research papers to process. Extract abstracts, pull out key findings, grab any data tables, save everything as searchable markdown.

Sure, Claude can read a PDF. One at a time. Upload, wait, copy the output, upload the next one, repeat 49 more times.

Old me would’ve done exactly that. Or Googled “batch PDF extraction tool,” found something that charges per page, done the math, decided it wasn’t worth it, and then manually uploaded 50 files anyway.

New me? I built a script.

Ninety minutes later, I had a skill that loops through a folder, extracts text and tables from each PDF using PyMuPDF, summarizes each one, and saves structured markdown files. Point it at a folder, go make coffee, come back to 50 organized summaries.

> Process all PDFs in ~/research/papers
[loops through 50 files]
[extracts + summarizes each]
[saves to ~/research/summaries/]

No uploading files one by one. No copy-paste marathon. No usage limits. Runs locally, so nothing leaves my machine.

The tool isn’t “PDF extraction”: Claude already does that. The tool is automation. Batch processing. The boring plumbing that turns a manual 3-hour task into a 5-minute one.

The Video Transcription Pipeline That Changed How I Learn

I’m an infoproduct junkie. Courses, masterclasses, workshops: if someone’s selling knowledge in video form, I’ve probably bought it. My Teachable and Gumroad purchase history is embarrassing. Hours and hours of content sitting in various dashboards, waiting to be watched.

Old me would take notes while watching. Pause, scribble, play, pause, scribble. Retain maybe 30% of it. Forget the rest within a week.

New me? I feed the videos to my video-distill skill. It transcribes everything with Whisper, distills it into readable chapters with Claude, and exports to EPUB.

Two hours of course video becomes a 12,000-word mini-book on my Kindle that I can search, highlight, and reference forever.

Build time: 2 hours.

Previous cost: $50-200 per course for transcription services (or just… not having transcripts and forgetting everything).

The ROI on courses went from “eh, probably worth it” to “this is a no-brainer.”

The Pattern Nobody Wants to Admit

Here’s what I noticed while building these:

Every AI SaaS is a thin wrapper around the same AI you already have access to.

• Batch file processing? A loop + Claude.

• Video transcription? Whisper + Claude.

• Content research? Web fetch + Claude.

• Cross-posting? Template formatting + Claude.

• Writing assistant? Prompt engineering + Claude.

The “product” is convenience packaging. A nice UI, hosting, a payment gateway, customer support. Sometimes that’s worth paying for.

But most of the time? You can build 80% of what you need in under two hours.

I’ve done this six times now. Total build time: about 14 hours. One weekend, spread across a few months.

Total monthly savings: $199.

Total annual savings: $2,388.

Tools I now own forever: 6.

The Real Question Nobody’s Asking

While everyone argues about whether AI will take their job, here’s what I’m thinking:

It’s not AI vs humans. It’s humans with AI vs humans without.

The lawyer who refuses to use AI for contract review loses to the lawyer who uses it and handles 5x more clients.

The developer who doesn’t use AI for code generation loses to the developer who does and ships features in days instead of weeks.

The writer who thinks AI is “cheating” loses to the writer who uses it for research and drafts 10x more content.

The people who lose their jobs to AI won’t be the ones whose work AI can theoretically do.

They’ll be the ones who didn’t use AI and got outpaced by someone who did.

What I Actually Do Instead of Panicking

I audit my subscriptions. Every few months, I go through my recurring charges and ask: “Is this just an AI wrapper?”

If yes, I build a replacement. If the replacement covers 80% of my use cases, I cancel the subscription.

Here’s my current hit list:

• Batch PDF processing: replaced manual uploads with pdf-reader skill (90 min)

• Video transcription: replaced $50-200/course services with video-distill skill (2 hours)

• Ebook formatting: replaced $30/book services with epub-builder skill (1 hour)

• Content research: replaced $29/mo tools with compose skill (3 hours)

• Cross-posting: replaced $50/mo tools with distribute skill (2 hours)

• Writing assistant: replaced $20/mo Sudowrite etc with fiction-writer skill (4 hours)

Not everything is worth building. QuickBooks? Keep paying. Complex Zapier automation with 50 integrations? Probably keep paying. Hosted databases? Definitely keep paying.

But simple AI wrappers that just call Claude with a prompt and charge you monthly for it? Those are dying. You can own that.

This Is What Leverage Actually Looks Like

When you own your tools, you can modify them to fit your exact workflow. Combine them in ways SaaS products can’t. Build competitive advantages nobody else has.

My distribute skill cross-posts to five platforms in one command. Most people manually post to each: different formatting, different copy, different everything. That’s 30 minutes per post. I do it in 2 minutes.

Over a year, that’s 50+ hours saved. For one skill.

My video-distill skill turns courses into searchable mini-books. Most people watch courses once and forget 80% of it. I have permanent reference material I can search and review anytime.

This is how one-person operations beat ten-person teams. Not by working harder. By owning tools that make you 10x faster.

Two Paths

The AI revolution is here. Not coming. Here.

Path A: Read about how AI is going to disrupt your career. Worry about it. Prepare for the worst. Maybe it happens, maybe it doesn’t. Either way, you spent months anxious instead of building.

Path B: Use AI to eliminate expenses, build tools, ship faster, own your stack. If disruption comes, you’re already leveraged. If it doesn’t, you still saved $2,400/year and got 10x faster.

I’m on Path B.

I built six skills in 14 hours. I save $200/month. I own tools that do exactly what I need, with no usage limits, no pricing tiers, and no risk of some startup getting acqui-hired and shutting down my workflow.

And I’m shipping four SaaS products while working two day jobs, because I have the leverage to do it.

You can panic, or you can build.

I’m building.

If You Want to Start

Here’s the playbook I use every time.

Step 1: Pick Your Target

Start with something you use weekly but don’t need enterprise features for. The sweet spot is tools where you’re paying for convenience, not capability.

Good first targets:

• Batch processing workflows (loop through files, process each, save outputs)

• Video/audio transcription (Whisper is free and runs locally)

• Content research and brainstorming (web scraping + Claude)

• Grammar/style checking (Claude prompts replace Grammarly)

• Format conversion pipelines (markdown → EPUB, video → transcript → summary)

Bad first targets:

• Accounting software (compliance, integrations, audit trails)

• Complex multi-step automation with 20+ triggers

• Anything requiring hosted infrastructure you don’t want to manage

• Real-time collaboration tools (Google Docs, Figma)

Step 2: Describe the Workflow, Not the Tool

Don’t say “build me a transcription tool.” Say “I have 20 course videos. I want to transcribe each one, distill the key points, and save them as markdown files organized by chapter.”

The more specific you are about your actual workflow, the better the tool fits. You’re not building a generic SaaS: you’re building exactly what you need.

Step 3: Start Ugly, Iterate Fast

Your first version will be rough. That’s fine.

My video transcription pipeline started as a janky script that choked on long files. I fixed the edge cases as I hit them. Now it handles 3-hour lectures without breaking a sweat.

Don’t try to build the polished SaaS version. Build the “works for my specific use case” version. That takes 90 minutes, not 90 days.

Step 4: The 80% Test

Run your homegrown tool alongside the paid one for 30 days. Track when you reach for the paid tool instead.

If your skill handles 80% of cases, cancel the subscription. The remaining 20%? Either iterate on your skill or accept the occasional manual workaround.

Perfect is the enemy of $X/month forever.

Step 5: Compound It

Once you’ve built one, you’ll notice patterns. The same techniques: file handling, API calls, text processing, output formatting: show up everywhere.

Your second skill takes half the time. Your fifth takes 20 minutes.

This is how you end up owning your entire stack without spending months building it.

The Prompt That Starts Everything

If you’re using Claude Code or similar:

I want to build a tool that [specific workflow].
I currently do this by [current manual process or paid tool].
My input is [what you're working with].
I want the output to be [format and destination].
What's the simplest way to build this?

Then iterate. The AI will ask clarifying questions, suggest approaches, write code. You test, refine, test again.

Two hours later, you own something you would’ve rented forever.

The people who win the next decade won’t be the ones who worried about AI disruption.

They’ll be the ones who used AI to build tools, eliminate costs, and move faster than everyone else.

Don’t rent your stack. Own it.

P.S.: The AI wrapper economy is dying. Every “AI-powered” tool that’s just a UI around Claude or GPT is on borrowed time. The moment users realize they can build 80% of that themselves, the subscription revenue evaporates. If you’re building an AI SaaS, make sure your value is in the 20% that can’t be replicated in two hours.

Here it is, paraphrased: “The real innovation of SaaS was laundering inaccessible open-source software into a format that doesn’t require transiting git. The hard part was never the code. The hard part was that git sucks.”

I laughed. Then I stopped laughing because it’s devastatingly correct.

The Git Laundering Machine

Think about the most profitable SaaS businesses in technology. Seriously, list them.

AWS? That’s Linux, KVM, and Xen behind a billing dashboard. Heroku was git-push-to-deploy because deploying was too hard. Vercel is the same thing for Next.js. MongoDB Atlas is MongoDB without the ops. Redis Cloud is Redis without the YAML. Supabase is Postgres without the DBA.

Every single one of them is a factory that converts something freely available on GitHub into something you can pay for on a website.

The commenter was right. These companies didn’t build moats with proprietary technology. They built moats by standing between users and git. Their value proposition, stripped to the studs, is: “You don’t have to clone a repo.”

That’s a $500 billion industry built on the fact that git clone is scary.

LLMs Just Killed the Middleman

Here’s where the “AI is killing SaaS” thesis gets real.

When a CTO says “can we build this internally?”, the old answer was: “Technically yes, but you’d need 3 engineers, 6 months, and ongoing maintenance. Just buy the SaaS.”

The new answer: “ChatGPT set it up in 20 minutes. It reads from the same open-source code the SaaS vendor uses. It runs on our infrastructure. There’s no monthly bill.”

LLMs do exactly what SaaS companies do — they take inaccessible open-source software and make it usable by normal humans. They just skip the subscription.

The git laundering machine now has competition. And the competitor works for free.

What Actually Survives

So is B2B SaaS dead? No. But the moat map just got redrawn.

Here’s what doesn’t survive: any SaaS whose primary value is “we set it up so you don’t have to.” Deployment wrappers, config GUIs, managed hosting for commodity databases — all of this is getting compressed.

An HN commenter who manages teams put it bluntly: “Management doesn’t want to be responsible for bespoke internal tools.” That’s real. But it’s a shrinking moat. Today’s management doesn’t want to be responsible. Tomorrow’s management grew up with ChatGPT and doesn’t see internal tooling as risky.

Here’s what survives:

Data. If your SaaS accumulates proprietary data over time — customer behavior patterns, industry benchmarks, network effects — that’s a moat AI can’t replicate. A new LLM-generated tool starts with zero data. Your SaaS has three years of it.

Compliance and trust. SOC 2, HIPAA, GDPR certification takes time and money. “ChatGPT built it” doesn’t pass an enterprise security audit. Yet.

Workflow lock-in. Not the software itself, but the habits. Slack isn’t hard to replace technically. It’s hard to replace because your whole company’s muscle memory lives there.

Network effects. Figma isn’t valuable because of the rendering engine. It’s valuable because your designers, developers, and product managers are all in the same file. That’s a moat no amount of vibe coding can replicate.

The specification itself. Here’s the contrarian take within the contrarian take: as code becomes commodity, the spec becomes the product. The companies that survive aren’t the ones that write the best code. They’re the ones that understand the problem deeply enough to specify what “right” looks like. Everyone else is just a GPT wrapper with a landing page.

The Indie SaaS Playbook Changes

If you’re building SaaS solo — and if you’re reading this newsletter, you probably are — the implications are brutal and clear.

Full disclosure: I built a product that does exactly this. Supabyoi deploys Supabase for you. By my own thesis, that’s a shrinking moat. I’m writing this post partly because I’m living the question: evolve or get compressed.

Stop building tools. Start building data flywheels.

A CRUD app with a nice UI is now a weekend project for anyone with ChatGPT. A system that gets smarter with every user interaction is still a real business.

Stop selling setup. Start selling ongoing value.

“We deploy Postgres for you” is dying. “We analyze your Postgres performance patterns across 10,000 databases and tell you what’s about to break” is thriving.

Stop competing on features. Start competing on understanding.

The SaaS products that survive AI commodification will be the ones that understand their customers’ problems better than a general-purpose LLM ever could. Domain expertise is the last moat.

The $500 Billion Question

The HN thread devolved into the usual “AI is overhyped” vs. “AI changes everything” tribal warfare. But that one comment, buried 14 levels deep, cut through all of it.

The SaaS moat was never the software. It was the fact that software was hard to access. That moat is evaporating.

What’s left is data, trust, network effects, and deep domain understanding.

Build your SaaS around those. Or enjoy competing with a free chatbot.

The metaphor runs through the whole thing: you’re not a line cook anymore, you’re orchestrating AI sous chefs, directing the kitchen, tasting every dish before it goes out. The developer-as-implementer era is over. Welcome to developer-as-orchestrator.

The Biryani Incident

It’s a good metaphor. I buy it. But here’s the thing about being a head chef that the metaphor doesn’t quite capture: a head chef without mise en place is just a guy having a panic attack near hot surfaces.

I know this because I’ve been that guy. Literally.

My wife had to leave town for a few days. “I’ll handle dinner,” I said, with the confidence of someone who has watched many cooking videos and successfully boiled pasta multiple times. I decided to make veg biryani — a dish my wife makes effortlessly, layering rice and vegetables and spices into something that tastes like it required more effort than it actually did.

“Prep everything first,” she told me before leaving. “Soak the basmati rice. Marinate the paneer. Chop the vegetables for layering. Have it all ready before you start cooking.”

Reader, I did not do this.

I started frying onions. While the onions were going, I realized I hadn’t marinated the paneer. So I started cubing paneer and mixing yogurt and spices. Then the onions started burning. I ran back, stirred frantically, ran back to the paneer. Remembered I needed to soak the basmati. Started the rice soaking. The onions were now definitely burned. I scraped them out, started over, but now I was behind, so I tried to do the vegetables and the new onions simultaneously while the paneer sat half-marinated…

An hour later I had a kitchen that looked like a crime scene, three pans with various stages of failure in them, and something that was technically edible but bore no resemblance to biryani. My wife, via video call, watched me plate this disaster with the expression of someone who had specifically warned against this exact outcome.

The problem wasn’t skill. I can cook. The problem was that prep and execution were bleeding into each other. I was trying to figure out what I needed while also doing the thing. And it turns out you can’t actually do both. Not well, anyway.

I’ve been that guy with AI sous chefs too.

I’ve been vibe coding since mid-2025. By “vibe coding” I mean the thing where you describe what you want in natural language and an AI writes the code. You know, the future we were promised, except the future has some sharp edges nobody mentioned in the demos.

Two SaaS products. Real users. Real revenue. Not toy projects, not “look ma I generated a todo app” tutorials, not the kind of thing you show off on Twitter and then quietly delete three weeks later. Actual products that people pay actual money for.

So when I tell you what follows, understand: this isn’t theory. This is what I learned by shipping real things and watching everything that could go wrong go wrong.

The Markdown Hemorrhage

For the first few months, I was that chef.

I’d sit down to implement a feature. Claude and I would get rolling. Then I’d notice a bug. Well, I’m already here, might as well fix the bug. Then while fixing the bug, I’d realize the error handling was inconsistent. Better clean that up. Oh, and there’s still context left in the window — might as well tackle that other feature I’ve been meaning to add.

Two hours later: three half-finished things, Claude confused about which task we’re actually doing, and code quality somewhere between “works” and “I’m not sure why.”

And the markdown. God, the markdown.

Claude, bless its heart, wanted to help me remember things. So it started creating files. ARCHITECTURE.md. DECISIONS.md. IMPLEMENTATION_NOTES.md. TODO.md. CONTEXT.md. CHANGELOG.md. README_UPDATED.md.

I call this markdown hemorrhage. The AI equivalent of a kitchen where every surface is covered with prep bowls, half-chopped vegetables, and sticky notes that say “DON’T FORGET THE SAUCE” — technically documentation, practically chaos.

At one point I had so many markdown files that I needed another AI tool just to search through the documentation I’d created for my AI tool.

This was clearly insane.

But here’s the thing that took me embarrassingly long to figure out: the problem wasn’t the tools. The problem was me.

One Goal Per Session

I was treating every Claude session like a buffet.

You know how it goes. You sit down to implement a feature. While you’re implementing, you notice a bug. Well, you’re already here, might as well fix the bug. Oh, and while fixing the bug, you realize the error handling is inconsistent across the codebase. Better clean that up too. And hey, there’s still context left in the window — might as well tackle that other feature you’ve been meaning to add.

Two hours later, you’ve got three half-finished things, Claude is confused about which task it’s actually working on, and the code quality has degraded to “works but I’m not sure why.”

I call this context pollution. And once I named it, I started seeing it everywhere.

LLMs are bad at juggling multiple goals. This isn’t a Claude problem — it’s a fundamental thing about how these models work. When you ask them to hold multiple objectives simultaneously, they get worse at all of them. Not a little worse. Dramatically worse.

The fix sounds almost stupidly simple: one goal per session.

That’s it. That’s the whole trick. One goal. One session. If you discover a bug while implementing a feature, you write down the bug and you close the session. The bug gets its own session later. No “while I’m here” detours. No context pollution.

“But what about efficiency?” I hear you asking. “Isn’t it wasteful to end a session when there’s still context left?”

This is the trap. This is exactly the thinking that leads to burned onions and half-marinated paneer. The leftover context is not an asset. It’s a liability. It’s your coworker with three tasks open, doing all of them poorly, about to forget everything anyway.

End the session. Start fresh. One goal.

The Mise en Place

Now, this discipline only works if you have a way to track what you’re not doing.

If you end a session every time you discover a bug, you need somewhere for that bug to live. Otherwise you’ll forget it. The bugs pile up in your head, you context-switch mentally, and you’re back where you started.

This is where beads comes in.

Beads is a git-backed issue tracker that Claude can read and write. Steve Yegge built it (yes, that Steve Yegge — the guy who wrote the platforms rant and approximately nine million words about Emacs). The idea is simple: every task becomes a “bead.” Claude creates them, updates them, closes them. They survive compaction. They sync through git.

I installed it. I ran bd init. And then something clicked.

See, beads isn’t just a todo list. It’s a forcing function. When you start a session, you run bd ready and it shows you what’s available to work on. You pick one. Not three. One.

And when you discover a bug mid-session? You tell Claude to create a bead for it. Claude writes it down, logs the context, notes any relevant details. Then you move on. The bug exists now. It has a home. You don’t have to hold it in your head.

The discipline and the tool reinforce each other. One bead per session only works because beads exist to capture everything else. And beads only work because the discipline prevents you from drowning in them.

Grooming vs. Coding

But I’m getting ahead of myself. Let me tell you about grooming.

In my old workflow, I’d sit down and just… start. Open Claude, describe what I wanted, begin coding. Very vibe. Very chaotic. Whatever felt right in the moment.

The problem is that “figuring out what to do” and “doing the thing” are completely different cognitive modes. One is divergent — you’re exploring possibilities, breaking down problems, identifying edge cases. The other is convergent — you’re executing, making decisions, writing code.

When you mix them, you get mush.

So now I run two types of sessions:

Grooming sessions are for thinking. I’m not coding. I’m not even planning to code in this session. I’m creating beads. Breaking down a feature into pieces. Identifying dependencies. Noting edge cases. If I think of an unrelated feature while grooming, it gets written down — for a different grooming session. No cross-contamination.

Coding sessions are for execution. One bead. Implement it. If I discover a bug, I note it and keep going unless it’s blocking. The bug gets groomed and coded in its own sessions later.

This separation is the whole game. It sounds bureaucratic. It sounds like exactly the kind of process that “vibe coding” was supposed to eliminate. But here’s the secret: this discipline is what makes vibe coding actually work at scale. Without it, you’re just generating code and hoping. With it, you’re building systems.

A Few Other Things

MCPs should be loaded at project level, not globally. Every MCP eats context. If a project doesn’t need the Reddit MCP, it doesn’t get the Reddit MCP. Context is expensive. Guard it like it’s money, because in a very real sense, it is.

Autocompact should be off. I want to control when context resets, not have the algorithm decide for me mid-feature. Yes, this means manually managing sessions. That’s the point.

Claude.md files are more powerful than you think. I have a global one in ~/.claude/CLAUDE.md with rules that apply everywhere. Each project gets its own with project-specific instructions. Claude reads these automatically. They’re like a pre-prompt that doesn’t eat your context window.

What Still Doesn’t Work

Now, here’s the part where I’m supposed to tell you it’s all solved and my workflow is perfect.

It’s not.

Debugging production issues is still clunky. I’ve got a combination of skills and MCPs that sort of works, but there’s too much manual context assembly. Something breaks in prod and I’m still spending the first 20 minutes of the session explaining the architecture before we can even start diagnosing.

Test-driven development doesn’t flow. The loop of “write test, see it fail, implement, see it pass” — it’s awkward. Claude wants to write everything at once. I’m still tweaking my tooling to make TDD feel natural.

UX work is hard. Like, fundamentally hard. Claude can scaffold UI. It can generate components. But “does this feel right?” is a human judgment call, and trying to get there through text-based iteration is like describing a painting to someone and asking them to tell you if it’s beautiful.

These are the walls I’m hitting. I’m building tooling to address them — an agent orchestrator that tailors Claude to my specific workflow. Work in progress. If you’re the adventurous type, you can try it now.

The System

So here’s the actual system, if you want to try it:

1. Install beads: npm install -g @anthropic-ai/beads && bd init

2. Add to your global CLAUDE.md: “Check bd ready at session start. One bead per session.”

3. Separate grooming from coding. Different sessions. Different mindsets.

4. Resist the urge to “do more while there’s context left.” That’s the trap.

5. Protect your context. Project-level MCPs only. Kill anything you don’t need.

Two SaaS products since mid-2025. All vibe coded with this system.

Not because the tools are magic. The tools are good, but tools are never magic. What made it work was the discipline — the willingness to be a little bit boring about context hygiene, to resist the temptation to do more, to trust that a focused session ships more than a scattered one.

Vibe coding without chaos. It turns out it’s not about vibing harder. It’s about vibing deliberately.

You’re the head chef now. But don’t forget your mise en place.

My wife was right, by the way. She usually is.

I’m Lakshmi. 20 years in software — ops, infrastructure, full-stack. Now solo founder using Claude Code to develop, deploy, and distribute.

For years, I overcomplicated this. Custom SMTP servers. Self-hosted monitoring. Elaborate setups that took days to configure and broke whenever I looked at them wrong.

Then I realized something: I was spending more time on infrastructure than on validating whether anyone wanted my product.

So I built a repeatable stack. Total cost: about $30-42 per year, per small bet. Here’s the whole thing.

Domain & Hosting: Cloudflare (Free)

Buy your domain wherever you want, but point the nameservers to Cloudflare immediately.

Cloudflare’s free tier is absurd:

• DNS management (fast, reliable)

• Free SSL certificates (automatic)

• DDoS protection

• CDN caching

• Cloudflare Pages (unlimited sites, unlimited bandwidth)

That last one is key. Your landing page goes on Cloudflare Pages. Connect your repo, push to main, it deploys. No servers. No bills. No thinking about infrastructure when you should be thinking about whether anyone wants your product.

I run every small bet’s landing page on CF Pages. Zero hosting cost.

Email: Google Workspace (The India Pricing Hack)

You want professional email. hello@yourdomain.com, not yourdomain.help@gmail.com like some kind of digital nomad running a dropshipping scam.

Google Workspace direct pricing: $6/month. Painful when you’re running multiple bets.

Google Workspace through an Indian reseller: Rs.125/month. That’s roughly $1.50.

Same product. Same Gmail experience. Same everything. Just… cheaper, because regional pricing exists and Google apparently forgot to close this loophole.

Recommended resellers: Medha Cloud, Host IT Smart, Shivaami. They’re authorized, they’re legit, and they’ll save you $50+/year per domain.

Setup takes 30 minutes: verify domain, add MX records, configure SPF/DKIM/DMARC so your emails don’t land in spam. Done.

Support: Crisp Chat (Free)

Intercom wants $74/month. For a small bet that might make $0.

Crisp’s free tier gives you:

• 2 team seats (it’s just you anyway)

• Unlimited conversations

• Mobile app for notifications

• A widget that doesn’t look like it was designed in 2008

Copy-paste their script tag into your landing page. Five minutes.

Upgrade trigger: when you have so many support conversations that you need automation. Which means you have customers. Which means you can afford to pay for things.

Monitoring: BetterStack (Free)

Your app will go down at 3am on a Sunday. This is not a prediction, it’s a guarantee.

BetterStack’s free tier:

• 10 uptime monitors

• 1GB logs/month

• Email and Slack alerts

• 3-day log retention

Is 3-day retention enough? For a small bet you’re validating? Yes. You’re not running a bank.

Alternative: Axiom gives you 500GB ingest and 30-day retention if you’re logging more aggressively. Also free.

Error Tracking: Sentry (Free)

Your code will throw exceptions in production that never happened locally. Classic.

Sentry’s free tier:

• 5K errors/month

• 10K performance transactions

• 1 user

• 90-day retention

For a small bet, 5K errors/month is plenty. If you’re hitting that limit, either your app is broken or you have enough users to pay for it.

Database: Supabase (Free Tier or Self-Hosted)

Every small bet needs a database. Supabase’s free tier is genuinely useful:

• 500MB database

• 1GB file storage

• 50K monthly active users

• Unlimited API requests

That’s enough to validate most ideas. The catch: you get 2 free projects total. After that, it’s $25/month per project.

For small bets that graduate to real products, I self-host Supabase on a $6/month Hetzner VPS. Full Postgres, auth, storage, realtime — no project limits, no usage caps. (I’m building a service called Supabyoi to make this dead simple. More on that soon.)

The Complete Stack

• Domain — ~$10-15/year

• Cloudflare (DNS + Pages) — Free

• Google Workspace (India) — ~1.50/month( 1.50/month( 18/year)

• Crisp — Free

• BetterStack — Free

• Sentry — Free

• Supabase — Free

Total: ~1.50/month, 1.50/month, 30-42/year

That’s DNS, hosting, professional email, live chat, uptime monitoring, error tracking, and a database for less than a single month of most “startup” tools.

The Rules

Don’t upgrade until you have paying customers. Free tiers exist for validation. Use them.

Keep the setup identical across bets. Same tools, same patterns, same DNS records. You should be able to launch a new bet’s infrastructure in an afternoon, not a weekend.

Resist the urge to self-host. Yes, you can run your own mail server. You can also perform your own dental surgery. Neither is advisable.

When To Actually Upgrade

• Google Workspace — You need >30GB storage → $7/mo

• Crisp — You need chatbots or >2 team members → $25/mo

• BetterStack — You’re pushing >1GB logs/month → $24/mo

• Sentry — You’re hitting 5K errors/month → $26/mo

• Supabase — You need >2 projects or more storage → $25/mo (or self-host)

Notice a pattern? These are all “you have real traction” problems. Good problems to have.

What’s Not Covered (Yet)

This is the skeleton — the basic infrastructure every small bet needs from day one.

I’ll cover these in separate posts:

• Tech stack choices (frameworks, languages, deployment)

• Payment processing (Stripe, Lemon Squeezy, regional considerations)

• CI/CD pipelines (GitHub Actions, deployment automation)

• Landing page patterns (what actually converts)

One thing at a time.

The Point

Infrastructure should be invisible. It should cost almost nothing while you’re validating. It should scale up only when you have revenue to pay for it.

$30/year per bet means you can run 10 small bets for less than most people pay for a single Notion subscription.

Stop building infrastructure. Start shipping products.

This is part of my “Deploy” series — simple infrastructure patterns for solo operators who’d rather build products than manage servers.

ShipFast. LaunchFast. ShipQuick. QuickShip. FastLaunch. LaunchQuick. (I may be making some of these up. I genuinely can’t tell anymore.)

Each one promised the same thing: “Save 40 hours of setup! Auth, payments, email — all pre-configured!”

And they delivered. Sort of. You got a codebase with 47 features, of which you needed 3. You spent 20 hours understanding their architectural decisions. Then another 20 hours ripping out the features you didn’t need. Then another 10 hours wondering why they chose that ORM.

Revolutionary time savings.

What Boilerplates Actually Sold You

Let’s be honest about what you were paying for:

1. Code you didn’t want to write — Auth flows, Stripe webhooks, email templates

2. Decisions you didn’t want to make — Folder structure, state management, API patterns

3. Security patterns you didn’t know — CSRF tokens, rate limiting, input sanitization

The first two? Claude Code handles those in minutes now.

The third one? That’s where it gets interesting.

The Security Argument (And Why It’s Half Right)

I’ve seen this take on Reddit: “AI is careless with security and exposes secret keys.”

Fair. I’ve watched Claude Code cheerfully commit .env files to git(not now, in its early days). I’ve seen it generate SQL queries that would make Bobby Tables proud.

But here’s the thing: I’ve also seen paid boilerplates ship with hardcoded API keys in example files. I’ve seen “battle-tested” starter kits with XSS vulnerabilities that a first-year CS student would catch.

The boilerplate isn’t magic. It’s just someone else’s code. Sometimes that someone else knew what they were doing. Sometimes they were just faster at shipping than you.

What Claude Code Actually Changes

Ask Claude Code to set up Stripe webhooks.

Watch it scaffold the endpoint, handle signature verification, implement idempotency, and add proper error handling. In about 3 minutes.

Then ask it why it made each decision.

That’s the part boilerplate sellers don’t want you to think about. The boilerplate gives you code. Claude Code gives you code and explains the reasoning. You walk away actually understanding webhook signature verification instead of just copy-pasting it.

The Real Question

Do you know what to ask for?

If you understand auth flows, webhook handling, rate limiting, and input sanitization — Claude Code replaces the boilerplate entirely. You’re paying $299 for code you can now generate in a conversation.

If you don’t know what you don’t know — the boilerplate is documentation-as-code. It shows you “here’s how someone who’s shipped 50 SaaS apps structures their webhook handlers.”

But here’s the thing: Claude Code also knows how someone who’s shipped 50 SaaS apps structures their webhook handlers. You just have to ask.

The Uncomfortable Middle Ground

Some boilerplates still earn their keep:

• Active communities that find and patch subtle bugs

• Security audits by actual security people (rare, but they exist)

• Opinionated architecture from someone who’s felt the pain of bad decisions

But most boilerplates? They’re charging you for the labor of stitching together open-source packages. That labor is now approximately free.

The Pragmatic Take

Use Claude Code to build your first few projects from scratch.

You’ll learn the patterns. You’ll understand why you need idempotency keys on webhook handlers. You’ll feel the pain of forgetting CSRF protection and then never forget it again.

Then you’ll realize you never needed the $299 boilerplate.

You needed the knowledge it contained.

That knowledge is now a conversation away.

The $299 boilerplate sold you fish. Claude Code teaches you to fish while also catching the fish for you. Your mileage may vary, batteries not included, void where prohibited.

Time from “huh, interesting Reddit post” to “supabyoi.com is live”: under an hour.

This is either impressive or terrifying, depending on how you feel about the pace of software development in 2026.

The Setup

I’ve been building a Reddit research tool that lives inside Claude Code. It monitors subreddits, scores posts against your interests, and helps you find signals in the noise. The tool uses Reddit’s public JSON endpoints—no API keys required, because Reddit doesn’t issue them anymore.

That’s not hyperbole. Reddit recently announced they’re “ending self-service API access.” You can’t just create an app and get keys anymore. You have to submit a request form, explain your use case, and wait for approval. The approval that, according to r/redditdev, never comes. “Tickets rejected, modmail ignored, admin DM ignored.” One developer summed it up: “I don’t believe anyone is getting API access for small personal use at this point.”

They’re pushing everyone to Devvit, their walled-garden platform. JavaScript only. Runs on their servers. Limited to what they allow.

If you want Reddit data for your own tools, you either pay enterprise rates, beg for approval, or use public endpoints like a normal browser would. I chose option three.

GummySearch learned this the hard way. They built a Reddit research tool, hit $11k/month MRR, served 135,000 users. Then Reddit wouldn’t give them a commercial license. They’re shutting down by December 2026. The founder didn’t want to operate “looking over your shoulder every day.”

Public endpoints don’t have that problem. Same data. No license to revoke.

I had the tool pointed at r/Supabase, watching for pain points. Standard demand validation stuff.

It surfaced a pattern across multiple threads. “I’m a mass-project starter. Supabase ain’t for me?” (41 upvotes, 27 comments). “Is Self-Hosting Supabase Worth It?” (73 upvotes, 60 comments).

The pain: Supabase’s free tier caps you at 2 projects. Pro tier is $25/month plus $10 per additional project. If you’re an indie dev shipping lots of small bets, you burn through that limit fast.

Supabase is genuinely great for rapid prototyping—I use it myself. The pricing just doesn’t fit the small bets workflow.

The comments were gold:

“It feels like a bait-and-switch where the upgrade appears to remove project limits, only to hit you with unexpected per-project fees”

“Setting it up properly takes time, maintaining it takes time, keeping the server secure takes time”

“The setup process is extensive, unclear and often frustrating”

“Very strange pricing model, which is kind of unacceptable”

Translation: Indie devs love Supabase for building fast. They hate the pricing when they ship a lot. They want to self-host but are terrified of maintaining it.

The Evaluation

I have a framework for this. Open source project + operational complexity + permissive license = potential hosting business. I’ve been running variations of this for a while.

I asked Claude—right there in the same session—to run the threads through the framework:

Pain point: Real. Multi-project pricing punishes prolific shippers.
License: Apache 2.0. Clear.
Operational complexity: High. Supabase runs ~12 services.
Existing managed option: Yes, but that’s the pain source—not the solution.

Then the key insight: I’m not competing with Supabase Cloud on hosting. I’m offering care and feeding for self-hosted instances. Different model entirely.

• They bring their own VPS (Hetzner, $10-15/month)

• I handle upgrades, backups, security

• Fixed monthly fee: $25. Unlimited instances.

One customer with 5 projects: $25 from me + $15 VPS = $40 total vs $75 on Supabase Cloud.

The Build

Here’s where it gets fast.

I told Claude:

“Create a landing page. Tailwind, not CDN. Minimal. Dev-focused. Static HTML.”

Claude scaffolded the project structure, wrote the copy, set up the build pipeline. I tweaked the value prop and added my ConvertKit form.

Then:

“Push to GitHub, I’ll deploy to Cloudflare Pages.”

Done.

Total time building the landing page: maybe 20 minutes. Most of that was me fiddling with colors.

The Stack

For the curious:

Landing page: Static HTML, Tailwind CSS, Cloudflare Pages
Waitlist: ConvertKit embed
Domain: Namecheap (purchase) → Cloudflare (DNS)
Total cost so far: $12 for the domain

The actual product will be FastAPI + Supabase (yes, the irony) + HTMX. SSH into customer VMs. Cron jobs for backups. Simple. I can ship a working beta this week.

The Point

This isn’t about Supabyoi specifically. It’s about the workflow.

Old way:

1. Have idea

2. Think about it for weeks

3. Research competitors

4. Write PRD

5. Design mockups

6. Build MVP

7. Realize nobody wants it

8. Total time: 3 months

New way:

1. Tool surfaces interesting signal

2. Ask Claude to validate against framework

3. Ask Claude to build landing page

4. Ship

5. See if anyone signs up

6. Total time: 1 hour

The landing page is a hypothesis test. Not a commitment. If I get 50 waitlist signups, I build the thing. If I get 5, I move on. The cost of being wrong is $12 and an hour of my time.

About That Reddit Tool

I’ve been quietly building this for months. It’s how I found the signal that led to this post.

The key: it lives inside Claude Code. Not a separate app. Not a browser tab. Right there in my terminal, in the same session where I’m writing code and shipping products.

The architecture: Crawler runs locally or on your VPS (Reddit can’t shut you down if they can’t block your IP). Data syncs to a backend. You query it with natural language through Claude. “What are people complaining about in r/Supabase?” → ranked list of pain points with source threads. Then in the same breath: “Evaluate this against my validation framework.” Then: “Build me a landing page.”

One session. Research to shipping.

No Reddit API keys because Reddit killed self-service access. Uses public endpoints. Same data you’d see browsing the site. Your IP, your rate limits, no approval form that never gets answered.

I’m not ready to launch it yet, but if you want early access, DM me on LinkedIn or Twitter/X.

The Takeaway

The leverage is real. One person, one AI assistant, one hour, one live product.

The bottleneck isn’t building anymore. It’s finding the right thing to build. That’s why the Reddit tool matters more than the Supabase thing. The tool finds signals. Claude validates them. Claude builds the test. You watch the data.

Small bets at scale.

supabyoi.com is live. Let’s see what happens.

<fingers-crossed/>

AI makes us 10x writers. 100x typists. Whatever.

But nobody’s talking about becoming a 10x reader.

And here’s the kicker — AI is vomiting out more code than ever. Which means you need to read and understand more code than ever. The bottleneck isn’t writing anymore. It’s comprehension, judgment, and knowing when to hit delete instead of commit.

Why this Matters More Now

The AI paradox

Claude can churn out 500 lines of backend logic in 30 seconds. But you still have to:

• Check if it actually does what you asked

• Notice the subtle bug hiding in error handling

• Decide whether that abstraction will come back to bite you

• Understand it well enough to fix it when the PM changes the requirements tomorrow

AI can write all the code in the world. It still can’t tell you if it’s good.

The reality

Juniors with AI now ship code at senior speed. The problem? They can’t tell good generated code from hot garbage. They move fast, break things… and then ask you to review it.

The unlock

Seniors with reading chops use AI without becoming its pet. They skim generated code like Neo reading the Matrix — “yeah, that’s an off-by-one bug right there.” Reading is the gate. Writing is just the noise.

The Code Reading Muscle

It’s not “reading comprehension.” It’s mental pattern recognition with caffeine.

Pattern recognition — You see if err != nil { return nil, err } and your brain whispers, “Go boilerplate, nothing to see here.”

Architecture intuition — You open a repo and know where the dead bodies are buried just from the folder structure.

Bug radar — That spidey-sense that tingles before you even scroll — something’s off. Usually missing validation, or someone “cleverly” sharing a global.

Context switching speed — You can hop from React component → API → database query → back again without losing the plot.

Abstraction unpacking — You see userService.authenticate() and immediately imagine the 12 files hiding behind that call.

That’s the muscle. Reading is pattern spotting at light speed.

Exercises That Actually Work

1. The 5-Minute Codebase Scan

Pick a random GitHub repo. Small, readable.

Set a 5-minute timer. Try to answer:

• What does it do?

• What’s the core abstraction?

• Where would you add a new feature?

• What’s the sketchiest piece of code?

You’ll probably be wrong the first few times. Perfect. You’re training intuition, not memorizing trivia.

Start with stacks you know. Then branch out. Eventually, try reading something alien — that’s where growth hides.

2. AI Code Review Roulette

Ask Claude or ChatGPT to write something — a rate limiter, a REST API, a React hook.

Now, don’t run it.

Read it like a detective:

• What could break?

• What smells?

• What would you refactor?

Then run it and see how wrong (or right) you were.

Do this enough and you’ll develop a sixth sense for AI bugs — the kind that crash in production at 3 a.m.

Bonus: Ask two AIs the same thing. Which one’s code would you rather maintain? Why? That’s your taste muscle forming.

3. The Changelog Detective

Pick a library you use every day. Go to its GitHub releases. Read the commit diffs for a minor or patch bump.

Ask:

• Why was this changed?

• What broke?

• What tradeoff did the maintainer choose?

You’ll start seeing the real engineering behind the facade. That’s where mastery lives.

4. Explain It to a Duck

Grab a gnarly function.

Now, explain it in plain English. No jargon.

If you can’t? You don’t actually understand it. Keep at it.

Bad: “It maps and filters the array.”

Good: “It finds active users in the last 30 days, sorted by login time.”

That’s real understanding. Not just parroting syntax.

5. The “No Running” Challenge

Write a small program. 50–100 lines. Don’t run it.

Read it twice and predict:

• What will the output be?

• Where will it break?

• What edge case will it choke on?

Then run it. Reality check time.

This builds your internal compiler — the one that helps you debug production when the system’s on fire and kubectl exec isn’t helping.

How This Compounds Over Time

0–2 years:

You read slow. You write slow. You Google “Python for loop syntax” a lot.

AI enters:

Suddenly you write fast. But you still read like a confused tourist. You ship more bugs, faster.

2–5 years:

Now you read fast and write fast. You glance at AI output and see through it.

5+ years:

You can parachute into any repo and get the lay of the land in minutes. You’re debugging across services. Reading is 80% of your job. Writing is an afterthought.

Every project you touch sharpens the radar. Every bug you fix improves your mental models. Every codebase you inherit becomes easier to digest. That’s compounding.

Also: boring stacks help.

You read the same patterns — Postgres, Redis, Express — again and again until it’s second nature. No cognitive tax. Fancy tech makes you start from zero every time.

Daily Practice (a.k.a. the Boring Way That Works)

• Morning ritual: Read one function before writing a line. Two minutes. That’s it.

• PR reviews: Don’t just skim — ask why the author made those choices.

• AI pair programming: Never accept AI code blindly. Read before you run. Especially when you’re in a rush.

• Weekend deep dives: Pick one OSS project a month and read the core 200 lines.

• Bug postmortems: After fixing something, read the surrounding code. Figure out why it broke in the first place.

That’s how you actually build the muscle. Quietly. Daily.

Don’t Fake It

Speed reading code to “feel productive” is fake progress.

If you can’t explain it, you don’t understand it.

Red flags:

• Approving PRs faster than Slack loads

• Forgetting what your own code does after a week

• Acting surprised when it breaks exactly how it looks like it would

Slow down. Read with intent. Comprehension beats velocity every single time.

The Meta-Skill

AI will keep getting better at writing code. It’ll never understand why the code matters.

That’s your job.

The developer who can read code — fast, deeply, intuitively — will always win.

Start building the muscle. It ages like wine.

Do this today:

Pick one exercise. Do it now. Time yourself. Do it again next week. You’ll notice you’re faster — not at typing, but at thinking.

That’s the real 10x skill nobody’s bragging about on LinkedIn.

React or Vue? Flask or Django? Docker or bare VPS?

I’d open fifty tabs and still end up staring at a blinking cursor.

Now, we’re in a world where you can describe your idea and watch an AI spin up a working prototype. It feels magical — until you try to debug it.

The truth is, vibe coding only works if you understand what the AI is building for you.

Otherwise, you’re just rearranging generated code and hoping for the best.

So, before you ask AI to build your SaaS, here’s what you need to master first.

These aren’t frameworks or libraries — they’re the mental models that make AI your assistant, not your babysitter.

Version Control: Command the Timeline

I used to treat Git like a magical undo button — until it undid everything.

Even as a solo builder, Git is your safety net. Learn to branch, merge, revert, and tag with confidence.

Every “oh no” moment becomes recoverable when you know how to roll back.

🧠 Pro tip:

Integrate your favorite AI tool with GitHub’s MCP. You can tell it to open PRs, summarize diffs, or write changelogs.

But here’s the catch — to delegate effectively, you need to understand version control first.

Also, Magit for VSCode is an underrated gem. It makes Git feel almost fun.

Data: Model, Don’t Just Store

No SaaS survives without a solid data model. I learned that the hard way, after my “fast” prototype crawled because I hadn’t indexed anything.

Knowing how to design schemas, choose keys, and plan migrations will save you more pain than any ORM ever could.

Your data model will evolve. Be ready for it.

🧠 AI Tip:

Discuss your schema with your LLM.

Ask, “What should I index?”, “How will this evolve?”, or “What’s the best way to handle this relationship?”

You’ll get insights that feel like having a senior engineer on call.

HTTP & APIs: Speak the Native Language

Every SaaS runs on HTTP.

Learn verbs, status codes, and what to return when things go wrong.

In my early days, I’d return 200 for everything — even errors.

Don’t do that. It makes your users (and future self) miserable.

🧠 AI Tip:

Tools like Context7 make working with APIs much easier.

And yes, keep an OpenAPI spec. It’s documentation for your future self, not just a team.

(And between us — your first SaaS might not even need an API. We’ll talk about that soon.)

Authentication: Shop the Shelf

I built my own login systems multiple times.

It always ended with regret and sleepless nights.

Don’t code your own auth unless you’re writing a security product.

Use your framework’s built-in module, or plug in Supabase, Clerk, or Auth0. I wrote about this:

Security is not where you show creativity.

🧠 AI Tip:

LLMs can wire up cookie handling, password resets, and JWTs, but make sure you know where your secrets live and how they expire.

Frontend Literacy: Communicate, Don’t Overcomplicate

Frontend used to terrify me. CSS felt like chaos, and every “simple” change broke something else.

Then I discovered the power of simple stacks — HTML, Tailwind, and maybe HTMX or Alpine.js.

You don’t need React to make a clean, usable product.

You just need enough literacy to connect your API to a button and make it look decent.

🧠 AI Tip:

AI is terrible at design. It’ll give you perfect code for ugly UIs.

Feed it visual specs instead of vague prompts.

And if you can, learn a bit of design — not to be a designer, but to avoid obvious aesthetic crimes.

Caching: Respect the User’s Time

I once doubled my server bill because I didn’t cache anything.

Caching isn’t optimization — it’s respect.

You don’t need to master Redis or CDN tuning, but understand the concept:

store what doesn’t change, reuse what you can.

🧠 AI Tip:

Ask, “Where can I add caching for quick wins?”

AI can spot bottlenecks faster than you think.

Containers & Deployment: Build Once, Run Anywhere

I used to fear Docker. It felt like wizardry.

Then I realized it’s just consistency — the same environment, everywhere.

Learn how to write a Dockerfile and deploy with Docker Compose or Fly.io.

That’s 90% of what you’ll ever need early on.

Kubernetes can wait — though it’s worth knowing why it exists.

🧠 AI Tip:

Let the AI write your Dockerfile, but read every line.

A single bad layer can bloat your image from 100MB to 1GB.

System Design: Don’t Overbuild — Yet

When I first started learning about queues, event buses, and load balancers, I felt like I’d unlocked a hidden level of engineering.

I wanted to use everything.

So I did — and my “simple” SaaS turned into a distributed Rube Goldberg machine.

My future self hated me for it.

Here’s the quiet truth about system design:

the more you know, the more dangerous you become.

Because knowledge tempts you to overengineer.

To solve problems you don’t have yet.

To optimize for scale that may never come.

But good design isn’t about sophistication — it’s about restraint.

It’s choosing clarity today over hypothetical performance tomorrow.

🧠 AI Tip:

Ask your coding assistant to sketch a simpler version of what you have in mind.

Say, “Can this work without queues?” or “Can we handle this in-process first?”

Sometimes the best architecture is the one that fits in your head.

Observability: See Before You Panic

The most painful bugs are the invisible ones.

You can’t fix what you can’t see.

Start simple: print logs, expose /healthz, and add uptime checks.

You don’t need fancy dashboards — just awareness.

🧠 AI Tip:

Ask your LLM to set up Sentry, logging middlewares, or structured logs.

AI is great at the boring setup — you handle the insights.

Shell & Scripting: Glue Everything Together

Bash saved me more times than I can count.

A simple script to restart a service, clean a directory, or back up a DB — these are invisible superpowers.

Learn your way around permissions, env vars, grep, and tmux.

This is what separates the “can’t deploy” dev from the “fixed it in 5 minutes” builder.

🧠 AI Tip:

Have AI generate shell scripts — but never run them blindly.

Understand before you execute.

Security: The Habit, Not the Skill

You might’ve noticed I didn’t give security its own section. That’s intentional.

It’s not a tool — it’s a habit.

Every time you touch authentication, data, or deployment, think:

“If this were compromised, what breaks?”

Use HTTPS. Hash passwords. Never hardcode secrets.

Most breaches come from negligence, not genius-level hacking. Something I like to call the ignorance debt.

Frameworks, Languages, and Everything Else

By now, someone will say, “But what about React? Django? Go? Rust? CI/CD?”

All valid. All secondary.

Frameworks are shortcuts, not foundations.

Languages are dialects — once you understand these fundamentals, syntax becomes trivia.

Testing, CI, and cloud scaling make sense only after you’ve shipped something worth scaling.

Learn these ten areas deeply, and AI suddenly becomes 10x more effective.

Because now, you know what to ask, what to skip, and when to stop it from hallucinating an entire microservice.

The Indie Dev Reality

Vibe coding isn’t about skipping the hard parts — it’s about sequencing them right.

AI gives you speed, but not direction.

These fundamentals are your compass.

Learn them once, and you’ll never fear new tools again.

Everything else — frameworks, language wars, fancy hosting — becomes optional flavor.

Because in the end, you don’t need to know everything.

You just need to know enough to ship, fix, and try again.

No users yet. No traffic. Everything looks fine.

It’s the most deceptive calm in tech.

Because here’s what happens next:

Someone signs up. A few cron jobs kick in. A background task fails silently.

And you have no clue why.

Not because you’re a bad engineer.

But because you never gave yourself eyes.

I’ve been there — staring at a blank terminal, trying to reproduce a bug I can’t see, because I didn’t bother adding even basic observability before launch.

That’s when you realize: you don’t need users to create chaos. You just need time.

Your SaaS will break.

Something small. Something silly. Something preventable.

And when it does, you want breadcrumbs.

You don’t need Grafana dashboards or Prometheus metrics yet.

You just need awareness. A few tiny habits that make you less blind:

• Log errors to stdout. Your logs are your first debugger.

• Add Sentry for unhandled exceptions — because one will always sneak through.

• Expose a /healthz endpoint. It’s the easiest way to check if your app is even alive.

• Capture latency in middleware. You don’t need histograms; just print request times.

That’s enough.

You’re not setting up a monitoring stack. You’re giving your future self context.

You’re leaving breadcrumbs for when things go sideways.

Because when that first user says,

“Hey, your site’s kinda slow today,”

you’ll know where to look — not just what broke.

I can’t tell you how many times I’ve been grateful for a random log line I wrote months ago.

Future-me has sent past-me several thank-you notes.

So, before you chase new features or users…

Add observability.

Give yourself eyes. 👀

It’s the calmest insurance policy you’ll ever set up.

I tried useEffect. Then useMemo. Then stared at the dependency array like it had personally wronged me. Eventually, I fixed it — by restarting the dev server.

That’s when it hit me: React wasn’t made for people like me.

React was built for teams — with dedicated frontend engineers, design systems, review processes, and time to care about component hierarchies. I’m just trying to build a SaaS. Alone.

And as a solo dev, every layer of “modern architecture” feels like an extra wall between me and shipping.

I’m not great at React — mediocre, at best. But that’s the point. The tools I use shouldn’t need me to be great at them to get work done.

I don’t hate React. I hate how easily it turns small projects into puzzles.

The setup is never small: package managers, routing, build tools, state management, API layers, hydration. It’s an entire ecosystem just to render some HTML.

At some point, you stop writing features and start maintaining your own framework.

And no — AI coding assistants don’t make this any easier.

They’ll happily generate components, hooks, and entire pages for you. But they also multiply the cognitive load. You end up with auto-written code you didn’t fully read, logic you didn’t author, and bugs you can’t mentally trace.

AI helps you go faster — straight into the same wall.

When the code gets complex, you’re still the one debugging it at 1 a.m., trying to remember why useEffect depends on a variable that no longer exists.

Meanwhile, the old-school Model-View-Controller pattern — the one we abandoned because it wasn’t “modern” enough — still does the job.

Django, Rails, Laravel — these frameworks have one big thing React doesn’t: a consistent mental model. You don’t have to remember whether a component is server or client. You just write code that responds to requests and sends back HTML.

MVC assumes you’re one person who wants to move fast. React assumes you’re part of a team that can afford to slow down.

In MVC land, there’s no build step. No hydration mismatch. No npm install that randomly breaks after a week. You can teach a junior developer (or your future self) the whole stack in an afternoon.

The irony is that React is now rediscovering what MVC never forgot. Server components, data fetching, progressive rendering — all old ideas wearing new clothes.

And that’s fine. The web evolves. But if you’re an indie developer building your first or fifth SaaS, you don’t need to play catch-up with every new abstraction.

Complexity is not a sign of progress. It’s often just inertia.

Simplicity compounds. Every decision you don’t make leaves you more energy to focus on what matters — your users, your pricing, your roadmap, your survival.

So if your stack feels heavy, it’s not your idea that’s broken. It’s your setup.

You don’t need a front-end framework to validate your business.

You need feedback. Fast.

And for that, an old-fashioned MVC stack will get you further than a “modern” one built on a mountain of npm packages.

React is powerful — no argument there. But power isn’t the same as momentum.

For indie devs, momentum wins. Every time.

I’ve built half a dozen SaaS products. Some succeeded. Most failed. But the failures taught me something critical: ideas don’t die from competition—they die from delayed launches.

You lose weeks setting up databases, authentication, APIs, file uploads, and admin panels before writing a single line of actual product code. By the time you’re ready to ship, momentum is gone.

If I were starting today, I’d skip all that. I’d use Supabase—and I’d ship an MVP in days, not months.

The Problem with “Building from Scratch”

Building foundations feels productive. You’re writing code, making decisions, setting up infrastructure. But you’re not building anything users can touch.

Auth alone consumes days: password hashing, session management, password resets, email verification. Then you need database migrations, API routes, input validation, error handling. Before you know it, you’ve burned two weeks on scaffolding.

That’s two weeks you could’ve spent validating whether anyone actually wants what you’re building.

Why Supabase Changes Everything

Supabase isn’t just a database. It’s a complete backend—authentication, storage, real-time updates, edge functions—packaged as a single platform. And unlike Firebase, it’s built on PostgreSQL, so you’re not locked into proprietary tech.

PostgreSQL Foundation

Every table you create automatically gets REST and GraphQL APIs. No backend needed. Query directly from your frontend with row-level security enforcing permissions at the database layer.

// Fetch user's tasks directly from the frontend
const { data, error } = await supabase
  .from('tasks')
  .select('*')
  .eq('user_id', userId);

You still get full PostgreSQL power: triggers, extensions, stored procedures, joins, indexes. It’s not a toy database—it’s enterprise-grade Postgres with a developer experience that doesn’t suck.

Authentication That Just Works

Built-in support for email/password, magic links, OTPs, OAuth (Google, GitHub, etc.), and custom SSO. User records live in your Postgres schema. Add custom fields. Create relationships. No vendor lock-in.

// Sign up with email/password
const { user, error } = await supabase.auth.signUp({
  email: 'user@example.com',
  password: 'secure-password'
});

// Magic link (passwordless)
await supabase.auth.signInWithOtp({
  email: 'user@example.com'
});

No JWT libraries. No session stores. No password reset flows. It’s handled. You write product code.

Real-Time Updates Without Redis

WebSocket-based subscriptions give you instant updates on table changes. No message brokers. No Kafka. No Redis pub/sub.

// Subscribe to new messages
supabase
  .channel('messages')
  .on('postgres_changes', {
    event: 'INSERT',
    schema: 'public',
    table: 'messages'
  }, (payload) => {
    console.log('New message:', payload.new);
  })
  .subscribe();

Insert a row in your messages table? All connected clients receive it instantly. Build chat, notifications, live dashboards—without standing up infrastructure.

Row-Level Security

Database-level authorization policies replace entire backend authorization layers. One policy line defines who can access what.

-- Users can only see their own tasks
CREATE POLICY "Users see own tasks"
  ON tasks FOR SELECT
  USING (auth.uid() = user_id);

Policies compose. Multi-tenant? Add tenant_id checks. Admin override? Add role conditions. Security moves from scattered backend checks to centralized, auditable rules.

Storage & Edge Functions

Native file upload handling with access rules compatible with row-level security. TypeScript-based edge functions deploy in seconds for webhooks, scheduled jobs, or integrations.

// Upload file with automatic access control
const { data, error } = await supabase.storage
  .from('avatars')
  .upload(`${userId}/avatar.png`, file);

// Edge function for webhook processing
import { serve } from 'https://deno.land/std/http/server.ts'

serve(async (req) => {
  const payload = await req.json();
  // Process webhook
  return new Response('OK', { status: 200 });
});

The Developer Experience You Deserve

The CLI, dashboard, SQL editor, and APIs feel cohesive. You’re not juggling five different tools with five different authentication methods. Everything integrates.

Need to see your database? Open the dashboard. Want to test a query? Use the SQL editor. Ready to deploy a function? supabase functions deploy. It just works.

Open Source & Portability

Unlike Firebase, Supabase runs self-hosted via Docker Compose. Start on their hosted platform. Move to self-hosted if you outgrow it. Same codebase. Same developer experience.

You’re not locked in. Your data is Postgres. Your auth is Postgres. Your files are S3-compatible storage. If Supabase disappears tomorrow, you can migrate. Try doing that with Firebase.

Ship Fast, Own Your Stack, Avoid Unnecessary Complexity

This is the indie developer playbook: start small, ship fast, scale naturally. Supabase embodies that philosophy.

You’re not choosing between a custom backend and a proprietary platform. Supabase sits in the middle—powerful enough for serious applications, simple enough to start with one table and an auth flow.

If I were starting a SaaS today, I’d skip the scaffolding. I’d use Supabase. And I’d ship in days—not weeks.

Because the best way to validate an idea isn’t to build perfect infrastructure. It’s to put something in front of users and learn whether they care.

Supabase gets you there faster. And when you’re running solo, speed is everything.

You know the drill: a dedicated frontend built with React or Next.js, an API-only backend, and a separate database layer neatly tucked behind it.

It looks professional. It feels scalable.

But for indie developers building SaaS products, it’s a trap.

When you’re a solo founder or a two-person team trying to validate an idea, the 3-tier architecture — frontend + API + database — is rarely your friend.

It’s a cognitive and operational tax disguised as “best practice.”

Think about what you’re actually doing when you follow this pattern:

• You spin up a frontend repo with its own dependencies, build system, routing, and deployment.

• You spin up a backend API that must serialize, authenticate, and talk over HTTP just to move data between two systems you control.

• You wire in your database and ORM, create migrations, and write serializers or DTOs to keep everyone happy.

That’s three moving parts. Three deploys. Three layers of bugs.

For what?

Most MVPs don’t need “layers.” They need feedback.

The 3-Tier Pattern Serves Organizations, Not Builders

Here’s the truth: this architecture exists to serve org structure, not product velocity.

Big companies need clear boundaries because they have teams:

• Frontend team

• Backend team

• Ops team

The 3-tier pattern is basically Conway’s Law in code form — architecture mirroring the communication lines of large organizations.

But when you’re building your first SaaS, you are the team.

You don’t need boundaries between yourself. You need flow.

Every layer you add between user action and business logic slows that flow down. Every abstraction adds cognitive overhead. You spend more time plumbing than building.

The Cognitive Overload of “Modern”

React and friends were meant to solve complexity. Ironically, they’ve become a source of it.

A simple button click in React is rarely just a button click. It’s:

• A component that imports five dependencies.

• A state hook managing a boolean.

• A context provider that tracks global state.

• An API call wrapped in a useEffect that must sync with local cache.

You could’ve just written:

<button hx-post=”/like” hx-swap=”outerHTML”>Like</button>

and been done with it.

React, Vue, Svelte — they’re incredible for rich UIs, but they demand constant context switching. JSX, state management, bundlers, APIs, hydration. Each decision compounds.

If your goal is to ship a paid product, not a code showcase, that complexity is friction.

The Modern “Backend-First” Stack

Choosing a simpler path doesn’t mean going back to sticks and stones.

HTML isn’t dead. It’s evolved.

You can build interactive, modern interfaces right inside your backend using tools like:

• HTMX – progressive HTML-over-the-wire, no full reloads.

• Alpine.js – small, declarative reactivity.

• Tailwind CSS – utility-first design system that makes you fast and consistent.

Together, they form a sweet spot:

• You write HTML templates with embedded actions.

• You sprinkle JS only where it matters.

• You serve it directly from your backend.

No API layer. No hydration. No build pipeline. Just requests, responses, and users getting what they came for.

You still get interactivity, animations, modals, and dynamic UI updates — but with a tenth of the cognitive load.

This means faster iteration cycles, smaller deployments, and drastically fewer bugs.

Your stack lives in one repo.

Your deploy command is one line.

Your brainspace is freed up for actual product thinking.

“But What About Scaling?”

That’s the wrong question for 95% of MVPs.

You don’t have a scaling problem until you have users.

Startups die from lack of traction, not lack of microservices.

If you ever outgrow this setup — great. Peel off layers later.

Turn your backend endpoints into APIs, move your UI to React, or even split your services. By then you’ll have revenue, validation, and real data to justify the refactor.

Premature architecture is just another form of procrastination.

The Hidden Benefit: Mental Clarity

Beyond performance and simplicity, there’s a more subtle gain: cognitive freedom.

When your stack is unified, your brain can focus on the user flow instead of the glue code.

You can see everything — UI, logic, and data — in one place.

It feels cohesive.

You’re not juggling three languages, four toolchains, and two servers.

You’re just shipping.

And that matters more than any buzzword architecture ever will.

The Takeaway for Indie SaaS Builders

You don’t get extra points for being complex.

You get rewarded for being useful.

A simpler stack means:

• Faster idea-to-demo time.

• Easier onboarding if you add help later.

• Fewer mental tabs open.

• Lower hosting costs.

• And most importantly — fewer excuses to delay launch.

You can build 80% of what you think you need with plain HTML templates, Tailwind, and a bit of JS. Add Alpine for interactivity, HTMX for AJAX-like flow, and you’ll rival the speed of any React-Next duo out there.

Stop architecting for imaginary scale. Start shipping for real users.

Because the faster you close the gap between idea and feedback, the faster you learn, iterate, and make money.

And that’s the only scale that matters when you’re small.

One part of you just wants to build.

To open the editor, follow your curiosity, and see something real come alive on screen.

That’s the vibe coder in you — the part that moves fast, trusts intuition, and believes momentum creates clarity.

Then there’s the other voice.

The one whispering about tests, migrations, rate limits, and all the invisible things that keep production from burning down.

That’s the engineer in you — the part that’s seen systems crumble and knows “we’ll fix it later” often means “we’ll fix it never.”

Most of us swing between the two.

Too much vibe, and your SaaS turns into a spaghetti monster that terrifies future you.

Too much discipline, and you’ll design yourself into paralysis before your first user ever logs in.

The balance isn’t about finding the perfect middle ground — it’s about timing.

Phase 1: Vibe for Momentum

When you’re starting, you don’t need architecture.

You need proof. Proof that the idea resonates, that the workflow feels good, that you can sustain your own interest long enough to see it through.

Ship something messy.

Inline CSS. Hardcoded configs. A Docker Compose file running on your laptop.

If it helps you learn or get feedback faster, it’s good enough.

At this stage, your goal is to find the pulse of your product — the heartbeat that makes it worth polishing later.

Phase 2: Add Discipline for Survival

Once someone uses it — or worse, depends on it — your job changes.

You’re no longer hacking; you’re maintaining.

That’s when guardrails matter.

Not enterprise-level bureaucracy, but the indie essentials:

rate limits, structured logs, CI checks, and a migration plan that won’t kill your data.

Each layer of success earns another layer of discipline.

That’s how you scale without killing your momentum.

The Indie Balance

Vibe coding isn’t reckless.

It’s how you get to momentum.

But discipline is how you keep it.

The real art of indie software isn’t just writing good code.

It’s knowing when to write which kind of code.

TL;DR:

You start as an artist. You evolve into an engineer.

The trick is not to silence either voice — just let them take turns driving.

You know the story:

You clone your repo on a new laptop or spin up a new dev box, run flask run or uvicorn main:app –reload, and boom — connection refused on localhost:5432.

Postgres isn’t running.

Your .env file is half missing.

Supabase changed a port.

And now you’re googling “how to reset a Postgres user password” for the third time this month.

That’s why I’ve stopped messing around with manual setups — and started containerizing my local environment using Docker Compose.

Not because it’s trendy.

Because it’s the only way to guarantee I can pull, build, and run my app in under a minute.

The indie dev reality

As solo devs, we move fast. We don’t have infra teams or onboarding docs. Most of our systems live in muscle memory and terminal history.

That’s fine when you’re in the groove — until you need to:

• Revisit a project after a few months.

• Share it with a collaborator.

• Spin it up on a new machine.

• Or just fix a quick bug and realize nothing runs anymore.

A solid local setup is like documentation that actually works.

Docker Compose is the simplest way to get there.

Why Docker Compose?

It’s not about “microservices” or “container orchestration.” Ignore that stuff.

Compose is just a YAML file that says:

“Here’s everything my app needs — run it all together.”

You can define your web app, Postgres, and even Supabase’s local stack if you want to mirror production closely.

When you run docker compose up, everything spins up consistently — same versions, same ports, same config — every time.

It’s reproducibility for humans.

The minimal example (Python + Postgres)

Let’s say you’re building a FastAPI app that talks to Postgres.

Here’s a dead-simple docker-compose.yml to make your life easier:

link to the gist

And a Dockerfile to go along with it.

Link to the gist

That’s it.

Now you can run your entire stack with one command:

docker compose up

Your Python app connects to Postgres instantly.

No need to brew install, no weird port conflicts, no “is Postgres running?” guessing game.

Want to mirror Supabase locally?

If you’re using Supabase in production but want to run locally, Supabase has its own CLI that uses Docker under the hood.

You can spin up a near-production clone with:

supabase start

That’ll run Postgres, API, auth, and storage locally in containers — no manual setup required.

It’s heavier, but it’s great if you’re testing row-level security, triggers, or anything that depends on Supabase’s stack.

But isn’t Docker heavy?

Yeah, a little.

The first time you pull images, it’ll download a few hundred MB. After that, it’s fast.

And honestly, the alternative is worse — debugging inconsistent environments and broken local databases.

The real magic isn’t that it’s fast — it’s that it’s reliable.

If you take a break from your project for a month, you can come back and it’ll just work.

That’s worth the disk space.

Bonus: the same setup works for production

Here’s the underrated part — once you have this docker-compose.yml, you’re halfway to a production deployment.

You can:

• Build your app image with docker compose build api.

• Push it to a registry like Docker Hub or GitHub Container Registry.

• Deploy it to Fly.io, Render, Railway, or your VPS — all of which happily accept a pre-built Docker image.

That means your local setup = production setup.

No “works on my machine,” no separate Heroku config, no hand-tuned server differences.

You’re testing exactly what you’ll ship.

For example, to build your image for deployment:

docker compose build api

docker tag yourapp_api your-registry.com/yourapp:latest

docker push your-registry.com/yourapp:latest

Then you can run it anywhere with:

docker run -p 8000:8000 your-registry.com/yourapp:latest

This alignment — same Dockerfile, same Compose config — is what makes deployment predictable, even as a one-person team.

Quality-of-life improvements

Once you’ve got Compose running smoothly, you can make it even nicer:

1. Add a Makefile or script for one-command startup:

make up

Your Makefile contents:

up:

docker compose up --build

2. Add a seed script for your DB:

docker compose exec db psql -U dev -d app -f seeds.sql

3. Run tests in the same containers:

docker compose run api pytest

You now have a full, consistent local dev environment that feels like production, without the cloud bill.

The point isn’t Docker — it’s repeatability

You’re not doing this to “learn containers.”

You’re doing it because your time is too valuable to waste on setup chores.

A docker-compose.yml file is the indie dev version of a safety net.

You can drop your laptop, clone your repo on a new one, and be productive in 60 seconds flat.

And when it’s time to deploy?

You’re already 90% there.

TL;DR

• Your SaaS deserves a repeatable local setup.

• Docker Compose makes it dead simple for Python + Postgres (and Supabase).

• It doubles as your build foundation for production images.

• You’ll thank yourself every time you reopen an old project or deploy something new.

It’s one of those rare decisions that’s both practical and future-proof.

Set it up once — and your dev-to-prod pipeline just became a lot less fragile.

But let’s be honest — not every product justifies being billed every month.
Some tools solve a short, sharp problem. They’re used heavily once, and then only occasionally, if ever, after that.

Forcing that into a subscription model doesn’t create a loyal customer base. It creates churn.

So, let’s talk about an alternative: a one-time license model that’s installed on the user’s own infrastructure.

They buy it once. You give them the code. They run it wherever they want.

It’s not just a throwback to the old “software license” days — it’s a modern, lean, developer-friendly way to build a business without the overhead of hosting, scaling, and endless retention tactics.

When Subscriptions Don’t Fit

Imagine you’ve built a tool that helps teams migrate their customer data from one CRM to another.

Most companies only do this once. They just want it done right.

You could sell this as a $49/month SaaS, but that’s immediately awkward:

• Your users might only need it for a few weeks.

• You’ll end up with tons of churn.

• You’ll need to support inactive users forever because “they’re still subscribed.”

Now imagine instead you sell it as a one-time installable tool.

They pay $499 upfront. You send them the source (or a compiled binary) and a license key. They run it on their own infra — AWS, GCP, their laptop, whatever.

No ongoing hosting costs for you.
No surprise bills for them.
No monthly churn charts haunting you.

Just a clean, value-aligned exchange: they pay for the outcome; you deliver it.

But Isn’t That Giving Away the Code?

Yes — and that’s not as scary as it sounds.

For technical customers (especially startups or agencies), self-hosted + licensed software can be a big selling point. They get control, compliance, and peace of mind.

And for you? You skip the DevOps, uptime monitoring, and scaling headaches.

You can even open-source a limited version and sell the “Pro” edition with additional features, integrations, or automation. That approach builds trust and lowers the barrier to entry — a model proven by countless successful tools (think Plausible, Sentry, or PostHog).

How to Make It Profitable (Without Recurring Revenue)

Let’s be real: one-time payments can kill you if you don’t plan for longevity.

You can’t promise lifetime updates for $49 and expect to survive.
The trick is to price for sustainability and design smart upsells.

Here’s a simple structure:

1. Base License (One-Time Purchase)
   The core product, installable and self-managed. One license per company, priced based on business value — not your costs.
   Example: $499 for the migration tool.

2. Pro or Enterprise Tier
   Unlocks advanced features like API access, audit logs, or multi-user setups.
   Example: $1,499 for the “Enterprise Migration Suite.”

3. Done-for-You Setup
   Not everyone wants to fiddle with YAML files or AWS permissions. Offer to set it up for them — fast, clean, and guaranteed to work.
   Example: $1,000 for installation and configuration.

4. Support Retainer (Recurring)
   For customers who do want ongoing help, offer an optional support plan — monthly or yearly — that they can cancel anytime.
   Example: $200/month for priority support and updates.

5. Fixed Support Packages
   For those who prefer predictability, offer prepaid support hours.
   Example: $800 for 10 hours of support, usable anytime within a year.

The combination of these makes your business sustainable.
You get upfront cash flow from licenses and setups, and optional recurring revenue from support — but without forcing subscriptions on everyone.

A Real Example: Indie Data Migration Tool

Let’s run the numbers.

You sell a self-hosted data migration tool.
You price it at $499 for the standard license.

In your first month, 10 teams buy it. That’s $4,990 upfront.

Out of those, 3 ask for the done-for-you setup at $1,000 each.
Now you’re at $7,990 total.

Two of those teams also sign up for your support retainer at $200/month.

That’s an extra $400 MRR — but it’s optional, not forced.

You’ve built something simple, useful, and profitable — without ever worrying about churn graphs, Stripe retries, or feature bloat to “increase stickiness.”

Actionable Takeaways

Match pricing to value, not format.
Don’t just copy the subscription playbook because everyone else does. Ask yourself: how often will people actually use this thing, and how much pain does it remove? If it’s a one-time fix, charge like it.

Design for autonomy.
Developers love control. Let them host it, own it, and plug it into their stack. You’ll end up with happier customers and fewer support tickets than you’d think.

Price like it matters.
If you’re selling a one-time license, it needs to cover your runway. Don’t shy away from bigger numbers. $499 for something that works beats $49/month for something people cancel in two.

Offer optional continuity.
You don’t have to force subscriptions, but you can still offer them. A support retainer or yearly update plan gives your best customers a way to stay connected — and gives you breathing room.

Keep it simple.
No servers, no churn dashboards, no “engagement loops.” Just build a tool, sell it, and support the people who need it. That’s still a business — and a pretty good one.

In a world obsessed with “monthly recurring revenue,” it’s refreshing to remember you can still build a sane, sustainable business by selling software the old-fashioned way — for a fair, one-time price.

Sometimes, the best “recurring” part of your business isn’t the billing.
It’s your reputation for shipping solid tools that solve real problems.