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.
This is the part that decides whether you make money, before you touch either tool. Three rules:
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.
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.
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.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
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].Run all seven before you show it to a single real person.
Get people using it free first, then charge. Here is the honest order:
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.| Item | Cost | Notes |
|---|---|---|
| Claude | $0-20 | Free plan runs the scoping chat; Pro (~$20/mo) if it's part of your day |
| Emergent Standard | ~$20 | 100 credits; one deployed app holds ~50/mo; top-ups ~$10 per 50 |
| Stripe | $0 + per sale | No monthly fee; ~1.75% + A$0.30 per domestic card charge |
| Domain (optional) | ~$1-2 | About $10-20/yr; connect it to your app for a real brand |
| Rough total to run | ~$20-42/mo | Plus Stripe's cut only when you get paid |
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.