Your workspace is ready and your agent is waiting. Now you choose what to build the app out of: the language, the framework, the database where your data lives, and the place it runs. Ignore the hundreds of options and the fights about them. This chapter hands you a stack to start on today, and a prompt that picks the right one for your case with a senior engineer's judgment.
1.7.1A stack is layers, bottom to top
A stack is just the layers your app is built from, each sitting on the one below:
- Platform: where it runs, web, iPhone, or desktop. This choice decides everything above it.
- Language: the code it is written in, like TypeScript or Python.
- Framework: a proven structure on top of the language, so you do not start from a blank page.
- Boilerplate: a ready-made starter project, so you begin from a working app instead of an empty folder.
- Libraries: open-source pieces you drop in for one specific job instead of building it yourself.
- Services: whole capabilities you rent and call over the internet, like payments or email, instead of running them yourself.
You pick from the bottom up, and at each layer the popular choice is usually the right one.
1.7.2Reuse first, build your own last
Every layer points the same way: start from what already exists. Reach for a proven framework first, then stand a starter on top of it. Wire in open-source projects and paid services through their APIs, the doorways programs use to call each other. You write your own version of a piece only when nothing out there fits.
This is not laziness, it is leverage. A payment flow or a login system has absorbed years of edge cases you have never seen. Rebuild it by hand and you meet every one of them yourself.
You move fast because you integrate proven parts, not because you type faster. If a solid, maintained option already exists, use it. Building your own is the last resort, not the first move.
1.7.3Default to the popular choice
Pick the most common option unless a hard requirement forces otherwise. Your agent has built it countless times and makes fewer mistakes with it, so popularity is really how much help you get.
1.7.4A stack for almost any app
For a typical web or consumer app, take this as-is:
| Piece | Use | Why |
|---|---|---|
| Frontend, what the user sees | React, via Next.js | The default way to build a web interface |
| Backend, the code behind it | Node with TypeScript | Same language as the frontend, one stack to run |
| Database, where the data lives | PostgreSQL | Proven, free, handles almost anything |
| Hosting, where it runs online | A plain rented server, like Hetzner | Cheapest and simplest; a plain server suits your agent better than a fancy dashboard |
One language front to back. Next.js can serve both sides, so it is often the whole stack on its own.
Hosting is the one row you do not act on today, since nothing leaves your laptop for a while yet. You pick a host for real in the ship part, where the tiers and their true costs get compared.
1.7.5Switch when the job demands it
The default holds until your app has a real requirement. Then a senior engineer moves deliberately, one line each:
- AI or heavy data: a Python backend, its ecosystem is years ahead.
- Very low latency or high throughput: Go or Rust on the hot path.
- A static or brochure site: no backend or database at all.
1.7.6Let your agent choose for your case
This prompt already carries the engineering judgment. Paste it in and describe your app in the one slot at the bottom, nothing in the middle to hunt down and replace:
Do this now: take the default stack, or paste the prompt and describe your app at the bottom. Then lock one tool into each piece before the next chapter.