Frontmatter

Astro project delivery checklist — what to ship to your backend developer

A practical checklist for frontend developers delivering an Astro project to a backend team. What to include, what to generate, and what to never hand off manually.

#astro#backend-handoff#workflow#checklist#solo#twig#php

You’re done with the Astro project.

Before you hand it off, go through this list.

1. Every component has a typed Props interface

---
export interface Props {
  headline: string;
  sub?: string;
}
---

If a component doesn’t have a typed Props interface, the backend developer has no contract to work from. Add it before you ship.

Why it matters: The Props interface is what build-time tools like Frontmatter Solo use to generate the variable manifest. No interface = no automation.

2. Optional props are correctly marked

export interface Props {
  headline: string;   // required — backend must always provide this
  sub?: string;       // optional — backend can omit this
}

Every ? is a signal to the backend developer that they don’t have to provide that value. Every missing ? is a guarantee they do.

Get this right before shipping. Fixing it after the templates are generated means regenerating everything.

3. No hardcoded content in components

If a component renders a hardcoded string instead of a prop, it won’t be editable by the backend:

<!-- Wrong — not a prop, backend can't change this -->
<h1>Welcome to our site</h1>

<!-- Correct — exposed as a prop -->
<h1>{headline}</h1>

Scan your components for hardcoded content before generating the handoff.

4. Slots are used where content should be composable

If a layout or section should accept arbitrary content from the page:

<section class="section">
  <h2>{title}</h2>
  <slot />  <!-- becomes {% block content %} in Twig -->
</section>

Slots translate to Twig blocks or PHP include-points. If a slot is missing where it should exist, the backend developer won’t have a way to inject content.

5. Generate the render pack — don’t write it

At this point, validate first, then build:

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

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

You should get:

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

If you don’t have Frontmatter Solo, you can generate this structure manually or use a build-time tool. It pays for itself on the first project where you’ve had to answer “what does this prop do?” more than twice.

6. Review the INTEGRATION.md before sending

Open INTEGRATION.md and read it as if you’re the backend developer seeing this project for the first time.

Check that:

  • every page has its list of required variables
  • every partial has its expected data shape documented
  • optional fields are clearly marked
  • there are no variables listed as required that the backend can’t reasonably provide

This document is the backend developer’s starting point. If it’s unclear to you, it will be unclear to them.

7. Include a preview if the adapter supports it

Frontmatter Solo can generate a preview-php/ directory — a plain PHP rendering of the templates with stub data. This lets the backend developer verify the output structure before wiring real data.

If your backend runs Twig, a preview-twig/ equivalent works the same way.

8. Don’t ship the Astro source as the handoff

The Astro source is not the deliverable. It’s the origin.

Shipping .astro files to a backend developer who works in Symfony, Drupal, or WordPress is the equivalent of shipping a Figma file to someone who needs a PDF.

They can open it. It doesn’t help them.

The deliverable is the render pack: templates, manifest, integration guide. Generated from the source. Not the source itself.

9. Agree on the adapter format upfront

Ask the backend developer before you generate anything:

  • Twig: Symfony, Drupal, Craft CMS, any Twig-capable framework
  • PHP: WordPress, custom CMS, legacy PHP, anything without a templating engine

Running the wrong adapter wastes time for both sides.

10. Tag the version

Before handing off, tag the Astro source in git:

git tag handoff-v1

This gives both sides a stable reference point. If props change after handoff, the backend developer can diff against the tag to see exactly what changed in the contract.

The short version

  1. Type your props
  2. Mark optionals correctly
  3. Remove hardcoded content
  4. Add slots where needed
  5. Run npx @withfrontmatter/solo-check
  6. Run frontmatter solo:build
  7. Review INTEGRATION.md
  8. Ship the output folder, not the source

The backend developer should be able to start immediately. If they have questions, the handoff is not done.

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.