Your agent is set up and it knows your rules. The next question sounds obvious until you try to answer it: what shape does this thing take? People say "an app" and mean a dozen different things, and the answer decides every tool choice after it. This chapter settles it.
1.4.1Offline or online is the first fork
Everything splits on one question: does your app need a server?
An offline app runs entirely on the user's device. No accounts, no syncing, no shared data, and nothing to keep alive at three in the morning. A calculator, a notepad, a single-player game.
Everything else needs a server. The moment two people share data, money changes hands, or a phone and a laptop must show the same thing, you need somewhere neutral that holds the truth. This book assumes that from here on.
1.4.2Your interface is one of many
With that settled, the only remaining choice is what the user touches. That is your interface, and the list is longer than "a website":
| Interface | What it is |
|---|---|
| Web app | Runs in a browser, nothing to install, updates instantly |
| Mobile app | Installed from a store, store review on every update |
| Desktop app | Installed on a computer, can reach local files |
| Browser extension | Adds itself to pages the user already visits |
| Platform plugin | Lives inside WordPress or Shopify, borrows their users |
| Editor extension | Lives inside a tool like VS Code, aimed at developers |
| Assistant app | Called by an AI assistant on the user's behalf |
| Command line | No screen at all, just typed commands, fastest to build |
You can ship more than one, and most serious products eventually do.
1.4.3One backend, many faces
Here is the rule that makes that whole list cheap: every interface is a presentation layer, and nothing more.
Your rules, your data, your calculations and your keys all live in the backend, the code running on your server where users cannot reach it. Each interface asks for what it needs through an API, a fixed set of allowed requests, and draws whatever comes back.
Build it this way and a second interface costs you a shell, not a rebuild. Build it the other way, with logic sitting in the interface, and you write every rule again for every screen while a stranger reads all of them.
Rule of thumb: if a rule would embarrass you when a user reads it, it does not belong in the interface.
1.4.4The shell changes, the engineering does not
Your interface changes a handful of things: how updates reach users, whether someone reviews your release, what still works with no signal, and how a user proves who they are.
It changes nothing about your spec, your architecture, your tests, your security, your deploy, or the way you direct your agent. That is why this book can cover all of them at once. Pick the first interface and keep going.
1.4.5Let your agent name your first interface
Do this now: paste the prompt and lock in your first interface, then have your agent record it in your rules file before you pick a single tool.
