Frontmatter

Why frontend developers should own the backend handoff

The handoff is not a backend problem. It's a frontend artifact — and the frontend developer is the only one positioned to generate it correctly.

#backend-handoff#workflow#astro#solo#frontend

The traditional workflow puts handoff at the end.

Frontend ships. Backend receives. Someone in between writes documentation. Everyone hopes it matches.

It rarely does.

Where the mismatch comes from

The backend developer receives Astro source files they didn’t write, in a framework they may not use daily, with a component structure that made perfect sense to the frontend developer and is opaque to everyone else.

The questions are always the same:

  • What variables does this page need?
  • Which fields are required vs optional?
  • Where does this data come from?
  • What’s the expected shape of this array?

These are not backend questions. They are frontend questions, because the answers are encoded in the frontend source — in the Props interfaces, in the component composition, in the page structure.

The backend developer is asking the frontend developer’s code to explain itself. In a language neither of them speaks at that moment.

The frontend source already contains the handoff

An Astro component with a typed Props interface is already a specification:

---
export interface Props {
  headline: string;       // required
  sub?: string;           // optional
  ctaLabel?: string;      // optional
  ctaHref?: string;       // optional, pairs with ctaLabel
}
---

This interface tells you:

  • exactly which variables the template needs
  • which are required and which are not
  • the type of each variable

Every question the backend developer will ask is answerable from this file.

The problem is that the backend developer shouldn’t have to read it. They should receive something already translated.

Who is positioned to generate the translation

The frontend developer.

Not because they’re responsible for the backend. Because they’re the only one who can read the source correctly at the moment it matters.

The backend developer receives the Astro project after it’s done. They didn’t watch it being built. They don’t know which props were added last week, which components were split, which optional fields became required.

The frontend developer knows all of this — because they built it.

The correct workflow is:

  1. Frontend developer builds in Astro
  2. Frontend developer generates the handoff package from their own source
  3. Backend developer receives a complete, accurate package on day one

Step 2 is the one that usually doesn’t happen.

What “owning the handoff” looks like in practice

It means the frontend developer is responsible for producing:

  • Twig or PHP templates that match the Astro structure
  • a variable manifest listing every prop by template
  • an integration guide explaining what data goes where

Not as documentation written at the end. As a build artifact generated automatically.

npx @withfrontmatter/solo-check --root .
frontmatter solo:build --adapter twig

If validation fails, solo-check tells you exactly what to fix first. If you want AI assistance, open the packaged workflow with npx @withfrontmatter/solo-check --help-ai.

The build command then reads the Astro source, extracts the Props interfaces, and outputs:

output/
├─ pages/
├─ layouts/
├─ partials/
├─ manifest.json
└─ INTEGRATION.md

The frontend developer runs one command. The backend developer gets everything they need.

Why this changes the timeline

The standard handoff takes two weeks to actually start — not because anyone is slow, but because the back-and-forth of “what does this mean?” is slow.

When the handoff package is generated from the source, the backend developer can start immediately. There’s nothing to interpret. There’s nothing to ask.

The frontend developer doesn’t spend time answering questions they’ve already answered in their code. The backend developer doesn’t spend time reverse-engineering a framework they don’t use.

Both sides work from the same contract. Generated, not negotiated.

The shift in responsibility

This is not about putting more work on the frontend developer.

It’s about recognizing that the work already exists — encoded in the Props interfaces, the component structure, the page composition — and making it visible as a deliverable instead of leaving it implicit.

The frontend source is the spec. The handoff package is just the spec, translated.

Frontmatter Solo does the translation. The frontend developer stays the author.

Scope

Frontmatter Solo:

  • generates templates (Twig or PHP)
  • defines a variable contract (manifest + INTEGRATION.md)

It does not:

  • integrate with your backend
  • fetch data
  • configure a CMS
  • provide runtime behavior

Integration is explicit and owned by the host application.