Build an App Without Code: Emergent Tutorial for First-Time Founders

Disclosure: This post contains affiliate links. If you buy through them, Create Digital Tools may earn a commission at no extra cost to you. We only recommend tools we think are a good fit for small businesses.

Getting a first version on screen is the easy part. The founders who come out ahead are the ones who scope one feature, test it properly and know what it costs to keep running.

You can build an app without code on Emergent by describing it in plain English, reviewing what the agent proposes, and testing the preview before you publish. This tutorial walks a first-time founder through the whole sequence in nine steps, from scoping a one-feature MVP to watching your credits after launch.

Everything below is based on Emergent’s own docs, tutorials and public pages, with pricing as of November 2026. Where the docs do not describe something, or where two official pages disagree, we say so. The sample prompts are illustrations we wrote for this guide, not transcripts of real builds.

How to build an app without code on Emergent: the nine steps

This post is the practical sequence only. If you are still deciding whether the platform suits your business, read our Emergent Labs review first. For detailed budgeting, see how to predict your Emergent credit cost.

1. Scope a one-feature MVP.
2. Write the first prompt.
3. Review the plan before anything is built.
4. Run the build.
5. Test the preview by hand.
6. Fix problems with follow-up prompts.
7. Add login, payments and data connections as needed.
8. Publish the app.
9. Watch your credits every week.

A few terms from Emergent’s “Start with your idea” guide will help. A job is one app or task, with its own chat, code and preview. The preview is a private, live-updating working copy. Publish puts the app at a permanent address. Credits pay for agent work by usage, plus a monthly fee to keep an app live.

Before you start: what each plan lets you do

Check this before you plan your launch date. The Free plan does not get you to a live app.

Plan	Price (November 2026)	Monthly credits	What matters for this tutorial
Free	$0	10	Build and preview only. Publishing needs a paid plan.
Standard	$20 a month, or $17 billed annually	100	Private project hosting, GitHub integration, task forking, option to buy extra credits.
Pro	$200 a month, or $167 billed annually	750	Adds a 1M context window, custom agents and priority support. Maxx mode is Pro only, per the docs.
Business	Custom, demo required	Not listed	Adds roles, single sign-on, shared workspaces and co-editing.
Enterprise	Custom, demo required	Not listed	Adds audit logs, self-hosted database support and deployment to your own cloud.

One inconsistency: the homepage FAQ mentions “$250/month for teams”, while the pricing page shows Business as custom with a demo request. Treat the pricing page as current and confirm with sales.

Step 1: Scope a one-feature MVP

Emergent’s own guide puts it simply: “The simpler your first idea, the faster you’ll see results.” For a founder, simple also means fewer credits spent on features nobody has asked for yet.

Before you open the tool, answer these on one page:

1. Who is the one user? Name a specific person, such as “a solo consultant’s client”, not “businesses”.
2. What is the one action? The thing they must be able to do for the app to have any value.
3. What proves it works? For example, five real people complete that action without your help.
4. What is out of scope for now? Write this list down. It is what you will refuse to prompt for during the first build.
5. Does it touch money or private data? If yes, read the security section below before you plan anything else.

A running example for this guide: a booking page for a solo consultant. Clients see open slots and book with a name and email. The consultant sees a list of bookings. Payments, reminders and client accounts wait until later.

If you want a structured way to do this, our business requirements document template for Notion has sections for scope, business drivers and functional requirements. It runs in Notion, and a short version is enough. Later, you can paste the relevant parts into your prompt.

Step 2: Write the first prompt

The docs say a good first prompt covers three things: what the app is for, who uses it, and one core action. The “Write prompts that work” guide expands that into purpose, 3 to 5 core features, a design hint and the feel of using it.

You do not need to specify a tech stack, database structure or file organization. The agent handles those. Here is an illustration for the booking example:

Build a booking page for a solo consultant. Clients see open 30-minute slots for the next two weeks and book one with their name and email. A booked slot disappears from the list. I need a separate page listing all bookings with date, time, name and email. Keep the design clean and minimal, and make booking take as few taps as possible on a phone.

The docs add that naming an exact detail, such as a slot length, cuts down back-and-forth.

Optional: get help drafting it from Emmy

Emergent’s Emmy tutorial describes a chat assistant in the bottom-right corner of every page. She does not write the code, but she can ask scoping questions, propose a version-one scope and draft a prompt for you.

Step 3: Review the plan before anything is built

This is the cheapest place to catch a misunderstanding. Build is the default mode, and the agent starts working as soon as you send a prompt. So switch first if you want to review.

1. Set the Build/Plan switch in the composer to Plan (the docs give Option+P as the shortcut).
2. Send your prompt. The agent returns a plan proposal card.
3. Read it against your scope page. Look for features you did not ask for, and missing ones you did.
4. Choose Request changes and say what is wrong, or approve with Looks good, let’s build it.

Nothing is built until you approve. Planning is not free, since every turn bills per token, but the docs say it uses noticeably fewer credits than a build turn. They also say a short discussion usually saves credits later.

A catch with agent choice

The Emmy tutorial shows an agent selector with E-1, E-2, E-3 and Cross Platform, and in its example Emmy recommends E-3. The docs also say Plan mode is not available in E3 or Brainstorm sessions. So if you choose E-3, you may not get the plan card described above.

In that case, use Emmy to agree scope before you build, and answer the agent’s clarifying questions carefully. The public pages we read offer no full guide to choosing between agents, so ask Emmy if you are unsure.

Step 4: Run the build

Once you approve or send in Build mode, the docs say the chat streams the steps: planning, scaffolding, implementation and automatic testing. The first build usually takes a few minutes, and the agent does not ask for approval at each step. It may ask clarifying questions early on.

Two things are worth doing before you press send:

• Set a per-session budget. The credits guide says you can set one on the task form. If the agent uses it up, the run pauses automatically. This is your best protection for a first build.
• Leave Maxx mode off for now. The docs say it plans more thoroughly and uses significantly more credits. Their advice is to save it for a final build, not planning.

Checkpoints are saved automatically each time the agent finishes a turn. When it is done, a live preview appears with a short summary of what changed. The docs do not describe a stop control in the build flow, so treat the budget as your documented limit. Jobs also have a 4-hour execution limit.

Step 5: Test the preview by hand

The agent runs automated tests, but its results are not a substitute for you using the app. Emergent’s “Try it before you share it” guide says to still run the manual checks after asking the agent to test. Here is that guide condensed into a checklist:

• Click everything. Every button, link and card should do something.
• Complete the core action. Do it start to finish, then confirm the result shows up where it should.
• Enter bad data. Submit empty fields, and put “abc” in an email field. You should get a helpful error.
• Check devices. Use the desktop, mobile and tablet view buttons, or open the preview URL on a phone. Look for overlapping text and cut-off buttons.
• Check the console. If data does not appear, look for red errors in the browser console.

Step 6: Fix problems with follow-up prompts

You do not need to start over when something looks wrong. The agent keeps the context of the chat, so reply in the same thread. Good bug reports follow a pattern from the docs: what you did, what you expected, what happened.

• Weak: “Booking is broken, please fix.”
• Useful: “On the booking page, I chose the 2:00 pm slot and pressed Confirm. I expected a confirmation message and for the slot to disappear. Nothing happened and the slot is still there. The console error is pasted below.”

Choosing between fix, rollback and fork

Situation	What the docs suggest	What to watch for
A small issue you can describe	Ask the agent to fix it	A “verified” fix means confirmed in preview only, since the agent cannot access your live app.
Unsure what broke, or several changes need undoing	Roll back to a checkpoint, then ask more narrowly	There is no roll-forward. Erased work cannot be recovered once you continue.
A big experiment, or the agent is stuck	Fork the chat (the + button in the chat input)	Chat history is summarized, not copied, so you may need to restate early details.

Rollback restores code, packages and database structure, but not database records, so old code may hit errors with newer data. It also only touches the preview. Your live app stays on its last published version until you re-publish.

Stop paying for loops

If the agent keeps repeating a failing fix, stop sending the same request. Describe what went wrong and what to try instead, or fork to start fresh. The docs say a detected loop “may” earn an automatic credit rebate, so treat that as a possibility, not a guarantee.

Step 7: Add login, payments and data as needed

Add these one at a time, after the core action works. Fork first if the change is large. One timing rule matters: the login guide says the database schema is set on your first publish, so add custom user fields before publishing for the first time.

Login and user accounts

Login is not included by default. You ask for it in chat. The docs describe Emergent Auth with two options:

• Email and password, with passwords stored hashed.
• Google sign-in, which works without your own Google Cloud setup. You can add your own client ID and secret for custom branding or extra scopes.

The docs give prompts such as “Make the dashboard page require login.” They say you can integrate Auth0, Clerk, Firebase Auth or Supabase Auth instead.

Do not skip this if your app holds private data. The “Keep it safe” guide is blunt: without login, all app data is visible to anyone with the link.

Payments

The docs say money goes from Stripe to your bank and that Emergent takes no cut. You pay your plan or credits plus Stripe’s fees. Razorpay and PayPal are listed for other markets, and mobile Expo apps use RevenueCat.

The default route in the docs looks like this:

1. Tell the agent what you sell and the prices, for example a single $50 deposit per booking.
2. Open the Payments tab through Manage, next to Preview, and click Claim Your Sandbox.
3. Complete Stripe registration and identity checks, then install the Emergent app in the Stripe dashboard.
4. Test with Stripe test cards: 4242 4242 4242 4242 succeeds, and 4000 0000 0000 0002 triggers a decline.
5. Confirm the success page appears and that your database records the sale.
6. Go live. In the managed route the docs say the platform handles this once identity checks are complete. With your own Stripe account, you swap in live keys under Custom keys and re-publish.

The docs warn that a typo in a pricing prompt can charge customers the wrong amount. If a payment succeeds but no access is granted, they point to webhooks as the likely cause.

Database and other tools

The docs say MongoDB is already included and recommend it as the starting database for beginners. The integrations page also lists Supabase, Airtable and Notion in its database category, along with many other services.

For other tools, curated connectors appear under Preview, then Manage, then Connectors, and some carry a small per-run credit fee. Any other service with a public API can be connected with its key, but expect more back-and-forth.

Never paste a real API key into chat. The docs are explicit about this, because chat content goes to the AI provider. Have the agent create the key name, then enter the value yourself under Preview, then Manage, then Secrets, then Custom keys. If you already pasted one, rotate it with the provider.

Step 8: Publish the app

The docs say going live requires a paid plan. The tutorials describe the flow slightly differently from each other (one says Publish, another says Deploy), so expect labels to vary. The general sequence is:

1. Make sure the preview is clean, and run the pre-deployment Health Check.
2. Click Publish in the top toolbar and confirm.
3. Wait for the first build. The docs say about 15 minutes, and the Emmy tutorial says roughly 10 to 15.
4. Get a permanent address such as your-app-name.emergent.host.
5. Add production secrets and check them. Then test again on the live address.

Things that catch first-time publishers

• Secrets split after publish. The “Keep it safe” guide says the first Publish copies .env values to production and the two sets are independent after that. The Emmy tutorial says preview secrets do not carry over automatically. Either way, check production values yourself, especially if the app works in preview but breaks live.
• The live database starts fresh. The Emmy tutorial says the first deployment produces a production build with a fresh database, so do not expect preview records to be there. Test your data flow again.
• Changes are not automatic. Preview edits reach your live app only when you click Re-publish. The docs say this has zero downtime and keeps the same address.
• Anyone with the URL can visit. Publishing makes the app public unless you built login into it.
• Shutdown has side effects. Shutdown stops the hosting charge, but custom domain links are removed and not restored automatically. It does not delete your databases or external services.

Custom domain

Go to Preview, then Manage, then Domain, then choose Auto-Link or link manually. DNS values differ across Emergent’s pages, so use the ones shown in your own domain panel. Cloudflare users should keep records on DNS-only (gray cloud).

Step 9: Watch your credits

This is the least predictable part of the process, because cost depends on how much work the agent does. The credits guide says one prompt can cost anywhere from a handful of credits to hundreds. It gives no exact per-unit rates.

What gets billed

• Code generation and testing, with bigger changes and deeper test suites costing more.
• A monthly fee for each live app.
• Service connections, scheduled jobs and background workers.
• LLM calls from your app, if it uses the Universal LLM Key. This one scales with your users, not your building.

The live app fee is not described consistently

The “Put your app live” guide says a live app costs 50 to 1,100 credits a month depending on publishing tier. The deployment tutorial simply says 50 a month per app, and the app builder page says 50 on Standard. The pages we could read do not list each tier’s cost, so check your own publishing panel before upgrading.

Here is the math on Standard. If a live app takes 50 of your 100 monthly credits, 50 are left for building and fixing. The Emmy tutorial says its client tracker example typically uses about 100 to 300 credits with E-3, so a similar build may not fit inside one Standard month without top-ups.

A weekly routine

1. Open Account Settings → Credit Usage and review the breakdown by category.
2. Set a per-session budget before any large prompt. Job budgets are separate from your account balance.
3. Shut down test apps you no longer need, since each live app carries a fee.

Other rules from the docs: monthly plan credits do not roll over, one-time top-ups never expire, and expiring credits are spent first. You get an email when your balance falls below 20% of your monthly allowance. At zero, work pauses and resumes after you add credits.

The pricing page says Standard can “purchase extra credits as needed” but gives no top-up price, so check it inside your account. For a fuller planning method, see our Emergent credit cost guide.

Security review: what the agent will not do for you

The homepage shows SOC 2 and ISO 27001 badges, and the “Keep it safe” guide says workspaces are isolated and data is encrypted. Those are vendor claims about the platform, not proof that your generated app has the right permission rules.

Emergent’s pre-launch checklist is a good minimum:

• No API keys or passwords hard-coded in source files, and none pasted in chat.
• Production Custom keys hold the correct live values, with test keys swapped out.
• Sign in as a test user and confirm users cannot see each other’s data.
• No sensitive data hard-coded in client-side JavaScript or HTML.

Test the third item with two accounts. The guide does not recommend an outside review, but we do if your app takes payments or stores personal data. Ask a developer to check access rules, webhooks and data exposure before launch, because a founder cannot judge those from the preview alone.

When to hire a developer

Emergent’s own comparison article suggests a developer when a project needs custom logic or integrations beyond a builder, when compliance or extreme scale applies, or when you want someone accountable if something breaks. It also describes a hybrid: build the first version, then export the code and bring in a developer for what outgrows it.

We would add a few practical triggers:

• You handle health, financial or children’s data, or you have a compliance obligation.
• Paying customers depend on the app, and you cannot explain how it works.

Who should not use this route at all: anyone with a fixed budget who cannot absorb unpredictable credit costs, anyone without time to test, and teams whose first version must meet a regulatory standard.

Code ownership and export

The homepage FAQ says “You own all the code Emergent generates” and that you can download, modify or host it anywhere. The app builder page answers “Can I export my code?” with “Yes, on paid plans,” and says connecting GitHub pushes the full codebase to your own repository.

The pricing page lists GitHub integration from Standard up, so plan on export needing a paid plan. A few cautions:

• The beginner docs we read include no step-by-step export guide. Connect GitHub early and confirm the code really arrives in your repository.
• Code is not the whole app. Data, secrets, your domain and platform-managed items such as Emergent Auth or the managed Stripe sandbox may need separate migration. The public pages we read do not describe a full migration path, so ask support.

Ready to try the sequence on your own idea? Start on Emergent’s Free plan to build and preview, then upgrade only when you have something worth publishing.

The bottom line

To build an app without code, keep the first version small, read the plan, test by hand and watch credits from day one. Emergent’s docs cover most of the path well, but costs remain hard to predict and the security responsibility stays with you.

FAQ

Should I start in Plan mode or Build mode?

Use Plan mode for a first build if your agent supports it, since nothing is built until you approve. It is not available in Brainstorm or E3 sessions.

Is an app built this way secure enough for customers?

It depends on the app and your checks. If you take payments or store personal data, get a developer to review it before launch.

Can I really build an app without code on Emergent?

The homepage says no coding experience is needed, and the docs are written for beginners. You still need to scope, test, spot problems and handle keys and DNS. Those parts are not automated, and more complex apps may need developer help.

Can I publish on the Free plan?

No. The app builder page says deploying needs a paid plan, and the Free plan’s 10 credits are for building and previewing. Standard is the lowest listed paid plan, at $20 a month or $17 billed annually.

How many credits will my app cost?

Emergent does not publish a per-unit rate in the guides we read. A single prompt can range from a handful of credits to hundreds. Its Emmy tutorial gives about 100 to 300 credits with E-3 for one example, and a live app takes at least 50 a month. Set per-session budgets and review Credit Usage.

Can I move my app off Emergent later?

Emergent says you own the code and that paid plans can push the full codebase to your GitHub repository to host elsewhere. Its public docs that we read do not give a full migration guide for data and secrets, so test the export early.