Make Things: Build an App Without Code
This content was developed with AI assistance and is regularly reviewed for accuracy.
Snapshot: October 2026. Model names, prices, and product features change monthly; What's New in AI is the maintained chronology.
You can now describe an app in plain English and get a working one: a budget calculator to share with your family, a sign-up form for a club, a dashboard for your team's tracker, even a small web product with logins and a database. People call this vibe coding, and it became a real commercial category in 2026, with prompt-to-app builders such as Lovable and Replit reported at hundreds of millions of dollars in annual revenue. This page shows which kind of tool fits which kind of app, a workflow that gets you to something usable, and the security review you must not skip.
Learning focus
- Choose between a mini-app inside your assistant and a full app from a dedicated builder
- Write a one-page spec that a builder can act on, and grow the app one feature at a time
- Run a security and privacy review before real people or real data touch the app
- Know when a project has outgrown no-code and needs a developer
Three sizes of app
Most beginners reach for the biggest tool first. Start with the smallest one that does the job.
A mini-app inside your assistant. For a calculator, a quiz, a checklist, a simple chart, or a one-page tool, you do not need a separate product. Claude builds interactive artifacts, small working apps that appear beside the chat and can be shared by link, on every tier including free. In Gemini, a Gem is a custom assistant with saved instructions, and Opal, reachable from the Gems manager since December 2025, turns a description into an editable list of steps and then a hosted mini-app you can share. These are the fastest path from idea to something a friend can click.
A full app from a builder. When you need user accounts, a database that remembers things between visits, or a public web address, use a dedicated builder. The ones 2026 reviewers recommend most often for non-developers:
| Builder | Best fit | Watch for |
|---|---|---|
| Lovable | Full web apps with logins and a database (it sets up a Supabase backend for you); the consensus first pick for non-technical founders | Database access rules need checking before launch |
| Bolt.new | Fast prototypes and demos you will throw away or rebuild | Reviewers say its code usually needs a rewrite for production |
| Replit | Learners and hobbyists who want to see and gradually understand the code, including mobile apps | Agent sessions use credits quickly; set a spending cap before long builds |
| Base44 (owned by Wix) | Data-heavy internal tools and admin dashboards, with a path to app-store publishing | Much of its coverage is sponsored; test it yourself |
Several comparison articles disclose affiliate arrangements with these vendors, so treat rankings as opinions and try two builders on the same small idea before committing.
A business tool on what you already have. If your company runs on Microsoft 365, Power Apps and the agent builders inside your suite may be the approved route. Individuals can no longer create new Custom GPTs as of August 2026; OpenAI moved that role to Workspace Agents on business plans. Check with IT before you build anything that touches company data.
Write the spec before the first prompt
Builders respond to a clear brief just as assistants do; the Brief lesson's six fields map neatly onto an app. Write one page before you start:
Objective: An app that lets [who] do [the one main job], so that [why it matters].
Users: [who signs in, if anyone; what each type of user can see and change]
Data: [what the app stores, e.g. name, email, booking date; what it must never store]
Screens: [the 3-5 screens, one line each]
Constraints: Works on phones first. Plain, accessible design. No payments in version 1.
Verification: List how I can test each feature, and run your security check before I publish.
Then build in slices. Ask for the smallest version that does the main job end to end, try it yourself, and add one feature per round: "add an email confirmation when someone books," then "add an admin page that lists bookings." Each slice is easy to test and easy to undo. If the builder offers a plan mode or a chat mode that discusses before changing code, use it for anything bigger than a small tweak.
When something breaks, describe what you did, what you expected, and what happened instead, and paste the exact error text. After two failed fixes, roll back to the last working version (every builder keeps a history) and approach the feature differently. This is the same restart rule as in Check, and it saves more time here than anywhere else.
Run the security review
This is the step that separates a demo from something you can let strangers use. One 2026 review reported that the median vibe-coded app fails its first security audit (single source), and the failure pattern is consistent: the app works perfectly while leaving its data open to anyone who knows where to look. Builders generate what you asked for; they do not automatically guard what you forgot to mention.
Before you share the app beyond yourself, run this review:
- Logins and access. Can a signed-out visitor see or change anything they should not? Can one user see another user's data? Test it by signing up as two different people.
- Database rules. Ask the builder directly: "Explain who can read and write each table in plain language, and turn on access rules so users can only see their own records."
- Secrets. API keys and passwords must live in the builder's secrets or environment settings, never in the page code. Ask: "List every key or secret this app uses and where each is stored."
- Real data. Use made-up test data until the review is done. Apply the traffic-light rule from Protect: no customer, health, or payment data in a no-code app without a professional review.
- A second opinion. Run the builder's own security scan if it has one, then open a fresh conversation with another assistant, describe the app and its data, and ask it to list the ways it could leak or be abused.
- Costs. Set spending limits on the builder and on any AI service the app calls, so a bug or a busy day cannot run up a surprise bill.
Get a developer involved before you take payments, store sensitive personal information, or rely on the app for anything a business cannot afford to lose. A no-code prototype is still a fine way to start that conversation: you arrive with a working demonstration of what you want instead of a description.
Keep ownership of what you build
Builders change their pricing and features often, and some products disappear. Export your code or connect the project to a code repository if the builder offers it, keep your spec and your list of features in a document you control, and know how you would move the app if you had to. The habit costs ten minutes and protects months of work.
Key takeaways
- Start with the smallest tool: a Claude artifact or a Gemini Opal mini-app before a full builder
- Use Lovable, Bolt, Replit, or Base44 when you need logins, a database, or a public address, and try two before committing
- Write a one-page spec, build one feature at a time, and roll back after two failed fixes
- Never skip the security review: test access as two users, lock down the database, keep secrets out of code, and use fake data until it passes
- Bring in a developer before payments or sensitive data, and keep your code and spec exportable
Next steps
Continue to: Hands-On AI Exercises
- Compare the developer-grade options when you outgrow no-code in AI Coding Tools Compared
- Turn a mini-app into something that runs on its own with Build Your First Agent