The cliff: why so many AI prototypes never go live

What exactly is the cliff?

The cliff is the place where the guidance of your build tool stops and nothing takes its place. Up to that point everything went up: you described what you wanted, something working came back, you clicked through it and it worked. Then you want to give it to someone who is not sitting next to you, and there turns out to be a list nobody showed you.

That list is short and it is always the same. An address that is yours and not the tool’s. A place where the project runs when your laptop is closed. A database that keeps your data when the environment restarts. Keys and passwords that are not in your code. And as soon as you store a visitor’s email address or ask for money, a few legal minimums. None of those five is in the build tool, because they do not belong to building. They belong to having.

It is also called the technical cliff. We say the cliff, because the word says what it is: an edge you do not see until you are standing on it.

• Above the cliff: everything the tool arranged for you, and that is a lot.
• The cliff itself: the moment you want to give the project to a stranger.
• On the other side: the same project, at an address and a place that are yours.

Why do you only feel it once the prototype is done?

Because the build tool does its job well. Everything you needed to build came with it: an address to look at, a database to try things, a button to share. That is exactly enough to build and exactly too little to have, and you only notice the difference when you try the second.

There is another reason. Building with an AI feels like progress per sentence: you type, something changes, it works. The steps after the cliff do not give that feeling. Connecting a domain does not produce a new screen. Restoring a backup changes nothing in your app. Writing a privacy statement produces a text nobody reads until it matters. They are steps without a reward, and that is why you put them off until you can no longer put them off.

That moment usually comes with a question from outside: someone wants the link, someone wants to pay, or the tool says your free trial is over. Then the whole list is suddenly there at once, and then it looks bigger than it is.

• The tool gives you enough to build, not enough to have.
• The steps after the cliff give no visible result, so you put them off.
• They come back as a question from outside, all at once.

In which five places do makers get stuck?

In the same five, in varying order. The first is ownership of the code: the project exists only in the tool, and if the tool stops or your subscription stops, there is nothing. The second is the address: the project sits on a subdomain of the tool, and that address is theirs. The third is the data: the database from the build environment was made for trying things, not for keeping them, and the first time you lose it you learn that the hard way.

The fourth is the keys. An AI that wants to build fast sometimes puts a password or a key in the code itself, because that works. It works until someone else sees your code. The fifth is the obligations: as soon as you store an email address you need a privacy statement, as soon as you sell something there are rules for consumers, and as soon as you earn money you need bookkeeping. None of that is heavy. All of it is new.

The good news is that the list does not grow. Whoever has done these five once recognises them in an afternoon on the next project.

• Ownership: the code exists only in the tool.
• Address: the domain belongs to the tool, not to you.
• Data: a trial database without a backup you have restored.
• Keys: passwords and keys in the code instead of outside it.
• Obligations: privacy, consumer rules and bookkeeping as soon as it becomes real.

What is the first step across?

Ownership of your code. Before you arrange anything else, you make sure the project is in a place that is yours and that you can open without the tool. In practice that is your own repository at a version control service, with you as the owner. Every serious build tool has a connection for that; search the documentation of your tool for version control or export.

This is the first step because all the others lean on it. A host needs your code in a form it can read. You immediately have a backup of your code as well. And for the first time you can see exactly what the AI changed between two versions, instead of only that it works differently. If you are not a developer, five concepts are enough; they are in the article on Git and GitHub.

After connecting, fetch the code to your own computer once and check whether it is complete. Add a short file with how you start the project and which values it needs. That file is for you, three months from now.

• Your own account at a version control service, an empty repository, you as the owner.
• The connection from your tool; the documentation of the tool takes precedence over any explanation.
• Fetch and check once, and add five lines on how it starts.

In what order do you arrange the rest?

After ownership comes the address, then the data, then the keys, then the obligations. That order is not sacred, but it prevents double work. You buy a domain in your own name at a registrar and connect it to a host that treats your code as ordinary code, so you can leave later without rebuilding everything. Once the address works, you know where the data has to go.

The data is the step that is skipped most often and turns out most expensive. Choose a database that is yours, make a backup, and restore that backup once onto an empty system. Not because it goes wrong, but because then you know it can be done. Then the keys: everything secret goes out of the code and into the settings of your host, and you search your repository once for what does not belong in it.

The obligations come last, but not after the first visitor. A privacy statement should be in place before you store the first email address. What else you need depends on what you do, and the main guide walks through it step by step.

• Address: your own domain at a registrar, a host you can leave.
• Data: your own database, backup made and restored once.
• Keys: out of the code, into the settings of the host.
• Obligations: a privacy statement before the first visitor, the rest as soon as it applies.

What do you not have to do?

You do not have to become a developer. The five steps ask for understanding, not skill: you need to know what a record is, not how DNS works. You also do not have to do everything perfectly. For each step there is a smallest version that is good enough, and it is almost always the version your host or your registrar prescribes in its own documentation.

You do not have to choose the most expensive or the best-known host. You do not have to manage your own server. You do not have to wait until the project is finished; the cliff is there for half a project too, and getting across with something small is easier than with something big. And you do not have to let go of the tool. Most makers keep building in the same tool and only put the result in a place of their own.

What you do have to do is finish the whole list once. Stopping halfway gives you the worst of both sides: a project that is yours but runs nowhere, or one that runs but is not yours.

• No becoming a developer, no server of your own, no perfect choice.
• Do: follow the documentation of your host or registrar, because that is the smallest good version.
• Do: finish the list completely, once.

What changes once you are on the other side?

The project is yours. That sounds small and it changes everything: you can switch tools without starting over, you can give someone access without sharing your account, and you can sleep when the tool has an outage. What also changes is the nature of the work. Building stays building, but a second job is added that nobody offered you: maintenance, users, and as soon as money comes in, bookkeeping.

That second job is what basestep is built for: it guides the steps after the cliff and puts the bookkeeping of a sole proprietorship (eenmanszaak) next to them, with every line explained down to the source. You do not need it to get across the cliff. The guides are free, need no account, and this article is one of them.

Whoever has done the five steps has something many makers with a nicer prototype do not have: a project that really exists.

• Switch tools without starting over.
• Give access without sharing your account.
• A second job: maintenance, users and the bookkeeping as soon as money comes in.

Sources

Checked on 5 September 2026. The steps themselves come from the five guides on this site; the sources below are about the concepts the article uses.

• Wikipedia, Vibe coding (the term coined by Karpathy and the criticism)
• GitHub Docs, Hello World (repository, branch, commit)

Further reading

Three places that connect to this.