How to make money building real apps with Claude and Emergent ⚡

The one that got me thinking 💭

Sebastian Volkis (x.com/sebastianvolkis) publicly posted around $21k in one month. Only about $5,500 of that was a SaaS tool he built with AI in four days (TrendFeed, which finds trending news and drafts short-form scripts); the rest was his personal brand and a course, and he says the month was brutal. So no, this is not push-a-button money. But the mechanic underneath is real and repeatable: one person, no engineering team, shipped a small paid tool fast and people paid for it. The lesson is not "copy his app", it's copy his approach: build small, launch in days not months, and only scale the ones people actually pay for.

The strategy: pick small, specific, and already-paid-for 🎯

This is the part that decides whether you make money, before you touch either tool. Three rules:

1. Small. One job, one screen or two, one type of user. Not a platform, not "Uber for X". A tool you could describe in one sentence.
2. Specific. A narrow audience beats a broad one. "Invoice reminders for freelance photographers" outsells "an invoicing app". Narrow means you know exactly who to sell to and your tool fits them perfectly.
3. Already paid for. The safest ideas replace something people already spend money on, or save them time they currently pay for. If people are already paying (for a clunky tool, a VA, a spreadsheet consultant, a $200 course workaround), the demand is proven. You are not creating a new habit, you are doing an existing job better or cheaper.

Real tool shapes with the kind of prices solo builders actually charge:

Single-feature tools like Plausible (privacy analytics) and Healthchecks.io reached $5k-30k a month with a solo founder behind them. You are not aiming there on day one. You are aiming at your first paying person.

How the two tools split the work 🧩

1. Claude (claude.ai or the desktop app) is your spec engineer. It interviews you, helps you pick a small monetizable tool, then writes a build-ready spec: the written blueprint of exactly what to build.
2. Emergent is the builder, and it builds with Fable 5 (Anthropic's newest Claude-family model) under the hood. A team of AI agents (architect, designer, developer, tester) turns that spec into a working full-stack web app (React front end, FastAPI back end, a real database, with email-and-password login built in) and deploys it to a live URL. "Live app" means a real website with its own link that people open in a browser, nothing to install.

Why this split works: Emergent's architect agent reads your first prompt and turns it into data models, screens, and flows. A spec that already arrives organized that way builds far better on the first pass, and that is exactly what the Claude prompt below produces.

Step 1: scope and pick the idea with Claude 🧠

Open a new Claude chat and paste the prompt below. It does two jobs in order: first it asks you 3-5 questions to land on a small, specific, monetizable tool (not "the next big app"), then it writes the full build spec you paste into Emergent. Answer honestly from what you actually know and who you actually have access to, then copy the spec it returns.

You are my spec engineer and product coach. I want to build ONE small, specific, paid software tool that a non-technical person can ship with Emergent, an AI app builder that turns a written spec into a working full-stack web app. My goal is real revenue, not a big idea. Your job has two phases: first help me pick a tiny monetizable tool, then write ONE build-ready spec I can paste into Emergent as my very first prompt with zero edits.

PHASE 1, DISCOVERY. Before writing anything, ask me 3 to 5 questions in a single message, then stop and wait for my answers. Only ask questions whose answers change what we build. Pick from: what industry, hobby, or group of people I already understand or have access to; a task those people currently do in a spreadsheet, by hand, or by paying someone; what they use today and roughly what it costs them; what specific outcome would make them happily pay a small monthly fee; and whether I want a tool people use repeatedly (subscription) or once (one-time). Do not ask about tech stack, hosting, or design taste.

PHASE 1 OUTPUT. After I answer, propose 3 concrete tool ideas that are each small (one core job), specific (a narrow audience), and already-paid-for (they replace an existing cost, tool, or time sink so demand is proven). For each: one-sentence description, exactly who pays, what it replaces, a starting price ($9 to $49/mo is the sweet spot for a v1), and why it is buildable as a small first app. Then recommend ONE and tell me plainly why. Ask me to confirm or pick, and stop.

PHASE 2, THE SPEC. Once I confirm an idea, write the spec using exactly this structure, because the builder's architect agent parses data models, screens, and flows directly:

- Write it in second person to the builder ("Build a web app that...") so it pastes clean.
- Keep it 600 to 1,000 words. Specific enough to build, short enough that nothing gets ignored.
- Section 1, What this app is: 2-3 sentences. Who logs in, what the one core job is, and who pays.
- Section 2, Data model: every entity with every field, its type (text, email, number, currency, date, datetime, dropdown with the exact options, boolean, long text), required or optional, and the relationships between entities. Cover at minimum: User (the paying customer), plus the 2 to 4 entities the core job needs. Do not invent fields nobody will use.
- Section 3, Screens: a numbered list. For each: screen name, who sees it (logged-in customer, or public), what is on it, and its one primary action. Include at minimum: a public landing page that explains the tool and its price with a "Sign up" button, a simple email-and-password signup and login, the main tool screen where the core job happens, and a basic account/settings page.
- Section 4, User flows, step by step: (1) a visitor lands on the public page, understands the tool, and signs up with email and password. (2) a logged-in customer does the core job end to end (spell out every click). (3) the customer sees their result or saved work when they log back in later.
- Section 5, Business rules and edge cases: what a brand-new empty account sees (an encouraging empty state, never a blank screen), validation on every input, what happens on duplicate signups, and how a customer's data stays private to their own account.
- Section 6, Payments note (put this heading in caps): the app must ship v1 with a simple email-and-password signup and NO payment processing yet, so I can test with real users for free first. But structure it so a paid plan is easy to add later: include a "plan" field on the User (free or paid) and gate nothing yet. In a short PAYMENTS-LATER note at the end of the spec, describe in 3 to 5 sentences how I would later add Stripe Checkout so paid users get plan = paid, without building it now.
- Section 7, Explicitly OUT OF SCOPE (caps heading): no payments in v1, no email or SMS sending, no mobile app, no admin dashboard beyond my own login, no AI features unless the core job genuinely needs one, no team or multi-user accounts. Tell the builder not to add these even as "nice to haves".
- Section 8, Acceptance tests: 6 to 8 checkable statements that prove v1 works, phrased as "I can..." (for example "I can sign up, log in, do the core job, log out, log back in, and my work is still there").
- End the spec with: "Seed the app with a small set of realistic demo data so every screen renders with content on first load."

HARD RULES for the spec: no vague words (some, various, robust, user-friendly), replace them with specifics. Every field gets a type. If my answers leave a gap, make the smallest sensible decision and tag it "ASSUMPTION:" inline so I can override it. Do not add features I did not ask for. After the spec, list all assumptions in one short block so I can correct them before I paste.

Step 2: build it in Emergent 🛠

What to expect: paste the spec, and a working preview usually appears in a few minutes, with a full first build of something this size done in roughly 15-30. When you deploy, you get a live URL with SSL, and you can connect your own domain later.

Try it here: Emergent

1. Paste the whole spec first. Start a new build and drop in the entire spec from Claude as your very first message. Don't summarize it, the detail is the point. Answer any clarifying questions in one message.
2. Preview before you deploy. Click through everything first. A deployed app holds around 50 credits per month, so ship only when v1 actually works.
3. Connect GitHub on day one. Your code syncs there, which is your safety net and your proof of ownership.
4. One change per follow-up message. Bundle closely related tweaks ("settings page with profile editing and a plan field") into one prompt to save credits.
5. Be surgical, not vague. "The signup button doesn't redirect after success, send the user to the main tool screen" beats "signup is broken". Vague prompts are the number one credit burner.
6. Roll back, don't argue. If a bug survives two fix attempts, revert to the last good checkpoint (rollbacks are free, fix-loops cost credits). Fork before anything risky so your working version stays safe.

Step 3: iterate, one change at a time 🔁

First builds come out roughly 80% right, and that is normal, not failure. Plan on 3-5 rounds. The order matters: structure first (fields, screens), then behavior (the core job, signup), then paint (style), then data, because a style pass before structural changes gets clobbered. Everything in [brackets] is a placeholder with a worked example, so swap in your own values.

1. Fix the core job first

The main tool screen is the heart of this app. Right now when a logged-in customer does [the core action], it [what goes wrong]. It should: [the exact step-by-step behavior you want, including what saves and what they see after]. Do not change signup, the landing page, or the account page while you fix this. Done when a logged-in customer can [core job] and see the correct result, and it is still there after they refresh.

2. Make signup and empty states friendly

Improve first-time experience only. On signup, after a customer creates an account, take them straight to the main tool screen with a short one-line welcome. If they have not created anything yet, the main screen shows a friendly empty state that explains what to do first and a single clear button to start, never a blank screen. Validate the signup form: real email format, password at least 8 characters, and a clear message if the email is already registered. Do not change the core job logic. Done when a brand-new account lands somewhere encouraging and never sees a blank page.

3. Landing page that sells it

Rewrite the public landing page to sell this tool to [exact audience, e.g. freelance photographers]. Structure: a headline naming who it is for and the outcome, 3 short benefit points, one line on the price ([$19/mo]), and a single "Sign up" button that goes to signup. Keep it honest and specific, no fake testimonials. Match the app's colors. Do not touch any logged-in screen. Done when a stranger reading the page understands in 10 seconds what it does, who it is for, and what it costs.

4. Style pass (swap in your own colors)

Style-only pass. Do not change any logic, data, flows, or page structure. Apply this look everywhere: background [#FAF7F2 cream], primary buttons and active states [#D97757 orange], dark warm gray text, one font family throughout [Poppins], rounded corners, generous spacing. The public landing and signup pages should feel friendly and minimal; the logged-in tool screen stays clean and focused. Keep every element in its current position, change only colors, typography, and spacing. Done when every screen uses this palette and all acceptance tests still pass.

5. Bug fix template (reuse for anything broken)

Bug report. On the [screen] page I did [exact action]. Expected: [X]. Got: [Y]. Fix only this bug, do not refactor or change any other feature while you are in there. Tell me the cause in one sentence, then confirm the fix. Done when [the expected behavior happens].

Step 4: test it like a paying customer ✅

Run all seven before you show it to a single real person.

1. Signup: create a fresh account from an incognito window with a real email and password. You should land somewhere useful, not a blank page.
2. The core job: do the one thing the tool exists to do, end to end. This is the whole product, so it has to feel obvious.
3. Persistence: log out, log back in, and check your work is still there. Refresh the page too.
4. Privacy: create a second account in another browser. Account two must never see account one's data. Non-negotiable if people are trusting you with their info.
5. Empty state: a brand-new account should see an encouraging "here's how to start", never a broken-looking blank screen.
6. Validation: try a bad email, a short password, and a duplicate signup. Each should show a clear, human message.
7. The stranger test: send the live link to one friend who fits the audience and watch them use it without your help. Where they get stuck is your next iteration prompt.

Step 5: price it and take signups 💵

Get people using it free first, then charge. Here is the honest order:

1. Ship v1 with free signup, no payments. This is on purpose. You want 5-10 real people using it and telling you what is missing before you build a checkout. The prompt above already sets it up this way.
2. Pick a simple price. For a v1 tool, $9 to $49/mo is the sweet spot. One plan, one price. Do not build three tiers on day one. If you are unsure, price it a little higher than feels comfortable; too cheap signals "toy".
3. Charge once you have a few fans. When a handful of people would be annoyed if the tool disappeared, add payments. That is your signal there is something worth charging for.

How payments actually work: the standard tool for recurring payments is Stripe. It charges per transaction (in Australia, roughly 1.75% + A$0.30 on domestic cards, more for international), with no monthly fee to start, so you only pay when you get paid. The simplest setup is Stripe Checkout: a hosted payment page you send customers to, so you never touch card details. Good news for achievability: Emergent has a built-in Stripe integration and lets you test with Stripe's test keys before going live, so this is a real prompt, not a "figure out code" project. When you have a few fans, wire it in:

Add Stripe Checkout for a single paid plan at [$19/mo]. Flow: a logged-in free user clicks "Upgrade", goes to Stripe Checkout, pays, and on success their account's plan becomes "paid" and they return to the app with a "you're on the paid plan" confirmation. Use my Stripe test keys first so I can test with Stripe's test card before going live. Do not gate any features yet beyond showing the upgrade button to free users. Tell me exactly which Stripe keys and settings you need from me and where to paste them.

The honest part (read this before you quit your job) 🫶

• Building it is the easy 20%. Marketing it is the other 80%. A live app with no users makes $0, which is exactly why Step 1 anchors on a specific audience you already reach.
• Payments are a separate afternoon. Stripe means identity verification and a bank account, not five minutes.
• It is not free to run. Owning one live app is about $20/mo before Stripe's cut, tiny next to what the tool can earn. Here is the full math:

Quick answers 💬

Do I need to know how to code? No. Claude writes the spec in plain language, Emergent writes the actual code and hosts it. Your job is judgment: pick the right small idea, describe it clearly, test it, and sell it.

What should I build first? The smallest tool for a group of people you already understand or can reach. If you photograph weddings, build something for photographers. Access to the audience beats a clever idea.

How do I take money? Stripe. It is the standard, there is no monthly fee to start, and Stripe Checkout means you never touch card details. Add it after you have a few free users who love the tool.

What if the first build comes out wrong? Normal. Expect roughly 80% right, then 3-5 iteration prompts. If it keeps drifting, fork or start a fresh build with a tighter spec instead of patching forever.

How many Emergent credits will this take? Ballpark 60-150 credits for a first build like this. Small tweaks cost 1-2, a new feature 5-10, and one deployed app holds around 50/mo. Burn varies with how much fixing you do, so specific prompts and free rollbacks are your best economy. Top-ups are about $10 per 50 credits if you run out.

Will I actually make money? Building it is the easy part. Whether it earns depends on picking something people already pay for and getting it in front of them. The app is the tool, not the business. The business is you knowing a specific group of people and solving one real problem for them.

The move 💡

Links used in the reel 🔗

1. Sebastian Volkis (the ~$21k/month post): x.com/sebastianvolkis
2. Try Emergent: app.emergent.sh
3. Emergent pricing and credits: https://emergent.sh/pricing
4. Stripe pricing: https://stripe.com/pricing
5. Claude: https://claude.ai