Multi-Page Site with Cowork

Multi-page websites used to be the thing everyone avoided. Static site generators, build toolchains, component frameworks, hydration mismatches. You wanted four pages; you got a webpack config and a bad afternoon.

That friction is gone. A four-page static site with shared chrome, a working contact form, and auto-deploy on every push is now a one-session build with a good pair programmer. This is a walkthrough of exactly that session, written alongside the actual build of the site you're reading this on.

The pair programmer was Claude Cowork. The output is a four-page static site deployed on Netlify. No build step. No framework. No opinions you can't override.

What We Built

One landing page with a 3-by-2 card grid. Three content pages behind it:

• /edu for articles like this one
• /research for intelligence reports
• /consult for a Netlify-backed intake form

Plus external redirects to sibling brands, a shared visual chrome (HUD grid, floating particles, corner brackets), and a live form that collects submissions without any backend code.

Total source: six HTML files, one CSS file, one JS file, two config files. No build step. The directory ships as-is.

The Mental Model

A multi-page static site is nothing more than HTML files in folders. The "multi-page" part is just Netlify (or any static host) serving about/index.html when someone visits /about. That's it. There's no magic.

The two problems people try to solve with frameworks are:

1. Shared chrome. Every page has the same nav, footer, background layers. Frameworks solve this with components. For a small site, you solve it with one shared stylesheet and a tiny script. You pay a one-time cost: when the chrome HTML changes, you update every page. For a four-page site, that's acceptable.
2. Clean URLs. You want /edu, not /edu.html. Netlify handles this for free if you use the nested index.html pattern. No config needed.

The File Layout

m0ntan1-com/
├── index.html           # Landing
├── edu/
│   └── index.html       # /edu
├── research/
│   └── index.html       # /research
├── consult/
│   └── index.html       # /consult (form)
├── assets/
│   ├── site.css
│   └── site.js
├── netlify.toml
└── README.md

Every HTML file links /assets/site.css and /assets/site.js. Every file duplicates the chrome markup (nav, background layers, footer). That's the deal.

How the Session Actually Went

The starting state was a single-file landing page with a 3-by-2 card grid. One HTML file, ~800 lines, everything inline. Working, shipped, good enough to show people.

The move to multi-page happened in five Cowork instructions. Not five days of work. Five messages.

1. "Extract the shared chrome into site.css and site.js."

Cowork read the single file, pulled the styles and the background-layer JS out into two new assets, and rewrote the landing page to link to them instead of embed them. One tool call per file. Zero configuration.

2. "Now scaffold three inside pages: /edu, /research, /consult."

Cowork created the three nested folders and dropped an index.html in each. Each inherited the same chrome markup, swapped the hero title, and got its own content section. The /consult page got the Netlify form markup.

3. "Wire up a Netlify form for consult intake."

Netlify forms work by scanning deploy output for a data-netlify="true" attribute plus a hidden form-name input. Add a honeypot field to cut spam. That's the entire integration.

<form name="consult-intake"
      method="POST"
      data-netlify="true"
      netlify-honeypot="bot-field"
      action="/consult?sent=1">
  <input type="hidden" name="form-name" value="consult-intake">
  <p hidden>
    <label>Leave blank: <input name="bot-field"></label>
  </p>
  <!-- real fields -->
</form>

No server code. No form backend. Submissions appear in the Netlify dashboard. You get email notifications for free.

4. "Add a netlify.toml."

Publish the current directory, no build command, a few security headers. Thirty lines of config. Cowork wrote it. I glanced at it. Ship.

5. "Write the deployment doc and this article."

You're reading the second half of that instruction.

The One Real Gotcha: Nested Git

The site source lives inside a larger research vault that's already a git repo. That's a nested-git situation and it needs handling.

The fix is simple: the outer repo stops tracking the site directory (one line in .gitignore), and the site gets its own .git folder pointing at its own GitHub repo. Netlify connects to the site's repo, not the outer one. Two independent histories, one directory tree.

Full commands are in DEPLOYMENT.md. The important idea: nested git is fine, you just have to be explicit about which repo owns which files.

What Cowork Did vs. What I Did

Worth naming, because the division of labor is the interesting part.

Cowork did:

• Wrote every line of HTML, CSS, and JS
• Extracted the shared chrome cleanly without breaking the landing page
• Scaffolded the three inside pages with correct link paths and accessible markup
• Wired the Netlify form with the right honeypot and action attributes on the first try
• Wrote this article

I did:

• Decided it should be multi-page instead of sprawling
• Picked the page set (edu / research / consult) based on what the business actually needs
• Corrected the card grid from 3-by-3 to 3-by-2 when Cowork guessed wrong
• Asked for the tagline word-by-word pulse animation
• Locked the visual identity (palette, typography, feel) so Cowork had something to design against
• Made the call on clean URLs, no build step, git-connected auto-deploy
• Held the line on voice in the prose

Cowork is a strong junior engineer with instant hands. Not a designer, not a product manager, not a brand strategist. If you give it good taste to design against, you get output that matches your taste. If you don't, you get output that matches whatever taste the internet averages to.

Try This Yourself

If you want to replicate this pattern on your own project, the minimum viable starter is about six files. Here's the order that worked for me:

1. Pick your pages first. Not the design. The pages. What does each one do? Who's it for? Write it down before you start.
2. Build the landing page single-file. One index.html, everything inline. Get the visual identity right before you split anything.
3. Extract shared assets only when you know they're shared. Don't pre-optimize. Cowork can refactor when the time comes.
4. Use the nested index.html pattern for clean URLs. Don't touch redirects unless you have a reason.
5. Pick Netlify or Cloudflare Pages. Both are free for static sites, both do git-connected auto-deploy, both handle forms. I use Netlify because the form backend is the simplest I've found.
6. Put the site in its own git repo. Even if it lives inside a bigger directory tree, give it its own .git. Future you will thank present you.

What I'd Change Next

Real images instead of picsum.photos placeholders. A proper OG image for each page instead of the default. A sitemap.xml once the page set stabilizes. Maybe a light/dark toggle, though the HUD aesthetic doesn't really translate to light mode.

None of that is blocking. The site ships. That's the point of this style of build: you get to shipped, and then you iterate on a living site instead of negotiating with a framework.

The Takeaway

A few years ago, this build would have been a framework evaluation, a toolchain fight, and two evenings of documentation reading. It's now a single focused session with a pair programmer that already knows the tools.

The craft didn't disappear. It moved. You still have to decide what to build, who it's for, what it should feel like, and what the actual truth is that you want the site to tell. Those aren't Cowork's jobs. Those are yours.

Cowork is just faster hands.

Cross-posted to Montani AI. Questions, corrections, or your own war stories: drop a note via the Consult Gateway.