Form Factory’s operating model centers on a single insight: project success depends more on aligning what gets built with client needs than on how it gets built. The model prioritizes consensus-building, concrete artifacts over abstract requirements, and flexible sequencing driven by what’s ambiguous.
Why Code Is Cheap
The cost of generating code is falling fast. Traditional process assumed code was expensive: document everything upfront, get approval, then build once. When code becomes cheap, that logic flips — explore in code, prototype early, refine through working software instead of documents. (Source)
Engineering excellence isn’t diminished — it’s redirected. Less time writing code, more time designing systems and ensuring the right thing gets built. See repository-nerve-center for how cheap code also reshapes tooling and the role of the repo.
The Core Challenge: Consensus
Large organizations struggle to make decisions. Different teams want different things. Incentives misalign. The more people involved, the harder consensus becomes. In Form Factory’s history, this — not engineering capability — is what determines project success. (Source)
Form Factory helps organizations with conflicting priorities reach consensus on what to build by exposing options, articulating trade-offs, and mapping desires to real platform capabilities. Then building it.
Workflow
The model uses four elements. There is no rigid sequence — project leadership determines flow based on what’s ambiguous. (Source)
| Element | Tool/Surface | Purpose |
|---|---|---|
| Design | Figma | Visual exploration where consensus forms; concrete and approvable |
| Acceptance Criteria | Qase | Single source of truth for “done”; refined until merchant approves |
| Prototypes | Code | Disposable code to test ideas and surface edge cases |
| Merchant Approval | — | The gate where AC lock; before = fluid exploration, after = measuring progress |
Acceptance criteria in Qase remain the spine throughout, regardless of sequence. Sometimes requirements come first; sometimes design; sometimes it’s a data problem to explore in code.
Relationship to other processes
Prototypes as “disposable code” aligns with the placeholder-development philosophy — both treat early code as a conversation tool, not a commitment. Acceptance criteria in Qase map to the Given/When/Then format in user-story-guide, but the operating model emphasizes that AC are generated from designs, conversations, and prototype exploration — not written in isolation.
Fluid Role Boundaries
Role boundaries are becoming more fluid. Designers prototype in code. Engineers shape design direction. Everyone focuses on helping clients see what’s possible. This reflects the same cross-disciplinary vision described in repository-nerve-center, where all disciplines work from the same repo. (Source)
Measuring Success
| Metric | What it tells you |
|---|---|
| AC approval | Did clients understand what we’re delivering? |
| Qase pass rates | Did we build what we agreed to? |
| Rework and scope disputes | Was consensus real? |
Engineering velocity matters, but it’s a lagging indicator. Alignment is what drives outcomes. (Source)
See Also
- repository-nerve-center — how cheap code reshapes tooling and the repo’s role
- user-story-guide — acceptance criteria and the story writing process
- placeholder-development — disposable code as a development strategy
- product-backlog-example — worked example of the story/AC workflow