Guide · Web development
The Astro project is done. The backend team is waiting. What you hand them determines whether they can start on day one or spend two weeks reverse-engineering the frontend.
What usually goes wrong
The typical handoff package: the Astro source, a walkthrough video, a Notion doc explaining the components. None of it is wrong. None of it answers the question the backend developer actually has: for each page, which variables do I need to provide, in what shape, at what route? A description is not a contract.
If the backend developer has to open an Astro component to understand what props it expects, the handoff isn't done. They're doing work that the frontend should have delivered as an artifact. Multiply that by 20 components and you've added a week to their estimate.
A prop is renamed. A component is split. An optional field becomes required. If the handoff was a manual document, it's now out of sync. The backend developer finds out when something breaks in staging — not when the change was made.
What a clean handoff delivers
Not a description of the components. The actual templates — in Twig or plain PHP — with correct HTML structure, correct class names, and correct variable slots. The backend developer gets files they can use directly. They don't need to read Astro.
A machine-readable map of what variables each template expects — name, type, required or optional. This is the contract. The backend developer knows exactly what to inject without opening a single frontend file.
A human-readable document per page: which templates compose the page, which variables are required, where each data point is expected to come from — CMS field, database column, API response. With this, the backend developer can start on day one.
Why this is usually done manually — and shouldn't be
An Astro component's Props interface is the variable manifest. The JSX structure is the template body. The page composition is the routing and include structure. Nothing has to be invented — it has to be extracted and translated. That's a mechanical process, not a creative one.
A handoff document written once, by hand, goes out of sync the moment the frontend changes. Generating the handoff package from the source at build time means it's always current — the manifest reflects the actual component, not the component as it was when someone last updated the doc.
How I deliver it
The frontend is built in Astro with constrained props — literal values only, one layout per page, no client-side islands. This constraint is what makes automated extraction possible.
Frontmatter Solo is a build-time tool that reads the Astro project and generates the full render pack — Twig or PHP templates, manifest.json, and INTEGRATION.md — in a single command. The output is always in sync with the source.
The backend team receives templates, a manifest and an integration guide. They can start immediately. If the frontend changes, Solo regenerates the pack. The contract stays current.
What Solo generates
output/ ├─ pages/ │ └─ index.html.twig ├─ layouts/ │ └─ base.html.twig ├─ partials/ │ ├─ hero.html.twig │ └─ section.html.twig ├─ manifest.json ├─ INTEGRATION.md └─ frontmatter.build.json
Solo supports Twig output for Symfony and Drupal integration, and plain PHP for WordPress and custom PHP backends. Same structure, same variable contract, different syntax.
Who this is for
Services
Backend handoff service — Astro frontend built to the Solo contract, Twig or PHP render pack generated, INTEGRATION.md included. Your backend team can start on day one.
Related
The full service offer — from custom websites to backend handoff.
Performance, security and maintenance — what each stack costs in practice.
What the alternative stack looks like and what you gain from it.