How to Build an App Without Coding, Then Check It Yourself

To build an app without coding, describe it in plain English to an AI app builder, then improve it one change at a time until it does what you need. Before you share it with anyone, run three checks you can do yourself: one on saved data, one on privacy and one on secret keys.

Getting a first version on screen is the easy part now. The part no tool can sign off on for you is checking where the data goes and who can read it, so I spend most of this guide there.

We'll follow one example from idea to live link: a private workout log, where each person signs in and nobody can read anyone else's entries. It's built with Dyad, the free, open-source app builder we make.

The short version

1. Write down what the app does in one sentence, and plan a web app first.
2. Choose a builder and an AI model.
3. Describe the screens, then change one thing at a time.
4. Add a database and login (check 1).
5. Lock each person's data to their account (check 2).
6. Test it like a stranger, and check for secret keys (check 3).
7. Put it online.
8. Keep the code, and know what to do when something breaks.

1. Write down what the app does, and plan a web app first

Write one sentence: who uses it and what they get. For our example: "Each person logs their workouts and sees their weekly total, and nobody sees anyone else's." Then list the screens. Three is plenty for a first version: a list of workouts, a form to add one, and a weekly total.

Start on the web, even if you picture the app on a phone. A web app opens in any phone's browser, and you share it with a link.

App stores add cost: Apple charges $99 a year and Google Play a $25 one-time fee, and building for iPhone needs a Mac. Dyad can wrap a web app as a phone app, but that feature is experimental. Get the web version working first, then read our mobile app guide.

2. Choose a builder and an AI model

You'll run into two kinds of no-code tools. Drag-and-drop editors have you arrange ready-made blocks on screens inside the tool. AI app builders write the code for you while you describe what you want in a chat, which people often call vibe coding.

This guide uses an AI app builder that writes the code into a folder you own. Drag-and-drop editors, and some AI app builders, run in a browser tab and host the app and its database for you. That's less to set up, and if you don't care about owning the code, it's the simpler pick. Dyad is a desktop app, so you'll connect a database yourself in step 4 and a host in step 7.

Ask any builder three questions before you start:

• Where does the code live? You want code you can open and run without the tool. If the code only comes out through an export button or a paid plan, ask what happens after you export: can you keep building in the tool, or are you on your own from that point? In Dyad, every app is a normal folder on your computer, and that folder is a Git repo (a project with its full change history). You can open it in VS Code or Cursor any time.
• Which AI models can you use? You want a choice, because models differ in price and skill. If the only option is the builder's own credits, you can't shop around when prices change. Dyad works with your own API key from a provider such as OpenAI, Anthropic or Google, a free local model through Ollama or LM Studio, or your ChatGPT subscription.
• Who holds your data? If the database lives inside the builder's account, leaving means moving your users' data out first. Dyad doesn't host a database for you. You connect your own Supabase or Neon account, so the data sits in an account you own.

With your own key, you pay the AI provider for what you use. A local model has no usage bill, though smaller models can have trouble following Dyad's instructions.

To set up, download Dyad for macOS or Windows (Linux is experimental). Its home screen walks you through the rest. First it asks you to install Node.js, the free program that runs your app's code on your computer, and points you to the right installer. If that step gets stuck, our Node.js help page covers the usual fixes. Then add an AI key.

Dyad's quickstart suggests a Google Gemini key, because it has a free tier. On that free tier, Google may use your prompts to improve its products, AI models included. If you'd rather it didn't, turn on billing for the key's Google Cloud project, because Google doesn't use paid prompts that way. Or run a local model, and your prompts never leave your computer. Our guide to using your own API key compares the paid options.

3. Describe the screens, then change one thing at a time

Describe the screens and what a person does on each. "Build a workout app" leaves the AI to guess everything, and it will guess confidently. This works better:

Build a workout log. Screen 1: a list of workouts, newest first, showing date, type and minutes. Screen 2: a form to add a workout. Screen 3: total minutes this week. Keep the design simple and make it work well on a phone.

Dyad shows the code it wants to write. Approve it, and Dyad runs the app in a preview next to the chat. After that, ask for one change per message ("show the weekly total as a bar chart") so you can see what each one did. Dyad's docs give good advice here: if you ask for a small tweak and it edits several files, something likely went wrong, so undo it.

You can always undo, because Dyad saves a version every time it edits your code. Need a stronger first prompt? Try our AI app prompt generator, or borrow one from these vibe coding project ideas.

4. Add a database and login

Dyad's default starter project runs all of its code in your browser, with no server of its own behind it. Your first version may not save workouts at all, so a refresh wipes them. If it does save them, they live only in that browser (in its local storage), so your phone, a friend and a private window see none of it.

Our example needs accounts anyway, so ask for the database and login together:

Save workouts in a Supabase database and add login, so each person has their own account.

Dyad will ask you to connect Supabase, a hosted service that gives your app a database and sign-in. Give each app its own Supabase project. You can share one between apps, but Dyad's docs call a separate project simpler and safer, and I agree. The checks below use Supabase, but the ideas carry over to any hosted database.

Two Supabase surprises catch people in their first week:

• New users must confirm their email before they can sign in. You can turn that off in Supabase's settings.
• On the free plan, a project pauses after a week with no activity, and you get two active projects. With one project per app, that's two live apps at a time.

Check 1. Is the data saved in the database?

Click Open in browser in the preview toolbar, sign in and add a workout. Then copy the address into a private window and sign in as the same person. The workout must be there. If it isn't, open your Supabase project and look at the workouts table in the Table Editor. No row means the app isn't saving to the database yet. A row that's there means the app saves it but can't read it back. Either way, tell Dyad exactly what you saw and run the test again.

For more on what Supabase adds, see our guide to building with Supabase.

5. Lock each person's data to their account

If you only do one check on this page, do this one.

Login tells the app who someone is. Row level security, or RLS, decides what they can see: it's a rule inside the database that works like a filter on every request, so a signed-in person only gets back the rows that belong to them.

Supabase's own advice is to turn RLS on for every table your app can reach. A table without it can be read and changed by anyone who signs up for your app, and on many projects by anyone at all who has its publishable key (the public key that ships inside your app's code).

Dyad creates tables by running SQL (written database commands), and tables made that way don't get RLS turned on by themselves, so its built-in instructions tell the AI to turn it on for every table. An AI can still miss one, and Dyad's docs tell you to review the rules. I'd rather you learn what RLS does than trust any builder, ours included, to get it right every time.

For our example, a good rule reads like this: a person can read, add, change and delete only the workouts saved under their own user ID.

In October 2026, the security firm UpGuard reported 16,326 Supabase databases with tables anyone could read, and over half held what looked like personal data. Earlier in 2026, Wiz researchers reported that Moltbook, a social network for AI agents, had exposed 35,000 email addresses and 1.5 million API tokens because its database had no RLS rules, so the public key in its app could read everything. More on these risks in our guide to vibe coding security.

Check 2. Can one user read another's data?

Three parts. Parts 1 and 2 look at the database, part 3 looks at the app, and you need all three.

1. Run Supabase's Security Advisor. Open your project on supabase.com and run the Security Advisor. It flags tables with RLS turned off, along with other badly set up RLS rules. None of your tables should show up in its RLS warnings.
2. Read the rules. In Supabase's Table Editor, open the workouts table's menu and choose View policies. Every table with private data should have rules that mention the user's ID, something like auth.uid() = user_id (the column name can differ). Then ask Dyad: "List every table and its RLS rules in plain English." The dashboard shows you what's there, and Dyad's answer tells you what it means. Any rule that lets everyone, or every signed-in person, read a table of private data is wrong, even if the Advisor didn't flag it. Ask Dyad to fix it and check again.
3. Try it as two people. Sign up twice, with two real email addresses (confirm both, or turn email confirmation off first), one in a normal window and one in a private window. Add a workout as the first person, then sign in as the second. The list must be empty.

Part 3 alone isn't proof. An app can hide other people's rows on screen while the database still hands them to anyone who asks.

6. Test it like a stranger, and check for secret keys

Before anything goes public, use the app like a stranger would. Sign out and see what a visitor sees. Submit the form empty, and type letters where minutes go. Shrink the window to phone width. Refresh on every screen. Then ask one real person to try it while you watch.

Next, run Dyad's security review: open the Security panel at the top right and click Run Security Review. It's an AI review and still experimental, so it can miss things. Use it alongside the three checks.

Check 3. Is a secret key showing in the browser?

Once your app talks to Supabase, it has keys of its own, apart from the AI key Dyad builds with. One of them is fine for anyone to see: the Supabase publishable key, as long as RLS is on, because RLS decides what that key can reach. Two must never show up in the browser. Supabase's secret key skips every RLS rule, and an AI provider's key, if your app calls an AI model itself, lets anyone who finds it run up your bill.

Do this on your own computer now. You'll run the same searches again on the live app in step 7.

1. Open the app in Chrome. If Open in browser opened a different browser, copy the address into Chrome.
2. Click through every screen, so the browser loads all of the app's files.
3. Open DevTools (Command+Option+I on a Mac, F12 on Windows), then press Command+Option+F on a Mac or Control+Shift+F on Windows. This searches every file the page loaded.
4. Search for sb_secret_, the start of every Supabase secret key. Then search for the last 15 characters of each secret key your app uses. Take them from where you saved the key, or from Settings, then API Keys in the Supabase dashboard. The end of a key is unique to it, while the start is shared by many keys. Don't paste any part of a key into Dyad's chat.

You want every search to come back empty. That means no key is sitting in the files the browser loaded, which closes one way in. It doesn't make the app safe in every other way.

If a key does show up, don't publish yet:

1. Ask Dyad to move the code that uses the key into a Supabase Edge Function (a small piece of code that runs on Supabase's servers, not in the browser).
2. Create a new key in the provider's dashboard, and save it as an Edge Function secret in Supabase, so only the Edge Function can read it.
3. Once the app works with the new key, turn off the old one.

Replace the key even if you never published. Dyad saved a version of your code with the old key in it, and anyone who later sees your code's history, on GitHub for example, could find it.

7. Put it online

1. In Dyad, click Connect to GitHub, then Sync to GitHub to push the code to a repository in your GitHub account.
2. On vercel.com/new, import that repository.
3. Before you click Deploy, look at Environment Variables. For this app there's nothing to add. Dyad writes your Supabase address and publishable key into the app's code, and check 3 showed why that key is fine to ship. If you add a service later that needs a setting here, ask Dyad for the exact name.
4. Never add a secret key there. In a starter app like this one, every setting the app reads ends up in the browser, which is why check 3 moves secret keys into an Edge Function. If you add a variable later, redeploy, because Vercel only applies new variables to the next deployment.
5. Click Deploy. Your live address looks something like your-app.vercel.app.
6. In Supabase, open Authentication, then URL Configuration. Set Site URL to your live address and add it under Redirect URLs, as Supabase's docs tell you to for a Vercel app. Dyad can add its preview's address to that list, but not your live one. Until you do, Supabase sends new users' confirmation links to the Site URL, which starts as http://localhost:3000, so the link opens on their own computer and fails.
7. Open your live address, sign up with a new email, confirm it, and repeat the check 3 searches.

Anyone can open that address. Vercel's free Hobby plan is for non-commercial use only: if the app takes payments or advertises a product, you need a paid plan. Our free Vercel deploy guide walks through each screen.

8. Keep the code, and know what to do when something breaks

The code has been on your computer since the first prompt, and now it's on GitHub too, so there's nothing to export. If you hire a developer later, they clone it from GitHub, open it in their own editor and carry on. If you switch tools, the code comes with you.

Once people use the app, two habits matter most.

• Export your data before a big change. Restoring a version in Dyad rolls back code, not data, so it can't bring back deleted rows, and the Supabase free plan has no automatic backups. In Supabase's Table Editor, open a table's menu and choose Export data, then Export table as CSV.
• Describe the symptom, then paste the error. "After I click Save, the page goes blank" beats "it's broken". Paste the full error message, or click Fix with AI when Dyad shows one. Our list of prompts for fixing vibe-coded apps covers the common breaks.

Questions people ask

What's the first app you'd build this way, and who's going to sign into it?