Releases and team
The five delivery phases inside and after the three-month V1 frame, live plan figures, milestones and Gantt, who is responsible for what (RACI), how effort is estimated, and a capacity analysis computed from the plan with the real levers.
V1 — design, development and deployment, the reseller web included — fits in three months from the cadrage: production at the start of January, a two-week pilot right after, then generalisation and V2 (team decision of 18 October 2026). The cahier's ten-phase roadmap (§14) and its V1/V2 split (§14.1, §14.2) map onto five delivery phases; every date on this page is computed by the scheduler from content/plan/tasks.json (planning method) — none is typed by hand.
Phases
| Phase | Cahier phases (§14) | Delivers | Exit milestones | In the frame |
|---|---|---|---|---|
| P0 — Foundations | 1 Cadrage · 2 UX/UI · 3 Architecture | Validated rules and the decision register's first answers (decisions); the design system and every screen (21 working days); the service catalogue, the database schema and the API contract v1 with its mock server; the Flutter foundations; CI/CD and environments | Cadrage validated · Design system v1 ready · Screen inventory frozen · API contract v1 published · Design handoff complete · Mobile foundations ready | Yes |
| P1 — V1 build & integration | 4 Back-office V1 · 5 App revendeur V1 · 6 App délégué V1 · 7 Intégration | Server modules, back-office, reseller web, both Flutter apps; staging integration, field test, store readiness, test automation; Akram's document templates, notification copy, store assets, training material, V2 designs, design QA and the scripted functional campaign | Server V1 feature-complete · Mobile apps V1 feature-complete · Back-office and reseller web V1 feature-complete · Staging integration complete | Yes |
| P2 — Acceptance, go-live & pilot | 8 Tests · 9 Pilote | End-to-end tests on staging, HOCO's acceptance on pre-production and the signed PV (acceptance scenarios), production go-live with the initial import, training, the two-week pilot | Acceptance report (PV de recette) signed · Production go-live · Pilot starts · Pilot go / no-go | Go-live and pilot start are inside; the pilot ends just after |
| P3 — Generalisation | 10 Généralisation | Pilot improvements, progressive opening zone by zone, public Play release, iOS if HOCO decides (D-10) | Generalisation complete | After the three months |
| P4 — V2 evolutions | §14.2 | Loyalty, packs, detailed credit, per-reseller price agreements, carrier and WhatsApp Business integrations, tour optimisation, stock-system sync, advanced analytics | V2 delivered | After |
Two rules hold across phases: the documentation is written first and no application code starts before it is done — every build task starts from these specifications; and every API change goes through the contract before the server implements it (API-contract workflow).
119 open tasks · 173.75 d of planned effort (434.25 d from scratch) · plan ends 22 Feb 2027
| Phase | Effort | Start | End |
|---|---|---|---|
| P0 — Foundations (cadrage, UX/UI, architecture & contract) | 36.25 d | 18 Oct 2026 | 16 Nov 2026 |
| P1 — V1 build & integration | 73 d | 08 Nov 2026 | 27 Dec 2026 |
| P2 — Acceptance, go-live & pilot | 27.5 d | 23 Dec 2026 | 14 Jan 2027 |
| P3 — Generalisation (after the 3 months) | 10.5 d | 14 Jan 2027 | 24 Jan 2027 |
| P4 — V2 evolutions | 26.5 d | 21 Jan 2027 | 22 Feb 2027 |
Load per person
| Person | Role | Effort | Tasks | Window | Owns |
|---|---|---|---|---|---|
| Anis | Full-stack developer · 1 FTE | 60.75 d | 39 | 18 Oct 2026 → 18 Feb 2027 | Server (API), back-office dashboard, reseller web app, docs, DevOps |
| Imad | Mobile developer (Flutter) · 1 FTE | 69.75 d | 44 | 18 Oct 2026 → 31 Jan 2027 | Reseller app and delegate app (Flutter monorepo) |
| Akram | UI/UX designer · 1 FTE | 43.25 d | 36 | 18 Oct 2026 → 22 Feb 2027 | Design system and every interface, design QA, training and store assets |
Milestones
The milestones table checks Production go-live and Pilot starts against the end of the three-month frame.
3-month frame: design → development → deployment — deadline 17 Jan 2027.
| Date | Milestone | Target | Reached when these tasks end |
|---|---|---|---|
| 18 Oct 2026 | Cadrage validated — validation sheet signed | — | PRJ-03 |
| 18 Oct 2026 | API contract v1 published (OpenAPI + mock server) | — | SRV-03 |
| 19 Oct 2026 | Server V1 feature-complete | — | SRV-26, SRV-40 |
| 21 Oct 2026 | Design system v1 ready (tokens + components) | — | DES-04 |
| 22 Oct 2026 | Screen inventory frozen | — | DES-05 |
| 29 Oct 2026 | Reseller app designs ready for client review | — | DES-10 |
| 05 Nov 2026 | Delegate app designs ready for client review | — | DES-14 |
| 08 Nov 2026 | Mobile foundations ready | — | MOB-11 |
| 12 Nov 2026 | Back-office designs ready for client review | — | DES-19 |
| 16 Nov 2026 | Design handoff complete | — | DES-21 |
| 03 Dec 2026 | Back-office and reseller web V1 feature-complete | — | DSH-12, WEB-05, WEB-06 |
| 15 Dec 2026 | Mobile apps V1 feature-complete | — | MDA-12 |
| 22 Dec 2026 | Staging integration complete | — | MOB-14, SRV-28 |
| 28 Dec 2026 | Acceptance report (PV de recette) signed | — | QA-02 |
| 29 Dec 2026 | Production go-live | on time — 17 Jan 2027 | LCH-01 |
| 30 Dec 2026 | Pilot starts | on time — 17 Jan 2027 | LCH-02 |
| 14 Jan 2027 | Pilot go / no-go | — | LCH-03, LCH-03B |
| 21 Jan 2027 | Generalisation complete | — | LCH-05 |
| 22 Feb 2027 | V2 delivered | — | SRV-38, DSH-21, MDA-20, WEB-20, DQA-12 |
Gantt by phase
Team roles
| Person or role | Responsibilities | Decides | Back-up |
|---|---|---|---|
| Anis — full-stack developer | Server (API and worker), back-office, reseller web, the API contract, DevOps, these docs; client relationship and reporting; recette coordination; the plan | Technical architecture, sequencing, merge of contract changes, technical decisions of the register (maps, hosting option, sessions) | Imad for the API contract review; none for the server — the reason Anis's lane is the critical path |
| Imad — mobile developer | Reseller and delegate Flutter apps (hoco-mobile), their CI, store publication, offline sync client, mobile support during the pilot | Mobile architecture and libraries, background location approach (D-24) | Anis for API-side questions |
| Akram — UI/UX designer | Design system and every interface, client design reviews, design QA, notification copy, document templates, store assets, training material, the scripted functional test campaign, pilot UX observation | Visual and interaction design within the specification | — |
| HOCO sponsor (signatory of the cahier's validation sheet) | Approves scope, the three-month commitment (D-38) and the acceptance report | Go/no-go, scope trade-offs | Named at the cadrage |
| HOCO project referent | Brings answers to the decision register, coordinates HOCO's testers and data owners, attends the Thursday review | Business rules within the delegation given by the sponsor | Named at the cadrage |
| HOCO key users (commercial admin, stock, finance, delivery, support, two pilot delegates, a few pilot resellers) | Execute the recette, take part in training, become champions | — | — |
| HOCO data owners | Supply and validate the import data (D-31) | Data quality sign-off | — |
| HOCO IT / account owner | Creates and owns the Play Console, Firebase, billing, domain and provider accounts (D-25) | — | — |
| HOCO counsel and accountant | Privacy, retention and invoicing rules (D-11, D-21) | Legal and fiscal answers | — |
RACI
R responsible (does the work) · A accountable (one per row, answers for the result) · C consulted · I informed.
| Area | Activity | Anis | Imad | Akram | HOCO |
|---|---|---|---|---|---|
| Server | API contract (packages/contracts, OpenAPI, mock server) | A, R | C (first consumer, reviews) | I | I |
| Server | Modules, business rules, database and migrations | A, R | I | I | C (rules) |
| Server | Notifications, real-time streams, integrations adapters | A, R | C | C (copy) | I |
| Back-office | Pages, permissions in the UI, dashboards and exports | A, R | I | C (design QA) | C (reviews) |
| Reseller web | All screens, guest mode, invitation landing | A, R | I | C (design QA) | C |
| Mobile apps | Reseller and delegate apps, offline sync client, location, push | C (integration) | A, R | C (design QA) | I |
| Mobile apps | Store publication (Play; App Store if decided) | I | A, R | C (store assets) | C (account owner, approves listing) |
| Design | Design system, screens, prototypes, client review rounds | C | C | A, R | C (validates designs) |
| Design | Notification copy, document templates, store assets, training material | C | I | A, R | C |
| QA | Design QA of every build | I (fixes) | I (fixes) | A, R | — |
| QA | Scripted functional campaign on staging (QA-03) | A | C | R | — |
| QA | End-to-end tests on staging (QA-01) | A, R | R | R | — |
| QA | Client acceptance execution and decision (PV) (QA-02) | R (organises, fixes) | R (fixes) | C | A, R (executes, signs) |
| Client relationship | Cadrage, decision register, Thursday review, progress reporting, change requests | A, R | C | C | C (decides) |
| DevOps | CI/CD, environments, domains, secrets, backups, monitoring | A, R | R (mobile CI) | — | I (accounts, DNS access) |
| DevOps | Production go-live and initial import (LCH-01) | A, R | R (apps) | I | R (data, reconciliation sign-off) |
| Operations | Training (LCH-02) | A, R | C | R (materials, field) | R (participants, champions) |
| Operations | Pilot support and triage | A, R | R | R (UX observation) | R (pilot users, daily confirmation of orders) |
| Compliance | Privacy, retention, consent texts (Law 18-07) | R (technical measures) | R (consent flow) | C (wording) | A (data controller) |
| Docs | This site, specifications, plan, runbooks | A, R | R (mobile pages) | R (design pages) | I |
Estimating rule
Every task carries two estimates in person-days of focused work (planning method):
| Estimate | Meaning |
|---|---|
| Classic | From scratch, without the team's reusable code and without AI assistance — kept for comparison only |
| Optimized | This team: reusing what it already built (UI-kit patterns, RBAC, queues, storage, PDF, email and notification modules, CI and Docker recipes) with AI-assisted development — the only number the scheduler uses |
At the plan of 18 October 2026 the open tasks total 199.5 optimized person-days against 556.25 classic (live figures in the summary above). What barely moves between the two columns is what has no precedent: the offline-first delegate app, GPS and tour logic, client workshops, the recette and the pilot, and the design work, priced at Akram's own estimate. Sizes: XS ≤ 0.5 d · S ≤ 1.5 d · M ≤ 4 d · L ≤ 10 d.
Capacity analysis
Computed from tasks.json at the plan of 18 October 2026 (open tasks, optimized person-days, first person of the team owns the lane). The live versions are the summaries and Gantt above; re-run pnpm --filter @hoco/docs schedule after any plan change.
| Person | P0 | P1 | P2 | P3 | P4 | Total | Classic |
|---|---|---|---|---|---|---|---|
| Anis | 11.5 | 37 | 15.5 | 4.5 | 20.5 | 89 | 308 |
| Imad | 13.75 | 34 | 10 | 6 | 4.5 | 68.25 | 187 |
| Akram | 21 | 17.75 | 2 | 0 | 1.5 | 42.25 | 61.25 |
| Total | 46.25 | 88.75 | 27.5 | 10.5 | 26.5 | 199.5 | 556.25 |
The frame. The three months hold 64 working days (Sunday–Thursday, holidays removed). The V1 work inside them (P0 to P2) is:
| Person | V1 load (P0–P2) | Of which the pilot | Idle working days in the lane before the pilot | Reading |
|---|---|---|---|---|
| Anis | 64 d | 10 d (on call, LCH-03) | About 3, waiting for the functional campaign before the end-to-end tests | No slack: the lane fills the frame |
| Imad | 57.75 d | 10 d (LCH-03B) | About 8, at the year end between the accessibility pass (MOB-17) and the pilot | Buffer, partly used by recette support (co-responsible on QA-01, QA-02 and LCH-01, which do not consume his lane) |
| Akram | 40.75 d | 2 d (DQA-08) | About 5 + 3 + 3 in December between design-QA rounds, and about 8 at the year end | Buffers in December and January; V2 designs (DES-30, 6 d) sit in P1 and could move later if testing needs the time |
Co-responsibilities are not in the lanes (a task belongs to the first person of its team): Anis also contributes to staging integration (MOB-12), training material (DQA-06) and notification copy (DQA-10), so his real load is above the lane figure.
Why Anis's lane is the critical path. Inside P1 it holds 19.75 d of server modules, 13.5 d of back-office pages and 3.75 d of reseller web, in that order, then hardening (SRV-28). Every milestone from Server V1 feature-complete to Pilot go / no-go is reached when a task of his lane — or a task waiting on it — ends: the back-office starts after the server modules, the reseller web after the back-office, Akram's design QA and functional campaign after both, the end-to-end tests after the campaign, then acceptance, go-live, training and the pilot. The mobile lane reaches Mobile apps V1 feature-complete earlier and waits for the server only at staging integration; the design lane is ahead by construction (design first). A delay of a day in Anis's lane is a day on go-live unless a lever is used.
Two weak points the analysis shows:
- The test chain is sequential at the end of P1. The functional campaign (QA-03) waits for the design QA of the back-office and of the reseller web, which wait for the last back-office and web tasks; the end-to-end tests wait for the campaign. Running the campaign incrementally — the mobile part right after staging integration, the back-office part after its design QA, only the web part at the end — recovers most of the idle days in Anis's lane.
- The recette is short and falls at the year end. HOCO's acceptance (QA-02) is planned as two days with the PV signed the day before go-live; it only works if HOCO's testers are booked early, trained on the scripts and work in parallel by role (acceptance procedure).
Levers
The plan does not invent capacity. The levers are those of the timeline, applied to this team:
| Lever | Effect on the frame | Decision |
|---|---|---|
| Spend the visible buffers (Imad at the year end, Akram in December) and run the functional campaign incrementally | Recovers the idle days before the end-to-end tests without scope change | Team |
| Move non-essential V1 scope after go-live, in the agreed order (some reports, the import wizard — data imported by script for the pilot —, inventory sessions, announcements…) | Each item removed from Anis's lane brings go-live earlier by its effort | D-38 |
| Reseller web timing | The reseller web is in V1 and sits on Anis's lane (3.75 d) just before hardening; moving it after go-live is the largest single scope lever but reverses the decision that it ships in V1 | HOCO with the team |
| iOS | Not on the critical path: MOB-16 is planned in generalisation; deciding "no" frees 3 days of Imad's P3; deciding "yes" late only moves the iOS release | D-10 |
| Shorten the pilot to one week | Generalisation starts a week earlier; fewer data points for the go/no-go | D-32 |
| A second TypeScript developer on the back-office | The 13.5 d of back-office pages run in parallel with the server modules, against the contract and the mock server; net gain lower than 13.5 d (onboarding, reviews, server endpoints still needed), and only if decided early in P1 | HOCO (budget) and the team |
| Pilot timing versus Ramadan | No longer a constraint: the pilot ends before Ramadan. A date slip of about three weeks would bring the pilot into Ramadan — one more reason to prefer scope moves over date moves | D-38 |
| Adding V1 scope (packs, Arabic interface, quantity tiers…) | Breaks the frame unless an equivalent effort moves out | D-16, D-09, D-37 |
A slip is handled the same week it is seen — at the Thursday review, as a changed effort, dependency or scope in tasks.json — never absorbed silently at the end (progress).
Hardening report
SRV-28 findings — permission, scope and exposure sweeps, security headers, rate limits, dependency and secret scan, upload checks, slow-query pass, restore drill and load-test kit — each with severity, status and evidence.
Decision register
Every open decision with its question, source, options and consequences, recommendation, owner, the plan task that needs the answer, the default applied if no answer comes, and its status.