From prototype to live

What is the cliff?

The cliff, or technical cliff, is the gap between a prototype that works and a project that lives. Your AI tool took you further in an afternoon than you used to get in a month, and that is exactly where the guidance stops. What is missing then is not functionality but a list: nobody tells you which ten things to sort out before you dare show something to a stranger.

It is a knowledge problem, not a skills problem. In the words that describe most sharply what happens: not I am missing a feature, but I do not know what I do not know. That is why the cliff feels so personal. You cannot search for something whose name you do not know.

The way out is mundane: write the list down and work through it. That is what the eight sections after this one do. They are in the order in which you run into them, and each section ends at the smallest version that is good enough to go live. Perfection is the real risk here: a project that is almost ready for months is worth less than a project that runs today and gets better next week.

• The cliff is an information problem: you are missing a list, not talent.
• Work in the order in which you run into the problems, not in order of difficulty.
• For each step, choose the smallest version that is good enough, and go live.

Which hosting do you choose for an AI-built project?

Hosting is the place where your project runs once your laptop is closed. For an AI-built project, one question decides almost everything: is it a site that can be delivered as files, or does a server need to think along? A static site (only pages, no login, no database) can go almost anywhere, almost for free. As soon as accounts, storage or payments come in, you need an environment that runs code.

The three forms you run into in practice: a static host that serves your files, a platform-as-a-service that runs your code for you and redeploys it on every change, and your own server where you set everything up yourself. For a first live project, the second form is almost always the right one: you keep control over your code without having to manage an operating system.

When you choose, look at four things, in this order: can you connect your own domain, do you get HTTPS automatically, can you set environment variables without putting them in your code, and can you leave without rebuilding everything. That last one is the most important and the one most often forgotten. A host that treats your code as ordinary code is one you can leave. A host that locks you into its own format is not.

• Static site without login: a static host is enough.
• Accounts, storage or payments: choose an environment that runs your code.
• Four requirements: your own domain, automatic HTTPS, environment variables, and a way out.
• Count on monthly costs, not one-off costs, and check what happens when your free tier fills up.

How do you connect a domain, in plain language?

A domain is a name that points to an address. You buy the name from a registrar and then tell the internet where the matching server is. That telling happens with DNS records, and in practice you need two kinds: a record that ties your name to an address, and records for email if you want to send mail from your own domain.

For the site itself you need two records. An A record, or AAAA for the newer IPv6, that ties your bare domain name to an address. And a CNAME that makes a subdomain such as www point to another name. Many hosts tell you exactly what to fill in; that instruction takes precedence over any general explanation, including this one.

Three things that surprise almost everyone the first time. First: a change is not visible everywhere right away, because DNS is cached, and the waiting time is in the TTL field. Count on minutes to hours, not seconds. Second: choose one canonical form, with or without www, and redirect the other one to it; two forms that both work cost you findability and confuse your visitors. Third: set up HTTPS before you share the link, because a browser warning that your site is unsafe costs more trust than a day's delay.

• A record for the bare name, CNAME for subdomains such as www.
• Follow the instruction from your host over any general explanation.
• Choose one canonical form and redirect the other in one step.
• Wait for the TTL before you conclude that it does not work.

What do you do with your database?

A prototype often stores data in a place that disappears: in memory, in a file next to the code, or in the browser of whoever is looking at it. That works exactly as long as nobody uses it seriously. The first time your host restarts your project and the data is gone, the lesson is learned. A real database is therefore not a luxury but the line between demo and product.

For a first live project you rarely need anything exotic. A managed relational database is the safe default: it is provided for you, a backup comes with it, and you can leave because the format does not belong to one provider. Managed here means that someone else does the updates and the backups; that is worth it, because maintaining a database yourself is work that never stops.

Three things to get right straight away, because they become expensive later. Turn on a backup and actually restore from it once, because a backup you have never restored is an assumption. Keep your schema in code through migrations, so you can see what changed when. And do not store data you do not need: a field you do not store cannot leak and does not need cleaning up.

• Keep nothing permanent in memory or in a file next to the code.
• Choose managed, in a format you can take with you.
• Backup on, and one real restore test.
• Schema in migrations, and store only what you actually use.

Where do you keep environment variables and secrets?

A secret is any value that lets someone else pose as you: an API key, a database password, a token key. AI tools often put those values in the code for convenience, and as long as only you are looking, nobody notices. As soon as your code is in a repository or your project is public, every secret in the code is a secret that is gone.

The method is simple and the same everywhere. Secrets belong in environment variables that you set at your host, not in files you ship. Locally you use a .env file that you exclude from version control, with a .env.example next to it that holds only the names, so someone else knows which values are needed. And you separate keys that may be in the browser from keys that may only exist on the server; a key that ends up in the browser is public, whatever it is called.

Two things you can do today. Search your project for anything that looks like a key, old commits included, because version control forgets nothing. And if a key has ever leaked, rotate it: removing it from the code is not enough, because the old value stays valid until you revoke it.

• Secrets in environment variables at the host, never in the code.
• .env out of version control, .env.example with only the names in it.
• What reaches the browser is public; separate client and server keys.
• A leaked key is rotated, not just removed.

Which security checks do you do before going live?

Security sounds like a specialism, and at large scale it is one. For a first live project it comes down to a short list of basics that prevent most of the trouble. The rule of thumb: everything that comes in from outside is suspect until you have checked it, and everything that goes out should reveal no more than necessary.

The checks that matter most, in order of payoff. Turn HTTPS on and enforce it, so nobody comes in through the unsecured variant any more. Check that your input fields validate their content on the server and not only in the browser, because the browser check is a convenience and not a lock. Make sure error messages to visitors reveal nothing technical: a stack trace on a public page is a road map. Put rate limiting on forms and login attempts. And check that one user's data can never end up with another by changing an id in the URL; that is the mistake that happens most often and costs the most.

basestep includes a health check of eighteen points in five areas for this, which you go through and tick off yourself. The platform does not check your site automatically and does not put anything live for you: it gives you the list and the explanation, you take the action.

• HTTPS on and enforced, no unsecured way in.
• Validation on the server, not only in the browser.
• Clean error pages without technical details.
• Rate limiting on forms and login attempts.
• Check that an id in the URL does not open someone else's data.

The eighteen points are in the health check, with what to do and why for each point.

What is the minimum for accessibility and findability?

Accessibility and findability look like two subjects and in practice are the same work. A page that a screen reader can follow, a search engine can follow too. Both read your page as structure, not as a picture, and both trip over the same things.

The minimum that pays off most. Give every page one h1 and use the heading levels in order, without skipping one. Give every image an alt text that says what is shown, or an empty alt if the image is purely decorative. Make sure your whole site can be used with the keyboard and that you can see where the focus is. Check the contrast between text and background. And give every page its own title and its own description that matches what is on it. What basestep.io itself has checked on these points is in the accessibility statement.

For findability, add three technical things that you do once. A sitemap.xml so a search engine can find your pages. A robots.txt that does not accidentally block your whole site. And one canonical URL per page, so the same content is not at two addresses. That last one is the same choice as with your domain in step 3, and it is the same mistake if you left it there.

• One h1 per page, heading levels in order.
• Alt texts that say something, an empty alt for decoration.
• Usable with the keyboard, with visible focus.
• Contrast checked, its own title and description per page.
• Sitemap, robots.txt and one canonical URL per page.

Which legal minimums apply?

As soon as your project is public, information obligations apply, and as soon as you process personal data, more apply. This is not legal advice and not a complete list; it is the short version of what you will run into in the Netherlands in any case, so you know what to ask about.

Three things that almost always apply. First: who you are must be findable. For an information society service, Article 3:15d of the Dutch Civil Code (Burgerlijk Wetboek) requires your identity, address, contact details and KVK number (from the Dutch Chamber of Commerce) to be easily and permanently accessible. Second: if you collect personal data, even just an email address for a waiting list, you need a privacy statement. It says what you keep, why, for how long, and who you share it with. The information obligation of Article 13 of the GDPR (AVG) applies from the first sign-up. Third: if you place something in your visitor's browser that is not strictly necessary for the service, such as analytics, you need consent for it (Article 11.7a of the Dutch Telecommunications Act, Telecommunicatiewet). If you measure nothing, you do not need a banner either, and that is the simplest route.

If you are going to sell, more comes in: general terms and conditions that you make available to your customer in a way that lets them store them, and for consumers a right of withdrawal. Have those texts reviewed by a lawyer before you receive the first euro. They cost less than the dispute in which you lack them.

• Your identity and KVK number permanently findable on the site.
• A privacy statement as soon as you collect a single email address.
• No non-essential storage in the browser without consent; measuring nothing is the simplest way.
• If you are going to sell: terms and a right of withdrawal, reviewed before you sell.

This is general explanation, not legal advice. For your situation, consult a lawyer.

What comes after going live?

Going live is half of it. A project that runs quietly decays if nobody looks at it: certificates expire, dependencies age, forms stop working without anyone noticing. The second half is a small rhythm instead of a big plan.

The minimal rhythm that works. Check monthly whether your site still runs, whether your forms still arrive and whether your backups are still being made; that last one by opening one. Update your dependencies at a fixed moment, because half a year of doing nothing turns every update into a renovation. Measure one thing you actually use instead of a dashboard full of numbers you do nothing with. And write down what you changed, even if it is three lines a week: it is the only way to know in half a year why something is the way it is.

And then the step that catches most people off guard: the moment your project starts earning money. Then bookkeeping comes in, with VAT (btw), invoices that must meet requirements, and a retention obligation. That is exactly why basestep exists: the path runs from first prompt to your first tax return, with a tax engine that explains every box down to the legal reference. You file yourself and understand exactly what you are doing.

• Monthly: does it run, do forms arrive, does the backup work.
• Update dependencies at a fixed moment.
• Measure one thing you use.
• Keep track of what you changed.
• If you earn money: set up your bookkeeping before the quarter is over.

This is general information, not tax or legal advice. basestep calculates and explains; you file yourself. If you are unsure about your situation, consult an adviser.