ADR-012-F: Adopt All 365 Competitor Features, Prioritise by Build Order¶
Status: Accepted Date: 2026-04-16 Decision Makers: Gautham Chellappa
Context¶
Brainstorm-12 audited 13 competitor systems (Fasttrack360, Staffd, SmartAI, MakeSure Verify, Flare HR, DBIT/DPAY, Xero, Bullhorn, 2cloudnine, 3B Onboarding, idibu, Whatfix, RatesCalc). The audit identified 34 feature gaps plus confirmed ~331 features Finnest already plans to cover. Total feature surface: ~365.
The question is scope discipline: adopt narrow (pick the top 30 features, ship faster) or adopt broad (every useful feature, prioritise by phase).
Gautham's stated working style is "adopt features broadly, prioritise by build order (no scope discarding)" — rather than repeatedly re-litigating scope decisions, decide once that the feature surface is broad, then manage delivery through phasing.
Decision¶
Finnest adopts all 365 features identified across the brainstorm and research corpus. No feature is categorically rejected. Scope management happens via phase assignment (P0 through P5) in research/08-master-feature-inventory.md, executed over the 44-week roadmap.
Prioritisation model¶
| Priority | Meaning | Phase |
|---|---|---|
| P0 | MVP — launch blocker | Phase 1 (Weeks 5–12) |
| P1 | Operations-ready | Phase 2 (Weeks 13–20) |
| P2 | Full platform | Phase 3 (Weeks 21–32) |
| P3 | Maturation | Phase 4 (Weeks 33–44) |
| P4 | Post-launch year 2 | Beyond 44 weeks |
| P5 | Speculative | Evaluated on customer demand |
Architectural implication¶
Every feature maps to a module in the 19-module inventory (research/07-complete-module-inventory.md). Modules designed to accommodate their full feature surface — not stripped-down MVPs that need re-architecting to absorb P3+ features later.
Example: finnest_performance (Tier 5, 10 tables) is designed to hold goals, OKRs, reviews, 360, pulse surveys, eNPS, calibrations, development plans, skills matrix — even though Phase 1 ships only the minimum. When Phase 3-4 delivers the remainder, the schema is already shaped correctly.
Competitor-audit gap closure (B12)¶
All 34 gaps accepted into the roadmap:
- 6 Critical (Phase 1-2): compliance auto-blocking (ADR-011-F), super onboarding wizard, DVS integration, liveness detection, award-aware billing, timesheet-to-invoice automation
- 10 High (Phase 2-3): single-record candidate→employee lifecycle, interview scheduling, job board multi-posting, client hierarchy, split billing, margin visibility, credential registry verification, Xero/MYOB, ongoing monitoring, analytics dashboard
- 14 Medium (Phase 3-4): re-induction scheduling, competency reviewer, client onboarding workflow, bias detection, candidate rediscovery, drip campaigns, digital identity wallet, PEP screening, 100-point ID check, outbound webhooks, labour-hire licensing, portable LSL, consent management, custom form builder
- 4 Low (Phase 4+): AI job description writer, OCR scanned CVs, multi-language CV parsing, video interview integration
Features explicitly not in scope (the only exceptions)¶
Two categories of features that B12 identified but chose not to adopt:
- L5 (Salary packaging / novated leasing) — specialist domain; consider partnership with Flare rather than build
- L6 (Benefits/perks marketplace) — specialist domain; partnership path likely
These remain in scope as future integrations (via Accounting port or similar), not native features.
Alternatives Considered¶
| Alternative | Rejected because |
|---|---|
| Narrow scope — ship 30 features as v1.0 | Risks losing ASG anchor client; Fasttrack360 already has the broad surface; labour-hire clients need completeness, not a tech-demo |
| Adopt per competitor selectively | Leads to repeated scope re-litigation; every new competitor audit restarts the discussion |
| Phase 3+ features built as separate "Finnest Extended" product | Creates a second product to sell, support, and maintain; muddies the commercial story |
| Outsource long-tail features | Doesn't exist at the quality bar Finnest needs; also defeats the single-platform value proposition |
Consequences¶
Positive:
- Scope decisions made once, executed via phasing — no repeated "should we build X?" debates
- Modules designed for their full feature surface — no Phase 3 re-architecture
- Competitive parity at Phase 3; advantage at Phase 4 (AI agents + multi-industry + IRAP + asset management as native)
- Clients see a clear 44-week progression, not a moving target
Negative:
- Commits to ambitious scope — missed milestones are more visible
- 3-person team is heavily leveraged — relies on AI-assisted development delivering the productivity assumption
- Some Phase 3+ features may become obsolete by the time they're built (partial mitigation: P5 is explicitly evaluated on customer demand)
Risk mitigations:
- Phase gates (P0 through P5) create natural scope-reduction points without "cutting features"
- Atomic architecture (D7) means complexity = max(feature), not sum — absorbing 365 features doesn't linearly increase build cost
- Agent-centric UX (B09) handles discoverability for broad surface — 365 features aren't 365 nav items
Tipping points for re-evaluation:
- Milestone slip of >4 weeks on any phase → review remaining scope against commercial commitments
- New competitor emerges with a genuinely novel feature class (not just a variation) → amend inventory, not this ADR
Relationship to Guardrails¶
Enforces / informed by: D14 (lean team velocity), D7 (atomic feature isolation), Commandment #4 (YAGNI) — scope is "all 365 features" but implementation of each feature still obeys YAGNI per feature.