Skip to main content

What to Build It With

Share

Share this page

Pass it to someone who needs it.

Star on GitHub

Key takeaway: Pick boring, popular stack

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.

Work down the reuse ladder; writing your own is the last resort.

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:

PieceUseWhy
Frontend, what the user seesReact, via Next.jsThe default way to build a web interface
Backend, the code behind itNode with TypeScriptSame language as the frontend, one stack to run
Database, where the data livesPostgreSQLProven, free, handles almost anything
Hosting, where it runs onlineA plain rented server, like HetznerCheapest 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:

Ready prompt
Act as a senior engineer choosing my stack. Read my rules file first, and keep any language, framework, or tool it already names unless my case forces a change. Say why if it does. Recommend a frontend, backend, database, and hosting for the app below. Default to the simplest, most popular, agent-friendly option, and override only with real engineering judgment: - Typical web or consumer app: TypeScript everywhere. - AI or heavy-data app: Python backend for the ecosystem. - Low-latency or high-throughput core: Go or Rust there. - Weigh ecosystem maturity, hosting cost, and how easily an agent can maintain it. For each choice: one line of reasoning, plus one alternative and its tradeoff. Once I confirm, write the stack into my rules file, so every later session builds on it. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/setup/choosing-your-stack My app:

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.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Star on GitHubContribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license