Placeholder Development

Form Factory’s approach to unblocking feature development using placeholders. When part of a feature is blocked (incomplete UI, missing data models, unclear requirements), the blocked piece is isolated with a clearly-marked placeholder while unblocked work proceeds. Every placeholder is tracked via a dedicated Jira ticket and a TODO(TICKET-ID) comment in code. Related: pull-request-guidelines for PR size considerations when splitting work, and code-review-guidelines for how reviewers handle incomplete work with follow-up tickets (non-blocking comments).

Strategic Goal

Placeholders implement the walking skeleton and tracer bullet patterns — deliver a thin slice of functionality that touches all layers end-to-end, get fast feedback, then fill in detail. Prioritize placeholders that complete an end-to-end flow over those that perfect a component in isolation.

Decision Guide

Blocked?
  ├── Low uncertainty → Use a placeholder
  ├── High uncertainty → Enabler ticket first, then placeholder
  └── Trivial work → Just do it

When uncertainty is too high for even a reasonable placeholder, create a time-boxed enabler ticket (see user-story-guide for enabler types) to reduce uncertainty first.

Placeholder Types

Type	When to Use	Pattern
UI	Shared component doesn’t exist or isn’t finalized	ComponentPlaceholder suffix, minimal render, disposable styling
Data	Data models incomplete or APIs unavailable	Mock data / static structures with assumed contract
Path	Multiple user flows, some blocked	Happy path first, stub alternates with simple fallbacks
Rules	Business rules complex or unfinalized	Simplified common-case logic, document assumptions

Conventions

• Naming: UI placeholder components use the Placeholder suffix (e.g., LabelPlaceholder)
• TODO format: // TODO(TICKET-ID): Description — every placeholder gets one
• i18n: All placeholder user-facing text must use useTranslation — the linter enforces no hardcoded strings in TSX. Add placeholder keys to locales/translation/en.ts in a dedicated section
• Jira: Feature ticket description lists placeholders used and links to replacement tickets
• QA: Test the feature as if the placeholder were real; don’t raise bugs for expected placeholder limitations

Placeholder Ticket Template

Each placeholder replacement ticket should include:

• Placeholder type and location in code
• Current behavior — what it renders/returns, assumptions, limitations
• Target behavior — full functionality, edge cases, integration points
• Acceptance criteria — Given/When/Then scenarios