Blank Screen to Running App

You have a spec, an architecture, and an empty folder. The instinct is to open your agent and generate the first feature, but there is nothing for that feature to live in yet: no app that runs, no page that loads. This chapter gets you from that empty folder to a running app skeleton you can see in a browser and commit as your known-good baseline.

5.1.1From blank folder to running appAdd note

The gap that stalls people is not writing features, it is the plumbing before the first one: install the tools, wire the build, get a server to boot. Your first goal skips straight past that struggle.

Aim for a running app that does almost nothing useful yet, a skeleton that boots, serves one page, and proves the whole toolchain works end to end. Once it runs, every feature drops into something already alive, so a broken feature stands out against a baseline you know works.

5.1.2Start from a boilerplateAdd note

Do not hand-assemble the plumbing. A boilerplate is a ready-made starter project with the build, the config, and one working page already wired together, and a scaffolder is a single command that generates one in seconds. For a typical web app, create-next-app is the fastest path from nothing to running:

npx create-next-app@latest my-app
cd my-app
npm run dev

That leaves you a project that already boots at http://localhost:3000, with a shape like this:

my-app/
  app/
    page.tsx      (the home page you see)
    layout.tsx
  public/
  package.json

Watch out: get the default booting and committed before you customize anything. If you tweak first and it breaks, you cannot tell whether the boilerplate or your change is at fault.

5.1.3Get one thing on screen firstAdd note

Before a single feature, put one thing on screen that is unmistakably yours. Open the home page the scaffolder made and replace it with your app's name:

// app/page.tsx
export default function Home() {
  return <h1>Ledger is running.</h1>;
}

Save, and the page in your browser updates on its own. Seeing your own words render proves the loop you will live in all through building: change a file, see the result. That tiny win is the entire point of the skeleton.

5.1.4Commit the skeleton before featuresAdd note

A running skeleton is the most valuable state your project will be in for a while: it works, and nothing you have added can have broken it yet. Lock it in with a commit before you touch a feature.

git add -A
git commit -m "chore: scaffold running skeleton"

From here, every feature is a change against a known-good baseline. When something breaks, and it will, you can always get back to an app that ran. Steering your agent through those features, one small slice at a time, is what the rest of this part teaches.

This prompt has your agent scaffold that skeleton for your stack:

Act as a senior engineer scaffolding my project.
Pick the right scaffolder for my stack and use its
official generator: create-next-app for a Next.js
web app, Vite for a plain single-page app, or the
framework's own CLI otherwise. Generate the
starter, get it booting locally, and confirm the
dev server serves one page in the browser. Then
replace that page with a single line showing my
app's name, so I see my own output render.
Do not add any feature yet. Show me the commands
to run and the file tree they produce first.

My app idea and stack:

Do this now: paste the prompt, name your app and stack, and let your agent scaffold a running skeleton, then commit it before you build a single feature.