Build a Real App Without Coding — On One Condition

Yes, you can build a real app without knowing how to code. Platforms like Lovable, Bolt.new and Google AI Studio do exactly that: you describe your idea, show a mockup if you have one, and you get a working, hosted app with a URL you can share. For a first product, an internal tool or an MVP, it's genuinely spectacular — and genuinely democratizing, because many of the people vibe-coding today aren't professional developers.

The one condition for this to stay a good idea long-term fits in a sentence: keep an exit door. Concretely, three things need to stay true: your code can be exported to a Git repo, your database is a standard format (Postgres, SQLite), and your domain name belongs to you. If they are, the platform is a springboard. If none of them are, your project effectively belongs to the platform: it sets the prices, decides which features exist, and picks the shutdown date.

Let's look at what's true in the promise, what lock-in actually means, and the checklist to run before you pick a tool.

What these platforms genuinely get right

The whole point of "zero friction" platforms is removing everything that used to block non-developers: no installs, no terminal, no configuration. You type "I want an app to manage bookings for my guesthouse," you iterate through conversation, and the app exists. UI, database, hosting — all handled for you.

And let's be honest: it works. For validating an idea in a weekend, for building the internal tool nobody was ever going to build for you, for showing real users a real prototype instead of a slide deck, these tools are hard to beat.

It's also good news collectively. Thousands of problems too small or too niche for any software company to care about are finally getting solved — by the person who actually lives with the problem.

Lock-in, explained without the drama

Lock-in is when your project can't live anywhere except the platform it was born on. You don't need a doomsday scenario to see why it matters. Three perfectly ordinary situations are enough:

The price goes up. Your app takes off, you upgrade to the next plan, then the next one. If you can't leave, you pay whatever is asked.
A feature is missing. You need PDF export, a specific payment flow, one particular integration. If the platform doesn't offer it, you wait. Possibly for a long time.
The service pivots or shuts down. Startups change direction, get acquired, refocus. Nobody's fault — but your app lives at their place.

None of this is a reason to avoid these platforms. It's a reason to check, before you move in, that you can move out. It's the difference between renting an apartment and renting an apartment with no door.

The 5 questions to ask before you choose

Ask them before you sign up — or today, if your app already exists. Five minutes in the platform's docs usually gets you the answers.

Can you export the code? Best case: one-click GitHub sync. Failing that, a full ZIP export. If the answer is "no," you now know the platform's real price.
Is the database a standard? Postgres or SQLite means your data is readable by any tool, anywhere. A proprietary format means only the platform can read your data.
Do you own the domain? myapp.theplatform.com is their address. yourdomain.com, bought from an independent registrar, is yours — and it follows you everywhere.
What does scaling cost? Look at the pricing tier two levels above your current plan. That's what you'll pay if the app succeeds.
Can the app run somewhere else? The ultimate test. If the exported code can start on another host, you're free. The answer usually lives in the docs under "export" or "self-hosting."

No platform necessarily ticks all five boxes. But you should know which ones are missing before you build, not after.

The standard exit path

Good news: an exit door is something you prepare in advance, without breaking anything. The path is always the same, in three steps.

Step 1: export the code. Do it now, even if everything's fine. An export that works today is insurance for tomorrow.

Step 2: put the code on Git. Git is your project's history, stored on your own (free) GitHub account. Even if you don't understand a single file in there, five commands are enough:

git init
git add .
git commit -m "Backup outside the platform"
git remote add origin https://github.com/you/my-app.git
git push -u origin main

From that moment on, your code exists outside the platform. That's the turning point.

Step 3: host it elsewhere when the project gets serious. You don't have to do this on day one. But once your app has real users, running it on a standard host gives you back control over pricing and features. Standard hosts are interchangeable in a way platforms aren't — that's the whole point.

Where to start today

You don't need to do everything at once. Here's the actionable version, in order:

[ ] Haven't picked a platform yet? Run the 5 questions above on your two or three candidates. Pick the one that ticks the most boxes.
[ ] App already exists? Test the code export today. Not next week — today. It's the only item on this list that can't wait.
[ ] Create a GitHub account (free) and push your first export to it, even a messy one.
[ ] Buy your domain name from a registrar independent of your platform, and point it at your app.
[ ] Write down your price ceiling. The monthly amount above which you'd rather move out. Deciding it calmly, in advance, makes it much easier.
[ ] Repeat the export once a month. Exit doors need maintenance.

Building without coding is real freedom. Keeping the door open is what keeps it that way.