Landing Page Bootstrap

What it builds

Imagine you're a marketing consultant in Austin. You sign in, answer five onboarding questions, and say: "build me a landing page." Seven minutes later you have a one-page site at marketing-consultant-site.up.railway.app. A hero with your headline. A three-bullet value prop built from the pain you said you solve. An about section in your tone. Three services. A contact block. A footer. Semantic HTML, Tailwind via CDN, Inter from Google Fonts, responsive down to 320px. The repo is on your GitHub, public, ready to fork or customise. The Railway project is yours — no shared infrastructure.

It is not Squarespace-custom. It is a real, professional, live starting point — a first magic moment — shipped in the time it takes to make coffee.

Prerequisites

The CEO runs three preconditions before step 1. If any fails it emits an owner card and pauses until you resolve it.

• GitHub connected. Done from Power Grid in the app. If missing, you'll see a manual_task card: "Connect GitHub so I can save your site code."
• Railway connected. Paste a Railway token in Power Grid. Missing triggers: "Connect Railway so I can deploy your site."
• Onboarding answers. Business kind, team size, pain, north star, hands-on level. These come from the five-question interview; if any are missing the CEO asks you via a decision_required card.

Step-by-step walkthrough

Eight steps. Two run entirely in the CEO. Five delegate to the Coding Specialist. One runs the evaluator. Here is each one, in order, as specified in the canonical playbook.

Step 1 — Context gather (CEO)

No delegate. The CEO reads $BB_DATA_DIR/config.json and the business profile from Company Memory. It pulls the five required fields — businessKind, peopleCount, wishAutomated, northStar, handsOnLevel — and computes a URL-safe slug of {slug}-site. That slug is reused for the GitHub repo name, the Railway project name, and the deliverable id, so the whole run is consistently named.

Step 2 — Content draft (Coding Specialist)

The CEO delegates with a brief asking for a copy.json file with keys for the hero (headline, subhead, CTA label), a value-prop array of three bullets, an about paragraph, three services, a contact heading and subhead, and a footer. The tone is derived from your handsOnLevel. The goal the page should drive toward is your northStar. The hard rule is inked into the brief: no invented testimonials, metrics, or quotes.

Step 3 — Template render (Coding Specialist)

Given copy.json, the Coding Specialist renders a static site to $BB_DATA_DIR/landing-page-bootstrap/site/: an index.html with semantic markup, a one-paragraph README.md, and a minimal railway.json so Railway can serve index.html directly. Tailwind ships via CDN for zero build. The design brief is pinned to "modern minimalist" — one large hero, generous whitespace, a single accent colour plausible for your business kind, Inter from Google Fonts, mobile-first.

Step 4 — GitHub push (Coding Specialist)

Inside the site directory, the specialist initialises a fresh git repo, runs gh repo create --public --source=. --remote=origin --push with your token, and commits with the message Initial landing page for {businessKind}. It returns the repo URL in the specialist summary. If the repo name is taken, it appends -2, -3 and retries once. No deploy-approval card — the CEO already has your consent from the initial ask.

Step 5 — Railway deploy (Coding Specialist)

The specialist uses the Railway API to create a project named {slug}-site, link the GitHub repo as deploy source, trigger a deploy, and poll / for HTTP 200 up to five minutes. It returns the public URL. On failure it reads the Railway logs, applies one targeted fix, and retries. A second failure surfaces the logs and stops rather than looping silently.

Step 6 — Evaluator review (CEO)

The CEO calls the evaluator with a six-item rubric against the live URL:

• Page loads with HTTP 200.
• Body contains your businessKind and the hero headline from copy.json.
• No broken markup; no Tailwind CSS missing; no placeholder strings like TODO, LOREM, {{, [INSERT, or a literal null in the DOM.
• Mobile viewport ≤ 480px is usable — no horizontal scroll.
• Contact section is visible and has an email input.
• Single <h1>, a <main> landmark, alt text on any <img>.

PASS is required to proceed. On NEEDS_REVISION the render step is re-delegated with the evaluator's feedback, up to two cycles. Beyond that, the CEO escalates via the standard error-alert fallback.

Step 7 — Surface success (CEO)

The CEO emits one report_ready card with title "Your landing page is live!" and a one-line summary. The report body includes the live URL, a bullet summary of what's on the page, and a link to the GitHub repo. The card carries two actions: Visit your page (primary) and What's next? (secondary). The deliverableId and the URLs are stamped into the card's metadata so the UI can deep-link.

Step 8 — Log the outcome (CEO)

The CEO calls record_outcome with status "succeeded", a one-line summary, and the live URL as the artefact. That writes to the outcomes log — the beginning of your Company Memory. Future playbook runs read this log, so "build me another page like the last one" works a month later.

What you see as the owner

Backstage, eight steps. Frontstage, at most four cards. In order of likelihood:

• manual_task — "Connect GitHub" or "Connect Railway" — only if a precondition is missing.
• decision_required — only if an onboarding answer is missing. Rare on a first run through.
• report_ready — the success card with the live URL. This is the one you'll always see.
• error_alert — only if the Railway deploy or the evaluator both fail twice. In the common case this never appears.

Between cards, the UI shows lightweight progress — the CEO's status line updates ("drafting copy", "deploying to Railway") so you know something is happening. If you close the tab, the run continues; you'll see the card when you return.

What specialists are involved

• Coding Specialist — draft copy, render HTML, git push, Railway deploy. The muscle of this playbook.
• Evaluator — the PASS/NEEDS_REVISION gate before the owner sees anything. Protects you from broken output.
• CEO agent — context gathering, delegation, card emission, outcome logging. The conductor.

Time and cost

On a well-wired account the pattern is consistent: about 90 seconds of prompting and onboarding, then seven minutes of background work, then one card. Cost sits around 45 credits — which is well inside every tier's monthly budget, including Starter.

• Step 1 — under 5 seconds. Pure read.
• Step 2 — 30–60 seconds. Copy generation.
• Step 3 — 60–90 seconds. Template render.
• Step 4 — 10–20 seconds. Git push.
• Step 5 — 90–240 seconds. Railway build and healthcheck.
• Step 6 — 20–40 seconds. Evaluator verdict.
• Steps 7 and 8 — under 5 seconds combined.

The largest variance is Railway's cold-start build time. If you see step 5 taking longer than five minutes, the CEO will surface the logs — it does not loop silently.

Customising the output

Reply to the report card with specifics — "change the accent to navy", "rewrite the hero as a question", "swap the services for these four". The CEO re-delegates the render step with your feedback embedded in the brief, the evaluator re-runs, and you get a fresh card. Two iteration cycles are cheap; deeper redesigns are better done by Design Specialist (coming in v0.2) once that specialist lands.

You can also edit the GitHub repo directly. Every commit pushed to main auto-deploys through Railway, same as any conventional site.

Frequently asked

How long does Landing Page Bootstrap take?

About seven minutes prompt-to-URL when GitHub and Railway are pre-connected. Under ten minutes total even if you're connecting both for the first time.

Can I use my own domain?

Not from this playbook yet. v0.1 deploys to a Railway subdomain. Custom Domain Setup is on the v0.2 roadmap as a Pro-tier Skill Pack.

What if the copy is wrong?

Reply to the report with what you want changed. The CEO re-runs the render step with your feedback. Up to two evaluator cycles before escalation.

Why GitHub and Railway?

Free tiers, fast deploys, and real public URLs. They minimise time-to-live without compromising that you own the code and hosting.

Does the CEO invent testimonials?

No — hard rule in the spec. Copy is grounded in your onboarding answers. No fake metrics, no fake quotes, no fake logos.

Key takeaways

• Eight steps, two specialists, one evaluator gate — all pre-wired.
• About seven minutes prompt-to-URL with GitHub and Railway connected.
• Your code, your Railway project, your repo — not a shared sandbox.
• No invented testimonials. Copy is grounded in your onboarding answers.
• Iterate by replying to the report card; deeper redesigns edit the repo directly.

What to read next

• The Coding Specialist — the team member doing the rendering and deploying.
• The Evaluator — how the PASS/FAIL gate works.
• Triggering playbooks — when the CEO picks Landing Page Bootstrap vs. improvises.
• Custom Domain Setup — the v0.2 roadmap entry for BYO domain.
• Company Memory — why step 8 matters for later runs.