Engine, Then Sidecars

"Prove the contract with the engine and its first client. Add the second sidecar after that."

The Order Is the Lesson

API-first is not only about where the boundary goes. It also limits how many consumers you validate at once. Bonfire starts with a thin engine vertical slice and a public contract, then uses the built-in UI as the first real consumer. The engine and UI may co-evolve while that slice becomes useful. The rule is not to finish the entire engine before starting the UI; it is to keep a second set of imagined Sidekick or Live-bridge requirements out of the contract until the first flow proves it.

Why Not Build the Second Sidecar Early

It is tempting to build an exciting sidecar beside the first vertical slice. But attaching several consumers to a contract the first client has not validated multiplies every change. Freezing the API too early causes the opposite failure: the first UI cannot teach the engine what the real contract needs. The accurate sequence is: let the engine and one real client validate a boundary together, stabilize that boundary, then add a second consumer.

Concrete-First, Not Anticipatory

This is the same discipline as 'do not generalize in anticipation' from Track 8. Design for one real UI workflow, complete a small end-to-end path, and clean the boundary revealed by that path. Concrete-first does not force producers and consumers into a rigid serial schedule. It limits the concrete case under test to one, so speculative consumers do not shape the API before they exist.

Code

Validate one vertical slice before the next consumer·text

Bonfire: thin engine slice ─┬─→ public contract ─┬─→ built-in UI
                             └────── feedback ──────┘
                                            │ proven in one real flow
                                            └─→ (later) Sidekick / Live bridge

# The engine need not be complete before the UI begins.
# Engine + first client prove one boundary before a second consumer arrives.

Exercise

Recall a project where an API and its consumers evolved together. Separate changes that improved the contract because of the first real consumer from churn caused by attaching a second or third consumer too early. Define one vertical slice that would validate the contract first, and the evidence that would justify adding the next consumer.

Hint

Feedback from the first client helps discover the contract. Churn grows when several clients depend on an unproven one. The goal is not perfect serial development; it is fewer simultaneous variables.