Build an App With No Code for Free: What Is Actually Free
Build an App With No Code for Free: What Is Actually Free
You can build a working app for free, describe it in plain words, and open it on a real URL the same day. What free tiers rarely cover is the boring half: a custom domain, generous usage, and getting the code out. Judge a free tier by whether you can ship and keep what you built, not by whether the first build costs nothing.
What does "no code" actually mean here?
The phrase covers two very different products, and picking the wrong one costs weeks.
The older meaning is a visual editor. You drag blocks onto a canvas, connect them with rules, and the tool writes nothing you can read. It works, and for some jobs it works well, but every question you later ask ends the same way: does this specific tool support that specific thing. If it does not, you stop.
The newer meaning is a builder that writes real code from a description. You type what you want, actual source files get generated, and the result runs like any other app. You still write no code, but code exists, which changes what happens when you outgrow the tool.
That difference matters most on the day something unusual is needed. In the first case you file a feature request. In the second you hand the project to a developer, or open the file yourself and change one line.
What is genuinely free, and where does free stop?
Free tiers differ in one important way: whether they let you finish and keep something, or only let you look at it.
| What you need | Usually free | Usually not free |
|---|---|---|
| Building and previewing | yes, this is the demo everyone gives | rarely limited |
| A live URL people can open | yes, on a subdomain | a custom domain of your own |
| Usage beyond the first few builds | a starting allowance | steady daily work |
| Getting the source code out | varies widely, ask first | often locked to paid tiers |
| Private projects | varies | sometimes paid only |
| Removing builder branding | sometimes | often paid |
The row worth reading twice is the fourth. A free tier that builds beautifully and will not let you take the result anywhere is a rental, not a free tool, and the bill arrives later at a moment you did not choose.
Here specifically: building, previewing and publishing to a subdomain are covered by the starting allowance, and no card is required. A custom domain is a paid feature. The full breakdown of what AI builders charge for, and why the numbers are hard to compare, is in AI app builder pricing.
How do you build the app, step by step?
The whole process runs in a browser, so a laptop and a phone follow the same path. If you are working from a phone screen, the specific quirks of that are covered in how to build a website from your phone.
- Open zugo.dev and sign in with Google or GitHub. The starting credits appear right away and no card is asked for.
- Describe the app in ordinary language. Not a specification, but the way you would explain it to a colleague: who uses it, what they see first, what has to be remembered between visits.
- Wait for the build. It gets verified by actually running in a sandbox, not just by looking finished.
- Open the preview and use it like a real user would. Fill the form, press the wrong button, reload the page, and check your data survived.
- Fix things by writing the next message. "Add a search box above the list", "make delete ask for confirmation", "default the date to today".
- Publish. The app gets a URL that opens on any device.
Step four is the one people skip, and skipping it is why some projects feel unfinished for hours. A build that looks right and loses your data on reload is a specific, fixable problem, but only if you notice it in the first five minutes instead of the fifth hour.
How do you write the first prompt so the build lands closer?
Most of the distance between "right the first time" and "still fixing it" sits in the opening message. Three things carry it.
Say who the user is and what happens on the first screen. "An expense tracker" is a topic. "I open it, see an amount field and a category list, type an amount, pick a category, and the entry shows up in today's list" is an instruction, and instructions get built.
Say what has to persist. This is the single most expensive thing to change later. If entries must survive closing the tab, and each person needs their own, say so in the first message: that app is built on a different foundation than a calculator with no memory. What that foundation looks like is covered in can AI build an app with a database.
Say what should not exist. Constraints save more time than requirements. "No sign up, access by link" or "one page, no navigation" cut off whole branches of decisions that would otherwise need undoing.
What does not help is a page-long specification. Twenty requirements in one message produce a build where half of them are approximately implemented, and untangling that takes longer than adding the same twenty things one at a time.
Which apps come out well, and which do not?
Well: anything that is essentially forms, lists, and rules connecting them. Expense trackers, client lists, booking pages, shift checklists, internal calculators, lead capture, filtered catalogues, simple CRMs, small tools nobody sells but everybody needs.
Moderately: apps with several user roles and different permissions, approval flows, reporting across slices. These get built, but the first result is a foundation rather than a finished product, and the refinement takes longer than the build.
Poorly: anything that leans on device hardware. Full offline operation, background sync, on device video processing, heavy three dimensional graphics, or system integrations deeper than a browser is allowed to go.
Can you put it in the App Store or Google Play?
Yes, and it is a separate project worth naming honestly before you start.
A web app can be wrapped and submitted like any other app. That needs a developer account with a fee and identity verification, and for new accounts Google adds a closed testing requirement: a number of testers have to use the app for several consecutive days before it can go public. Then there is the store listing, icons, screenshots, and a privacy policy.
None of that is building. It is distribution and paperwork, and it takes at least a week. The sensible order is to ship the link first, confirm that people actually use the thing, and only then decide whether a store listing earns its week.
Who owns the code?
Ask this before you build, not after. It decides whether the evening you spend is an investment or a rental payment.
Here the source can be pushed to your own GitHub repository, which means you can read it, edit it by hand, hand it to a developer, or host it somewhere else entirely. The mechanics are in can I export the code from an AI builder.
The practical value is not ideological. It is that an app built in one evening stops being a dead end: when something the builder cannot do finally comes up, you hand over a working project instead of starting again.
In short
Free is real, and it is enough to get a working app on a live URL the same day. The parts that are usually not free are the ones you need later: your own domain, steady daily usage, and taking the code with you. Check the last one before you invest an evening. Build small, test by using it rather than looking at it, fix by describing the change, and leave the app store question until people are already using the link.