Engine, Then Sidecars

"Finish the engine. Open the API. Let the sidecars come after. In that order, never scrambled."

The Order Is the Lesson

API-first isn't only about where the boundary is — it's about when things get built. Ember was built first and opened its API; only then did Cinder become a consumer. Bonfire inherits the exact sequence: complete the engine, open the API, and let sidecars (the Sidekick's deeper features, the eventual Live bridge) come after. The built-in UI is the first client precisely because it's the one that proves the engine's API is real.

Why Not Build the Sidecar Early

It's tempting to build the exciting sidecar in parallel with the engine — the Live bridge, the fancy coaching mode. But a sidecar built against a half-finished engine API is building on sand. The engine's surface is still moving; every endpoint you consume might change shape next week. So the sidecar churns: rewrite, rebreak, rewrite. You spend your effort tracking a moving target instead of finishing the target. Worse, the unfinished sidecar creates pressure to freeze the engine's API before it's actually right.

Concrete-First, Not Anticipatory

This is the same discipline as 'don't generalize in anticipation' (you'll see it again in Track 8). You don't build the second consumer before the first one is solid, and you don't design the API for imaginary needs — you design it for the one real client in front of you (the UI) and trust that a clean, real boundary will serve the next client too. Concrete-first means the engine and its first UI client get finished and proven before anything speculative gets built on top. Sidecars are a reward for a finished engine, not a co-requisite.

Code

Engine -> API -> sidecars, never scrambled·text

Ember:    build engine ──→ open API ──→ Cinder consumes it
Bonfire:  build engine ──→ open API ──→ UI consumes it ──→ (later) Live bridge
                                         ▲ first client = proof the API is real

# Sidecars come AFTER the API is real, never before.
# A sidecar on a half-built engine API just churns.

Exercise

Think of a project where you (or a team) built a consumer and its dependency in parallel. How much rework did the consumer eat as the dependency's interface shifted? Now imagine the other order: dependency finished and frozen first, consumer built against a stable surface. Estimate the rework saved. That delta is the cost of scrambling the order.

Hint

The churn shows up as 'we had to rewrite the client again because the API changed.' Count those rewrites. Most of them vanish if the producing side is finished and stable before the consuming side starts.