🌐 What publishing means
You've built the solution, and it runs beautifully on your computer—and yet it doesn't solve anyone's problem. Why? Because it's locked on your machine. Publishing means putting the solution out in the world: keeping it somewhere that stays online, with an address, so people and other systems can actually use it. It’s the difference between a model on your desk and a store open on the street.
🚪 "Live" means three things
A solution is “live” when: (1) it’s in a place that stays connected on its own, without your computer turned on; (2) has a address that other people can access; and (3) is connected to the channels where the customer talks to her. Everything in this module revolves around these three points.
✓ Published (live)
- ✓Runs even when your computer is off
- ✓Has an address anyone can access
- ✓The client uses it whenever they want, on their own
- ✓Solves the real problem
✗ Local only (locked in)
- ✗Only works while your computer is on
- ✗No one outside can access it
- ✗You become the project's "human server"
- ✗Stays a perpetual prototype, never a solution
🖥️ Website Hosting
The simplest way to publish is host. Hosting means renting a small piece of a computer that stays connected to the internet (a “locker” in a building that never turns out the lights) and putting your page or website there. For many prototypes, that’s enough: ready-made services put a website online in minutes, for free or almost free. It’s your first possible “live” version—fast, cheap, and enough to validate the idea.
💡 Practical tip
Don’t start by buying an expensive server. For a page, a folder, or a demo, use free static site hosting. It works, costs nothing, and gives you a link to send to the client. Add complexity later—only when the solution calls for it.
🧱 Static × dynamic website (the difference in one sentence)
- Static: ready-made pages, identical for everyone (one folder, one catalog). Cheap and easy to host.
- Dynamic: the content changes depending on who accesses it and what they do (a dashboard, a chat with memory). It needs a server that "thinks" — the next topic.
☁️ VPS and server
When the solution grows beyond one page—when it needs to keep thinking, remembering, and responding all the time, like a Jarvis — you need an server. A server is just a computer that stays on to serve others. A VPS (virtual private server) is the most common way to get one: you rent a computer in the cloud, dedicated to you, running 24 hours a day, and run your system's services on it.
💡 Practical tip
You don't need to "work in IT" to have a VPS. Today, you can rent a small server for just a few dollars a month, in minutes, with a visual dashboard. The important thing is to understand the concept: there's a computer in the cloud, running for you, where Jarvis lives.
🔗 Domain
Your server has a number—a long, hard-to-remember sequence that nobody is going to type. The domain is the fancy name for this number: inema.club instead of a string of digits. It’s the solution’s public and professional identity — the name it’s found and remembered by. Behind it is a system called DNS works like the internet’s contact list: you type the name, and it finds the number.
The translation DNS performs (illustrative)
Fictional number—just to show the concept: name → DNS → real address.
💡 Practical tip
A domain is inexpensive and worth getting early: it looks professional and it's yours. You can switch servers later and keep the same domain—just point it to the new server. The name belongs to the brand; the server is just where it lives today.
🗄️ Database, API, and Webhook
A published solution rarely stands alone — it connects with other systems. Three integrations come up all the time, and you only need to understand the concept from each person to design the flow: the database stores the information (the organized memory), the API is the standard way for two systems to communicate (a program’s “service desk”), and the webhook is an automatic notification that fires when something happens (“let me know when the payment comes through”).
Database
Where information is stored and organized—customers, orders, history. The system’s memory.
API
The counter where other systems request and deliver things to yours—in a standardized way.
Webhook
The automatic alert: "X happened, and I notified you right away." It runs on its own, without anyone asking.
🔄 API × webhook (the difference that confuses everyone)
API is you asking: "hey, any updates?" — you pull the information when you want it. Webhook is the system notifying: "look, it just happened" — the information arrives on its own. One you pull; the other pushes it to you. It’s the difference between calling to ask and getting a notification.
🚀 Deploy: from code to live
You made a change to the solution. How does it get to the server where the customer uses it? That act—taking the current version to the place where it actually runs—is called deploy. It’s the step that connects “it’s ready on my computer” with “it’s working for the customer.” In the architect’s workflow, deploy is the bridge from version control (which you saw in the previous module) to the live system.
🛤️ The deploy pipeline
1. Commit
You save the change in version control—a snapshot of "now it's the way I want it."
2. Send (push)
The change moves to the central repository, where the server can access it.
3. Deploy
The server gets the new version and puts it into operation—automatically or with one click.
4. Live (production)
The change is live for the customer. What was code has become a solution in use.
💡 Practical tip
The best deploy is one you don’t even notice: many services deploy automatically with every push. You save and push; the system goes live on its own. The less manual the deploy, the fewer human errors—and the more freedom the architect has to think about intent instead of clicking buttons.
🧪 Testing × production
Here’s one of the golden rules for anyone who publishes: never experiment where the customer is. The environment of test is where you can break things, make mistakes, and find out without risk; the production is where the customer actually uses it, and where an error is costly. They’re kept separate on purpose. Mixing the two is one of the biggest causes of accidents — which is why separating test × production is also a safety rule.
🧪 Test (draft)
- •It can break things as much as it wants
- •Fake data, no consequences
- •A place to experiment and learn
- •The client never sees
🌐 Production (live)
- •The client actually uses it
- •Real data, real consequences
- •Only what has already been tested gets included
- •Mistakes here are costly
⚠️ The classic accident
"It was just a quick little test in production." That's how you erase the customer database, send a thousand wrong messages, or charge someone twice. Testing is testing; production is production. When AI performs real actions, that boundary stops being a technical detail and becomes part of the security architecture.
Self-check (optional): why are testing and production kept in separate environments?
🎯 Module summary
Next module:
1.5 — Input and Output Channels: how the world talks to Jarvis and how he responds.