Build SaaS with Claude on $20 a Month

Key takeaways

• One founder used Claude Code and EARS requirements to reach $36,000 monthly recurring revenue on a single laptop.
• Total tooling and hosting spend stayed at $20 per month throughout validation and early growth.
• EARS syntax turns loose product ideas into precise prompts that Claude converts into working code.
• The workflow supports full-stack SaaS features including authentication, payments, and data persistence without external infrastructure teams.
• Common failure points appear when prompts lack the structure EARS provides or when deployment decisions ignore the single-laptop constraint.

What EARS actually is and how it pairs with Claude

EARS stands for Easy Approach to Requirements Syntax. It is a lightweight notation developed for embedded and safety-critical systems that forces every requirement into a trigger-condition-action format. When used with Claude, each EARS statement becomes a self-contained prompt that produces consistent, testable code rather than open-ended suggestions.

The syntax uses five main patterns: When, If, Then, While, and Until. Each pattern names the actor, the triggering event, any precondition, and the expected system response. Claude receives the EARS line plus the current file context and returns a diff that implements exactly that behavior.

Turning plain ideas into structured prompts

Begin with a one-sentence product goal such as "users can subscribe and receive usage reports." Break the goal into discrete behaviors: form submission, payment validation, record creation, and email delivery. Rewrite each behavior as an EARS sentence that specifies the trigger and the outcome. Feed one or two sentences at a time into Claude along with the existing codebase summary.

The model returns route handlers, database migrations, and utility functions that match the stated contract. After the code passes a local test, add the next EARS statement. This incremental loop prevents scope creep and keeps token usage inside practical limits. The founder maintains a running architecture note inside the chat that lists completed modules, allowing Claude to reference prior decisions without reloading the entire history.

Example EARS notation mapped to code output

An example EARS statement reads: "When a user submits a valid payment form, if the card is accepted by the processor, the system shall create a subscription record, mark the account as active, and send a confirmation email." Claude receives this line plus the current Express or FastAPI routes file and emits the matching POST handler, Stripe call, database insert, and email trigger.

The same pattern repeats for authentication, usage tracking, and report generation. Because each requirement is atomic, the founder can revert a single feature without touching unrelated code. In practice this produces 15-25 lines of new code per EARS statement when the prompt also includes the relevant file path and a one-paragraph summary of the current stack.

Real cost breakdown of the $20 monthly budget

The $20 figure covers Claude Pro at its current rate plus the lowest paid tiers of supporting services. Claude Pro supplies the primary coding model at roughly $20 per month. Vercel Hobby or Railway trial handles deployment at no cost during early validation. A managed Postgres instance from Neon or Supabase fits inside the remaining budget with 0.5 GB storage and 1 GB bandwidth. Stripe operates in test mode until the first customer arrives, after which live keys replace test keys with no extra monthly cost.

No paid monitoring, logging, or CDN services appear until revenue justifies them. The laptop itself supplies the development environment, local testing, and git pushes. Any additional API calls stay under free tiers during validation. The founder tracks exact spend in a simple spreadsheet that lists Claude Pro, one database connection, and domain registration amortized over twelve months.

▶ Play the video

The video shows the founder editing code that Claude produced moments earlier. The screen contains only the laptop, a browser window open to Claude, and a terminal running the local build. No additional machines or paid services are visible.

Step-by-step workflow from idea to working MVP

Open Claude and paste the initial EARS list for the core user journey. Ask the model to generate the first route and data model using the current project structure. Run the generated code locally with the chosen framework. When an error appears, paste the exact traceback and the relevant EARS statement back into Claude for a corrected diff.

Continue the cycle until the happy path works end to end. Only after manual verification of one requirement does the founder add the next EARS statement. The running architecture note inside the chat summarizes completed features so Claude maintains context across sessions without exceeding token limits. Each iteration typically takes 8-12 minutes from prompt to passing local test.

Week one focuses on authentication and the primary data model. Week two adds payment integration and basic reporting. By day 14 the founder has a deployable binary that accepts real payments. The same loop continues after launch for bug fixes and new features requested by early users.

Claude Code as the primary development tool

Claude Code accepts the full current file tree plus one or two EARS requirements in a single message. It returns diff-style patches that can be applied directly in the terminal or editor. The founder keeps conversation length manageable by summarizing completed modules in a persistent architecture note that travels with every new prompt.

This method supports full-stack work: frontend components, API routes, database schemas, authentication middleware, and payment webhooks. Because the model sees the entire tree, it avoids duplicate functions and respects existing naming conventions. When a new file is needed, Claude first proposes its path and imports, then the founder confirms before generation proceeds.

Context management relies on a 400-word rolling summary updated after every five EARS statements. The summary lists module responsibilities, key variable names, and external service endpoints. This technique keeps total prompt tokens under 8,000 even after the codebase grows past 3,000 lines.

From first commit to $36k MRR: realistic timeline

The first commit occurs inside the first day once the initial EARS list is ready. A usable MVP that accepts payments appears within one to two weeks of daily iteration. Customer acquisition begins once the MVP handles core workflows reliably. Revenue growth depends on distribution channels outside the technical stack, such as indie hacker forums, targeted outreach, or content marketing.

The $36,000 figure reflects the point at which the same single-laptop process supports enough paying users to reach that monthly recurring revenue. No additional infrastructure spend is required until the founder decides to add team seats or higher database tiers. Early revenue typically arrives between month two and month four when the founder posts the product in relevant communities and follows up with interested users.

Pricing math starts with a $29 monthly plan. At 1,200 active subscribers the product reaches $34,800 MRR before taxes and fees. The founder attributes roughly 40 percent of sign-ups to direct outreach and 60 percent to organic search and word-of-mouth after the initial launch posts.

Tooling alternatives: Claude vs Cursor vs other AI IDEs

Cursor provides inline edits inside an IDE yet still benefits from EARS prompts supplied in a separate chat window. Other models can generate code but require more prompt engineering to reach the consistency Claude achieves on structured syntax. The decisive factor remains the cost ceiling: only Claude Pro plus minimal hosting stays inside the $20 monthly limit while supporting full-stack generation.

A side-by-side comparison shows Claude 3.5 Sonnet produces fewer hallucinated imports and respects EARS constraints more reliably than GPT-4o or Gemini 1.5 Pro under identical prompts. Cursor shines for refactoring existing codebases but adds an extra subscription that would exceed the $20 budget when combined with Claude Pro. Local models such as CodeLlama require GPU rental costs that quickly surpass the entire monthly allocation.

The founder tested GPT-4o for two days early on and found it needed three follow-up prompts to match the accuracy of a single Claude 3.5 Sonnet response when given the same EARS statement. This difference directly affects iteration speed and therefore time-to-MVP.

Common pitfalls when using AI to write production code

Skipping the EARS step produces vague prompts that generate incomplete or hallucinated functions. Accepting large generated blocks without line-by-line review introduces security gaps such as missing input validation or exposed API keys. Ignoring local test runs before deployment leads to runtime failures once real traffic arrives.

The founder avoids these issues by treating every EARS statement as a contract that must be verified before the next requirement is added. Security reviews focus on authentication flows and payment handling first. Database migrations are always run against a local copy before production pushes. One observed failure mode involved Claude generating a webhook handler that did not verify Stripe signatures, which was caught during the local test phase.

Another common issue arises when the architecture note grows stale. If the summary is not updated after major refactors, Claude may suggest functions that duplicate logic already present. The founder dedicates five minutes at the end of each session to refresh the note, which prevents this drift.

Deployment, payments, and scaling on minimal infrastructure

Deployment uses a single-command push from the laptop to the chosen host. Payments are wired through a standard checkout library initialized with test keys that become live keys once the first customer arrives. Scaling begins only after revenue justifies additional instances; the initial architecture keeps state in a managed database so horizontal scaling requires no code changes.

Environment variables handle secrets. A simple health-check endpoint confirms the service is live. Once MRR supports it, the founder can move to paid hosting tiers or add a CDN without rewriting the application. Neon database usage stays under $5 per month until the product reaches roughly 800 concurrent users, at which point the founder upgrades to a $19 plan that still fits comfortably inside growing revenue.

The same single-laptop constraint applies to monitoring. The founder relies on built-in platform logs and a single email alert for critical errors rather than a paid observability stack. This choice keeps the monthly cost fixed until revenue crosses $10,000.

Originally explored in the source post.

Frequently asked questions

What exactly is EARS and how do you use it with Claude?

EARS is a requirements syntax that writes each behavior as a trigger-condition-action sentence. Paste one or two sentences plus the current code into Claude to receive matching implementation. The notation prevents ambiguous prompts and produces code that matches the stated contract.

Which Claude models or features work best for full SaaS builds?

Claude 3.5 Sonnet inside Claude Code delivers the strongest balance of speed and code quality for full-stack generation under the $20 budget. Projects stay in the same conversation thread with an architecture summary to maintain context across multiple features.

How long does it take to reach meaningful revenue with this method?

A working MVP appears in one to two weeks of daily iteration. Revenue depends on distribution channels and marketing effort, not the build process itself. The $36,000 MRR milestone reflects sustained customer acquisition after the technical foundation is stable.

What kind of SaaS product can realistically be built this way?

Any product whose core workflows can be expressed as discrete user actions and system responses fits the pattern. Examples include internal tools, niche marketplaces, simple SaaS dashboards, and automation utilities. Complex real-time collaboration or heavy machine-learning workloads exceed the single-laptop constraint.

How do you handle deployment and payments when running on one laptop?

Use hosted platforms that accept git pushes and provide free or low-cost tiers. Add a payment library with environment variables for keys; switch to production keys only after the first successful test transaction. Managed databases handle persistence so the laptop only needs to push code.

What are the main limitations of letting Claude write production code?

The model can produce insecure defaults or incomplete edge-case handling. Every generated block must be reviewed against the original EARS statement and tested locally before deployment. Larger codebases eventually require manual architecture decisions that exceed simple prompt-response cycles.

Can this approach scale beyond the initial $36k MRR?

Yes, provided the architecture keeps state in managed services and the founder adds paid tiers or team seats only after revenue justifies the cost. The same loop that produced the first revenue line continues to support iteration as the customer base grows.

The same loop that produced the first revenue line continues to support iteration as the customer base grows.