You Can Build It. Can You Run It?

Why this manual exists, who it is for, and the one thing it will not ask of you.

A few months ago someone sent me a message that I have thought about ever since. They had built a small product almost entirely by describing it to an AI, and they were close to launching it as their first real business. Then came the questions that the tools never answer: which hosting platform was actually doing what, whether a free tier was safe to launch on, where a cheap server comes from, and how to make the part that handles money secure. And underneath all of that, one line they nearly did not send: they were almost done, and they did not know why they had no confidence.

That message is this book. Every question in it is answered in these pages, and the last line is answered in the last chapter. If you recognised yourself in it, you are the reader I wrote toward.

What has changed

For most of my working life, the hard part of building software was writing it. That is no longer true. A machine will now write competent code from a plain description, faster than any team I have managed, and the code is getting better every month. Millions of people who could never have written that code are now producing it. You may be one of them.

What the machine does not do, and what nobody tells you when you start, is everything around the code. Where does it run? What is a server, and why does yours fall asleep? What is a database, and what happens to it if the server dies? What is a domain, and why did the site vanish on a Tuesday? Where do the passwords go? What does "secure" mean when money is involved? What do you do at two in the morning when it breaks?

Those are the questions that used to be answered by an engineer on the team. If you are building alone with an AI, there is no engineer. There is you, a chat window, and a growing feeling that you are one bad click away from disaster.

What this book will not ask of you

You will not learn to write code. Not PHP, not Python, not JavaScript. You will not memorise commands. You will not study frameworks. If at any point this book seems to be turning into a programming course, I have failed, and you should tell me.

What you will learn is a small number of concepts, each shown before it is named:

• Files and folders, and what "live" means
• What a server is, and what a database is
• What a domain is, and what a secret is
• What a job is that has to keep running

And a way of working: brief the AI, read what it proposes, let it do the typing, check the result, and never touch a live system without a backup you have actually tested.

Who this is for

• The page-builder designer who hits the wall every time a client site needs something past the dashboard.
• The freelancer looking after twenty sites who dreads the next hack.
• The founder who built a product by prompting and is afraid to launch.
• The owner who depends on a stranger for every change.

Four faces, one problem: you can make it, and you cannot yet run it.

It is not for people who want to become software engineers. There are better books for that. This one is about getting real things live, safe and running.

The road ahead

How to use it

Read Part I in order. After that, go where your problem is. Every chapter stands on its own and tells you what it assumes. The dark panels are instruments: things you can push, drag and break to see how an idea behaves. The exercises have hidden answers; try before you reveal. The checklists at the end of the job chapters are meant to be copied out and used. Your progress is saved in this browser.

About the author

A working architect, two decades of systems that had to hold up.

Konrad Voss is a systems architect who has spent the better part of two decades building software that has to stay up, under real traffic, real budgets, and real failure.

He has designed and scaled production systems from the first single-server prototype to platforms carrying millions of requests a day, and, just as often, been the one called in to rescue systems buckling under load they were never built for. Backend architecture, data pipelines, caching and storage layers, the migrations that have to happen with users still online: this is the terrain he works in, and has for a long time.

Everything in this manual was earned in production, not a lecture hall. The outages, the runaway bills, the security audits, the 3 a.m. pages, those were the curriculum, and the From the field notes throughout the book come straight from systems he built and, often enough, watched break. It is the book he wishes he had had at the start: the reasoning behind the decisions, not just the decisions.

His conviction is simple. Now that a machine can write the code, the scarce and valuable skill is understanding a system deeply enough to design it, direct the build, and judge what comes back. That is what this manual sets out to give you, not a set of answers to memorise, but the way of thinking that produces them.

He is also the author of System Design From Scratch, the companion field manual for readers who want to understand how systems hold up at scale. Both books share one shell and one way of teaching: a picture before every explanation, an instrument in every chapter, and exercises whose answers stay hidden until you have tried.

A Konrad Voss field manual

The Wall Is a Door

Everyone who builds with an AI hits the same wall. Here is what is on the other side of it.

Two people, one wall

The first is a designer. For years, her whole job fit inside a page builder. A client sends a logo, a paragraph about themselves, and a link to a competitor's site they like. She opens the builder, drags in a hero section, picks a font pairing, tweaks the spacing until it feels right, and sends a link. They say "can the button be bigger" and she makes the button bigger. She is good at it. Then a client's site starts throwing a 500 error at eleven at night, or Google flags it for harmful content, or a plugin update breaks the checkout page and the client is losing sales every hour. Every one of those problems lives on the other side of a wall. On her side is the WordPress dashboard. On the other side is the server: folders she has never opened, a database she is afraid to touch, a black terminal window she has seen developers use and has quietly decided is not for people like her. So she finds a developer on a freelance site, pays, waits two days, and hopes. Sometimes it works. Sometimes they fix one thing and break two. Sometimes they vanish with the login details. Either way she learns nothing, and next month she is back at the wall with her wallet open.

The second is a founder. He has built a small product by describing it to an AI, and he is going to launch it as his first real business. The code works on his laptop. He has pushed it to a free hosting tier because a video told him to. And now the questions have arrived that no video answered. What is the hosting platform actually doing? Where does a cheap server come from? Is free hosting still fine for a startup? How does he make the payments part secure? And underneath all of it, the thing he almost did not say: he is nearly done, and he does not know why he has no confidence.

I have spent twenty years on the far side of that wall, and I have watched a great many people stop at it. What I want you to see in this chapter is that the wall has changed shape. It used to be made of syntax. It is now made of understanding, and understanding is something you can be walked through.

What changed

For a long time, an AI chat could help you write a snippet. You pasted it in, tweaked it, pasted it back, and if it broke you were on your own. That is what most people still mean by vibe coding, and it has a ceiling. The ceiling is your own ability to move the code around, run it, read the error, and try again.

The newer tools are different in one way that matters: they have hands. They can open the folder on your computer, read the files, run a command, look at the result, and tell you in plain language what they found. Connected to a server, they can do the same there. The first time I watched someone with no technical background point one at a folder holding a client's site backup and say "tell me what is in here," it came back with: a WordPress install, a page-builder theme, about forty plugins, three of them not updated in two years, and one of them has a file that looks unusual, would you like me to take a closer look.

She sat there for a minute. Then she said yes. It was malware.

That is the moment this book is built around. Not because it found malware, but because the black window had stopped being a wall and become a door, and she had just found someone who would walk through it and describe what was on the other side.

What I do differently now

I still design and build systems. But the way work reaches me has changed, and the way I hand it to others has changed more.

When a client's site is hacked, I connect an AI to their hosting account over a secure connection and we clean it together. It reads the files; I make the decisions. A job that used to mean a two-day wait for a specialist now takes an afternoon, and the person paying for it can understand every step because the AI explains each one before it does it. Chapter 13 is that job, start to finish.

When a client has twenty sites on one hosting account and all of them need updating, nobody logs into twenty dashboards. The job is described once, the safety rules are set, and the AI works through the list, stopping when something looks wrong. Chapter 14.

When a client wants a members-only library on a site that earns its money from ads, and every off-the-shelf membership plugin would break the ads, the behaviour is described, the AI proposes a plan, the plan is corrected, and a small plugin is built that does exactly that and nothing else. Chapter 18.

None of that required anyone to learn PHP. All of it required someone to brief, to check, and to say "stop, show me first." Those are skills you already have from years of dealing with clients, colleagues and family. You only have to point them in the other direction.

Who this book is for

This book is for you if:

• You have built a site in a page builder and thought "I wish I could do the next bit myself."
• You have been vibe coding in a chat, pasting code into files and hoping, and you want the AI to have hands instead of only a mouth.
• You look after other people's sites and every hack or outage is a small crisis.
• You have built a product and you are afraid to launch it because you do not know where it should live or whether it is safe. Parts III and V were written with your questions open on the desk.

If you want to become a software engineer, this is not that book. There are better ones. This one is about getting real work done on real systems, safely, by directing a machine that knows more than you do and does what you tell it.

Three rules

Everything else in this book sits on three rules. I will repeat them until you are tired of them, because the difference between someone who works on a live client system and gets away with it, and someone who does not, is almost always one of these.

1. Never work on a live system without a backup you have actually tested. Not one you think exists. One you have restored somewhere and seen working.
2. Read what the AI says it is about to do before it does it. It will tell you. Your job is to read it, and to stop it if anything looks off.
3. If you do not understand the explanation, ask again. It will not get bored, it will not judge you, and the second explanation is usually better than the first.

What Vibe Coding Actually Is

Chat-and-paste versus an agent with hands, what you still need to understand, and what you can safely skip.

Here is a contradiction to start with. The people who build the most with AI are often the people who understand the least about what they built. That is not an insult. It is the natural result of a tool that produces working code from a sentence. The code arrives; the understanding does not. This chapter is about closing that gap only as far as it needs closing, and no further.

Two things called by one name

The first kind of vibe coding is the chat. You describe what you want, the model writes code, you copy it into a file, you run it, it breaks, you paste the error back, it apologises and writes more. Everyone starts here, and for small things it is fine. But notice who is doing the moving. You are the one opening files, saving them in the right place, running the command, reading the error, deciding what to paste. The model can only see what you show it. It cannot check whether the file you pasted into is the file it meant. It cannot run the thing. It cannot look at the server. Every gap between what it wrote and what actually happened is filled by you, and you did not sign up to be the gap.

The second kind is an agent. The same model, but connected to a tool that lets it open the folder, read every file in it, run a command and read the output, and, once you have done Chapter 5, do all of that on a server as well. Now when it says "I will change the config file", it can find the config file, read it, change it, run the site, read the error if there is one, and come back with "done, and here is what I saw." The gap is gone. You are no longer the hands. You are the person the hands report to.

Step the same task through both. The task is one that every reader has faced: a site is showing a blank white page.

Instrument 2.1. Same problem, same model. The difference is who fetches the evidence.

What you do need to understand

Six ideas. Each will get its own proper treatment later; here they are introduced by what they feel like, so that when the name arrives you already know the thing.

• Files and folders. Your thing is a set of files in a folder. The AI reads and changes those files. When something is "in the code" it means in one of those files. When you back something up you are copying the folder and the database. You already understand this from your own computer. Nothing changes on a server except that you cannot see the folder without asking.
• A database. The place where the changing facts live: users, orders, posts, settings. It is separate from the files. This matters constantly. Reinstall every file on a WordPress site and the posts are still there, because they live in the database. Delete the database and a perfect set of files shows you an empty site. Chapter 13 is built on that distinction.
• Live. The copy real people are using right now. There is usually also a copy on your laptop, and often a staging copy on the host. Everything risky happens on the copies. The live one only ever receives changes that worked somewhere else first.
• A server. A computer that stays on and runs your thing. Chapter 8. You do not need to know how to operate one. You need to know which kind yours is and what it can and cannot do.
• A secret. A password, an API key, a database credential. Anything that, if a stranger had it, would let them be you. Secrets have a place to live, and it is never inside the code and never inside a chat window. Chapter 11.
• A job that keeps running. Some things your product does happen when nobody is visiting. Reminders, backups, crawlers. They need a server that is awake. Chapter 9.

What you do not need

Syntax. You will never need to know where the semicolon goes. Frameworks: you do not need to know what React or Laravel are, only that the AI will pick one and that you should ask why. Commands: you will recognise a few (Appendix A) the way you recognise road signs, without being able to draw them. Memorising anything at all: the AI remembers; you decide.

And one more thing you do not need, which people carry around like a stone: the feeling that you are cheating. You are not. Every senior engineer I know now works this way. The skill that remains scarce is the one this book is about.

Instrument 2.2. Sort each thing into where it lives. The rule you discover is why a clean reinstall of the files fixes a hack without losing a single post.

You Are the Client Now

You already know how to brief someone and check their work. The three rules, and the briefing that makes an agent safe.

A scene. Late afternoon, a client's hacked site, the agent connected over SSH. It has found a hidden plugin that deletes every administrator account except the attacker's on every page load. It writes: "If I run any WordPress command before removing this file, it will fire again and delete your admin. I would like to delete the file directly first, then proceed. OK?" And it waits.

That pause is the whole chapter. The agent could have done the right thing without asking. It asked because it had been told to, and the telling is a skill you already have.

The skill that transfers

You have briefed people. A designer, a freelancer, a builder, a colleague. You said what you wanted, you said what mattered most, you said what they must not touch, and you looked at the result before you paid. When it went wrong it was usually because one of those four was missing: the goal was vague, the priority was unspoken, the boundary was assumed, or nobody checked.

An agent is briefed exactly the same way, and it fails in exactly the same ways. The difference is speed. A freelancer who misunderstands you wastes two days. An agent that misunderstands you can wipe a folder in two seconds. So the briefing has to be tighter, and the checking has to happen before the work, not after.

The three rules, and where they came from

Rule one. Never work on a live system without a backup you have actually tested.

The story: an attacker who, before doing anything else, deleted the site's backup folder. The client "had backups". They were on the same server, in a folder the attacker could see. A backup you have not restored somewhere and watched come up is a hope, not a backup. Before the first risky change on any live system, the brief includes: take a backup, put it somewhere else, and prove it restores. Chapter 21 covers where "somewhere else" is.

Rule two. Read what the AI says it is about to do before it does it.

The story is the scene above. The agent proposed an order of operations that mattered, and because it had been asked to say its plan first, the human got to agree. Every serious tool will tell you what it is about to do if you ask. The sentence that asks is "tell me the plan first, and do not change anything until I say go." Say it every time until it is a habit; then say it anyway.

Rule three. If you do not understand the explanation, ask again.

The story: a theme's main file had grown by 300 kilobytes. "What does this do, in plain words" produced an explanation a client could act on: it served a different site to search engines than to humans. The first explanation is sometimes too technical. The second, asked for in your own words, is almost always clearer. The agent does not get bored and does not think less of you. The person who asks twice understands; the person who nods and moves on is the one who gets hurt.

The shape of a brief

Every good brief to an agent has four parts. Chapter 7 turns this into a builder; here is the shape.

1. The goal. What done looks like, in one sentence. "The site loads in under two seconds on a phone."
2. The constraint. The one thing that must not break. "Ad delivery must never break, even briefly." "The shop platform stays the single source of truth for orders and stock." "Change nothing until we have the full picture."
3. The boundary. What it must not touch. "Do not edit anything in the uploads folder." "Do not install new plugins without asking."
4. Plan first. "Tell me the plan, then wait."

When to say stop

You will not always know whether a plan is right. You will often know when it feels wrong. Trust that. The signs:

• The plan touches something you did not mention
• It wants to install something
• It wants to delete rather than move
• It is about to change the live copy
• It is about to do something you cannot explain back

Any of those, say "stop, show me first," and ask rule three's question until you can explain it.

Saying stop costs a minute. Not saying it, on a live system, has cost people their weekend and occasionally their client.

This chapter is written and in editorial review. It will appear in your copy when it is released; the file you have will be updated, not replaced.