MVP Development Backlog
This is the working backlog for the MVP (Kuwait launch). Every epic maps to exactly one of the 12 domains; stories carry requirement-ID prefixes matching the SRS modules. Story points use the Fibonacci scale (1, 2, 3, 5, 8, 13). Priorities: P0 = launch blocker, P1 = should ship at launch, P2 = can follow within 30 days of launch.
Team assumed: 2 backend, 1 web (Next.js), 1 mobile (Flutter), 1 designer, 1 QA — 2-week sprints, indicative sustained velocity ≈ 35–40 pts/sprint after Sprint 2.
Epic index
| Epic |
Domain |
Req. prefix |
Points |
Priority |
| E1 Platform foundation |
11 Platform |
— |
34 |
P0 |
| E2 Identity & authentication |
1 Identity |
AUTH |
42 |
P0 |
| E3 Vendor onboarding & approval |
4 Vendor / 10 Operations |
VOS |
34 |
P0 |
| E4 Vendor subscriptions & billing |
6 Financial |
VOS, PAY |
39 |
P0 |
| E5 Vendor profile, catalog & gallery |
4 Vendor |
LST |
31 |
P0 |
| E6 Marketplace discovery & search |
3 Marketplace |
MKT |
29 |
P0 |
| E7 Customer events |
2 Event |
EVT |
21 |
P0 |
| E8 RFQ & quotations |
5 Booking |
RFQ |
47 |
P0 |
| E9 Messaging |
7 Communication |
MSG |
29 |
P0 |
| E10 Booking & deposit payment |
5 Booking / 6 Financial |
BKG, PAY |
52 |
P0 |
| E11 Reviews & ratings |
8 Experience |
REV |
18 |
P1 |
| E12 Notification engine |
7 Communication |
MSG |
21 |
P0 |
| E13 Dashboards (customer / vendor / admin) |
2 / 4 / 10 |
ADM |
26 |
P1 |
| E14 Admin console, CMS & audit |
10 Operations / 11 Platform |
ADM |
26 |
P1 |
| E15 Launch hardening |
11 Platform |
— |
21 |
P0 |
Total ≈ 470 points → ~12 sprints (~6 months) with buffer.
E1 — Platform foundation (Domain 11)
| # |
Story |
Pts |
Pri |
Depends on |
| E1.1 |
As a developer, I want the Laravel 11 modular-monolith skeleton with one module per domain, so that boundaries are enforced from day one. |
8 |
P0 |
— |
| E1.2 |
As a developer, I want Docker Compose + GitHub Actions CI (lint, Pest, build) with staging auto-deploy, so that every merge is verifiable. |
8 |
P0 |
E1.1 |
| E1.3 |
As a developer, I want a shared file-upload service (S3-compatible, image thumbnails, PDF/virus scanning), so that gallery, license and chat uploads reuse one path. |
5 |
P0 |
E1.1 |
| E1.4 |
As a developer, I want the localization layer (ar/en resource bundles, RTL-aware API strings, Accept-Language), so that every feature ships bilingual. |
5 |
P0 |
E1.1 |
| E1.5 |
As an admin, I want audit logging of sensitive actions (approvals, refunds, plan changes), so that every decision is traceable. |
5 |
P0 |
E1.1 |
| E1.6 |
As a developer, I want a money value object storing KWD minor units with 3 decimal places, so that no float rounding errors reach an invoice. |
3 |
P0 |
E1.1 |
E1.6 acceptance criteria
- Given an amount of
KWD 12.3456, When it is persisted, Then it is rejected by validation (max 3 dp) — amounts are stored as integer fils (1 KWD = 1000 fils).
- Given a subscription price of
KWD 15.000 with 5% discount, When the total is computed, Then rounding is half-up at the 3rd decimal and the stored value equals the value displayed and the value sent to the PSP.
E2 — Identity & authentication (Domain 1, AUTH)
| # |
Story |
Pts |
Pri |
Depends on |
| E2.1 |
As a customer, I want to register/login with email + password including verification, so that I own a secure account. |
5 |
P0 |
E1 |
| E2.2 |
As a customer, I want to log in with a Kuwait phone number and SMS OTP, so that I can join without a password. |
8 |
P0 |
E1 |
| E2.3 |
As a customer, I want Google and Apple sign-in, so that onboarding takes seconds. |
5 |
P0 |
E2.1 |
| E2.4 |
As a user, I want password reset and phone/email change with re-verification, so that account recovery is safe. |
5 |
P0 |
E2.1 |
| E2.5 |
As a user, I want profile management (name, avatar, language preference), so that my experience is personalized. |
3 |
P0 |
E2.1 |
| E2.6 |
As the platform, I want role/permission scaffolding (Customer, Vendor owner, Vendor team member, Admin roles), so that every endpoint is authorized. |
8 |
P0 |
E1.1 |
| E2.7 |
As a mobile user, I want biometric unlock after first login, so that re-entry is fast. |
3 |
P1 |
E2.2 |
| E2.8 |
As the platform, I want rate limiting + lockout on OTP and login endpoints, so that credential and OTP abuse is blocked. |
5 |
P0 |
E2.2 |
E2.2 acceptance criteria
- Given a valid
+965 number, When I request an OTP, Then a 6-digit code valid for 5 minutes is sent and at most 3 sends per 15 minutes are allowed.
- Given an expired or 5-times-wrong OTP, When I submit it, Then login fails with a localized error and the code is invalidated.
- Given a new phone number, When OTP verifies, Then an account is created and I land on the profile-completion step.
E3 — Vendor onboarding & approval (Domain 4/10, VOS)
| # |
Story |
Pts |
Pri |
Depends on |
| E3.1 |
As a business owner, I want to register as a vendor with business details (legal name AR/EN, category, contact), so that I can join the marketplace. |
5 |
P0 |
E2 |
| E3.2 |
As a vendor, I want to upload my Kuwait commercial license (PDF/image) and authorized-signatory details, so that Yam3at can verify my business. |
5 |
P0 |
E1.3, E3.1 |
| E3.3 |
As an admin, I want an approval queue with approve / reject-with-reason / request-changes, so that only verified vendors go live. |
8 |
P0 |
E3.2 |
| E3.4 |
As a vendor, I want to see my application status and resubmit corrections, so that I am never stuck. |
5 |
P0 |
E3.3 |
| E3.5 |
As a vendor, I want to invite team members with limited roles, so that staff can answer RFQs without owner credentials. |
8 |
P1 |
E2.6, E3.3 |
| E3.6 |
As the platform, I want license-expiry tracking with reminders and auto-suspension, so that no vendor operates on an expired license. |
3 |
P1 |
E3.3 |
E3.3 acceptance criteria
- Given a submitted application, When an admin approves it, Then vendor status becomes
Approved, the vendor is notified (email + push), the profile becomes editable-but-unpublished, and the action is audit-logged with admin ID.
- Given a rejection, When the admin submits it, Then a reason code + free text is mandatory and the vendor sees it verbatim in-app.
- See the operational checklist in the Operations Handbook.
E4 — Vendor subscriptions & billing (Domain 6, VOS/PAY)
| # |
Story |
Pts |
Pri |
Depends on |
| E4.1 |
As the platform, I want the payment-provider abstraction (MyFatoorah/Tap adapter, hosted checkout, webhooks), so that KNET, Visa/Mastercard, Apple Pay and Google Pay work behind one interface. |
13 |
P0 |
E1 |
| E4.2 |
As a vendor, I want to pick Free / Basic / Professional / Enterprise and pay in KWD, so that I unlock plan features. |
8 |
P0 |
E4.1, E3.3 |
| E4.3 |
As the platform, I want plan-limit enforcement (quotations/month, gallery size, team seats, featured slots), so that entitlements match the paid plan. |
8 |
P0 |
E4.2 |
| E4.4 |
As a vendor, I want auto-renewal with pre-renewal notice, invoices (PDF, AR/EN), and payment history, so that billing is transparent. |
5 |
P0 |
E4.2 |
| E4.5 |
As the platform, I want idempotent webhook processing with signature verification and retry tolerance, so that a duplicate PSP callback never double-activates or double-charges. |
5 |
P0 |
E4.1 |
E4.3 acceptance criteria
- Given a Basic vendor at their monthly quotation limit, When a new RFQ arrives, Then they can view it but the "Send quote" action shows an upgrade prompt instead of the quote form.
- Given an upgrade mid-cycle, When payment succeeds, Then new limits apply immediately and unused value is pro-rated per the pricing rules.
- Given a downgrade, When the current period ends, Then the lower limits apply from the next cycle only.
E5 — Vendor profile, catalog & gallery (Domain 4, LST)
| # |
Story |
Pts |
Pri |
Depends on |
| E5.1 |
As a vendor, I want a bilingual public profile (description AR/EN, areas served, working hours, location/Google Maps pin, policies), so that customers can evaluate me. |
8 |
P0 |
E3.3 |
| E5.2 |
As a vendor, I want to manage a service/package catalog (name, description, price-from in KWD, unit), so that customers see concrete offerings. |
8 |
P0 |
E5.1 |
| E5.3 |
As a vendor, I want a photo/video gallery with ordering and a cover image, so that my work sells itself. |
5 |
P0 |
E1.3, E5.1 |
| E5.4 |
As a vendor, I want to publish/unpublish my profile with a completeness meter, so that I control when I appear in search. |
5 |
P0 |
E5.1 |
| E5.5 |
As an admin, I want profile-content moderation flags, so that off-platform contact details or prohibited content are caught. |
5 |
P1 |
E5.4, E14 |
E6 — Marketplace discovery & search (Domain 3, MKT)
| # |
Story |
Pts |
Pri |
Depends on |
| E6.1 |
As the platform, I want the category taxonomy (venues, catering, photography, decoration, entertainment, …) seeded bilingually, so that browsing has structure. |
3 |
P0 |
E1 |
| E6.2 |
As a customer, I want category browsing and a Meilisearch-backed search with typo tolerance in Arabic and English, so that I find vendors fast. |
8 |
P0 |
E6.1, E5.4 |
| E6.3 |
As a customer, I want filters (governorate/area, price range, rating, category) and sorting (relevance, rating, price), so that I can narrow options. |
8 |
P0 |
E6.2 |
| E6.4 |
As the platform, I want featured-vendor placement driven by plan tier, so that Professional/Enterprise subscribers get visibility value. |
5 |
P0 |
E4.3, E6.2 |
| E6.5 |
As a customer, I want vendor detail pages with gallery, catalog, reviews and "Request quote" CTA, so that discovery converts. |
5 |
P0 |
E5, E6.2 |
E7 — Customer events (Domain 2, EVT)
| # |
Story |
Pts |
Pri |
Depends on |
| E7.1 |
As a customer, I want to create an Event (type, date, governorate/area, guest count, budget in KWD, notes), so that everything I do hangs off it. |
8 |
P0 |
E2 |
| E7.2 |
As a customer, I want an event workspace showing its RFQs, quotes, bookings, payments and messages, so that one screen holds the whole event. |
8 |
P0 |
E7.1, E8, E10 |
| E7.3 |
As a customer, I want to edit/cancel an event with clear impact warnings on open RFQs and bookings, so that changes are safe. |
5 |
P0 |
E7.1 |
E8 — RFQ & quotations (Domain 5, RFQ)
| # |
Story |
Pts |
Pri |
Depends on |
| E8.1 |
As a customer, I want to build an RFQ (service needs, budget, date, attachments) from an event and send it to up to N selected vendors, so that I collect comparable offers. |
13 |
P0 |
E7.1, E6 |
| E8.2 |
As a vendor, I want an RFQ inbox with quote composer (price KWD 3dp, line items, validity date, notes, attachments), so that I can respond professionally. |
8 |
P0 |
E8.1, E4.3 |
| E8.3 |
As the platform, I want the full RFQ state machine (Draft, Pending, Quoted, Negotiating, Accepted, Rejected, Expired, Cancelled) with guarded transitions, so that state is always consistent. |
8 |
P0 |
E8.1 |
| E8.4 |
As a customer, I want a side-by-side quote comparison table per RFQ, so that choosing is easy. |
5 |
P0 |
E8.2 |
| E8.5 |
As a customer or vendor, I want negotiation (counter-message moves quote to Negotiating; vendor can revise), so that price talks stay on-platform. |
8 |
P0 |
E8.3, E9 |
| E8.6 |
As the platform, I want automatic expiry of quotes past their validity date with notifications, so that stale offers never get accepted. |
5 |
P0 |
E8.3, E12 |
E8.3 acceptance criteria
- Given an RFQ in
Pending, When a vendor submits a quote, Then that vendor's thread becomes Quoted while other vendors' threads stay Pending.
- Given a quote in
Quoted or Negotiating, When the customer accepts it, Then it becomes Accepted, all sibling quotes become Rejected with reason another_quote_accepted, and a draft booking is created.
- Given any terminal state (
Accepted, Rejected, Expired, Cancelled), When any actor attempts a further transition, Then the API returns 409 with a state-machine error body.
E9 — Messaging (Domain 7, MSG)
| # |
Story |
Pts |
Pri |
Depends on |
| E9.1 |
As a customer/vendor, I want per-RFQ and per-booking chat threads (text, images, PDF), so that context never scatters. |
13 |
P0 |
E8.1 |
| E9.2 |
As a user, I want read receipts and unread badges, so that I know where I stand. |
5 |
P0 |
E9.1 |
| E9.3 |
As the platform, I want attachment limits (10 MB, jpg/png/webp/pdf) and content filtering for phone numbers/links pre-booking, so that leakage off-platform is discouraged. |
5 |
P1 |
E9.1 |
| E9.4 |
As an admin, I want to view reported threads, so that disputes have evidence. |
3 |
P1 |
E9.1, E14 |
| E9.5 |
As a mobile user, I want push-delivered messages that deep-link into the thread, so that replies are instant. |
3 |
P0 |
E9.1, E12 |
E10 — Booking & deposit payment (Domains 5/6, BKG/PAY)
| # |
Story |
Pts |
Pri |
Depends on |
| E10.1 |
As a customer, I want an accepted quote to become a booking with deposit amount, event date and terms, so that commitment is formal. |
8 |
P0 |
E8.3 |
| E10.2 |
As a customer, I want to pay the deposit via KNET/card/Apple Pay/Google Pay, so that the booking confirms. |
8 |
P0 |
E4.1, E10.1 |
| E10.3 |
As the platform, I want the booking state machine (Pending, Confirmed, Completed, Cancelled, Refund Requested) with role-guarded transitions, so that lifecycle is unambiguous. |
8 |
P0 |
E10.1 |
| E10.4 |
As a customer, I want to request a refund with a reason, so that disputes enter the resolution flow. |
5 |
P0 |
E10.3 |
| E10.5 |
As an admin, I want to process refunds through the PSP (full/partial, KWD 3dp), so that money movements are controlled and logged. |
5 |
P0 |
E10.4, E4.5 |
| E10.6 |
As the platform, I want bookings auto-marked Completed N days after the event date (unless disputed), so that reviews unlock reliably. |
5 |
P0 |
E10.3 |
| E10.7 |
As the platform, I want to capture a 5% commission from the paid deposit when a booking is confirmed (configurable rate, KWD 3dp), so that transaction revenue is collected from launch without a separate vendor charge. |
5 |
P0 |
E10.2, E10.3 |
| E10.8 |
As a vendor, I want my share of the deposit (deposit − commission) settled to my payout account with a downloadable statement (AR/EN, KWD 3dp), so that I trust how Yam3at handles my money. |
8 |
P1 |
E10.7 |
E10.2 acceptance criteria
- Given a booking in
Pending, When the PSP webhook confirms payment (idempotency key = payment intent ID), Then the booking becomes Confirmed exactly once, both parties are notified, and a receipt with 3-decimal KWD amounts is issued.
- Given a failed or abandoned checkout, When the customer returns, Then the booking remains
Pending with a retry CTA and no partial state.
E10.7 / E10.8 acceptance criteria
- Given a confirmed booking with total
KWD 100.000 and a 20% deposit, When confirmation completes, Then a commission of KWD 5.000 is recorded and a vendor settlement of KWD 15.000 is scheduled (all 3-dp KWD), per the commission model.
- Given a deposit refund on that booking, When the refund is processed, Then the commission and settlement reverse via new ledger entries (no edits) and the vendor statement reflects the reversal.
- Given a booking still in the refund-request window, When settlement runs, Then the vendor share stays
frozen until Operations resolves the dispute.
E11 — Reviews & ratings (Domain 8, REV)
| # |
Story |
Pts |
Pri |
Depends on |
| E11.1 |
As a customer, I want to review (1–5 stars + text + photos) only vendors from my Completed bookings, so that reviews are verified. |
8 |
P1 |
E10.6 |
| E11.2 |
As a vendor, I want to reply once per review, so that my side is heard. |
3 |
P1 |
E11.1 |
| E11.3 |
As the platform, I want aggregate ratings on profiles and search ranking input, so that quality is visible. |
3 |
P1 |
E11.1, E6.2 |
| E11.4 |
As an admin, I want a review moderation queue (reports, profanity filter), so that content stays clean. |
4 |
P1 |
E11.1, E14 |
E12 — Notification engine (Domain 7)
| # |
Story |
Pts |
Pri |
Depends on |
| E12.1 |
As the platform, I want a single notification service (templates AR/EN, channels: FCM push + email via Mailgun/SES, per-user preferences), so that no feature builds its own sender. |
8 |
P0 |
E1 |
| E12.2 |
As a user, I want notifications for RFQ received, quote received, message, booking status, payment result, subscription renewal, review received, so that nothing is missed. |
8 |
P0 |
E12.1 |
| E12.3 |
As a user, I want an in-app notification center with read state, so that history survives dismissed pushes. |
5 |
P0 |
E12.1 |
E13 — Dashboards (Domains 2/4/10)
| # |
Story |
Pts |
Pri |
Depends on |
| E13.1 |
As a customer, I want a dashboard (events, active RFQs, bookings, payments, favorites), so that my activity is one tap away. |
8 |
P1 |
E7, E8, E10 |
| E13.2 |
As a vendor, I want a dashboard (new RFQs, quote win rate, bookings, subscription status, basic analytics per plan tier), so that I run my business here. |
8 |
P1 |
E8, E4.3 |
| E13.3 |
As an admin, I want a KPI overview (registrations, approvals pending, MRR, RFQ→booking conversion), so that platform health is visible. |
10 |
P1 |
E14 |
E14 — Admin console, CMS & audit (Domains 10/11, ADM)
| # |
Story |
Pts |
Pri |
Depends on |
| E14.1 |
As an admin, I want user & vendor management (search, suspend, impersonate-readonly), so that support can act. |
8 |
P1 |
E2.6 |
| E14.2 |
As an admin, I want plan/pricing management, so that subscription changes need no deploy. |
5 |
P1 |
E4.2 |
| E14.3 |
As an admin, I want CMS pages (About, Terms, Privacy, FAQ — AR/EN), so that legal/static content is editable. |
5 |
P1 |
E1.4 |
| E14.4 |
As an admin, I want the audit-log viewer with filters, so that investigations are fast. |
3 |
P1 |
E1.5 |
| E14.5 |
As an admin, I want moderation queues unified (profiles, reviews, reported messages), so that ops works one list. |
5 |
P1 |
E5.5, E9.4, E11.4 |
E15 — Launch hardening (Domain 11)
| # |
Story |
Pts |
Pri |
Depends on |
| E15.1 |
As the platform, I want load testing to the targets in the QA Plan, so that launch-day traffic is safe. |
5 |
P0 |
all P0 epics |
| E15.2 |
As the platform, I want a security pass (OWASP ZAP scan, dependency audit, pen-test fixes), so that PII and payments are protected. |
8 |
P0 |
all P0 epics |
| E15.3 |
As the platform, I want monitoring/alerting (Sentry, uptime, queue depth, webhook failure alarms) and runbooks, so that ops can respond per the incident process. |
5 |
P0 |
E1.2 |
| E15.4 |
As the platform, I want production data backups + restore drill, so that recovery is proven, not assumed. |
3 |
P0 |
E1.2 |
Suggested sprint sequencing
Two-week sprints. Backend pair front-loads platform/payments; web and mobile track one epic behind backend; designer works one sprint ahead; QA embeds from Sprint 1.
| Sprint |
Backend focus |
Web focus |
Mobile focus |
Milestone |
| 1 |
E1.1–E1.6 |
Design system + Next.js/RTL shell |
Flutter shell, theming, l10n |
CI green, money object done |
| 2 |
E2.1–E2.4, E2.6, E2.8 |
Auth screens |
Auth + OTP screens |
M1: login works end-to-end |
| 3 |
E3.1–E3.4, E12.1 |
Vendor registration wizard |
Customer onboarding |
Vendor applications flow |
| 4 |
E4.1, E4.5 |
Admin approval queue (E3.3 UI) |
Profile management |
PSP sandbox integrated |
| 5 |
E4.2–E4.4, E5.1–E5.2 |
Subscription checkout + vendor profile editor |
Vendor app: profile/catalog |
M2: vendor can pay & publish |
| 6 |
E5.3–E5.4, E6.1–E6.3 |
Search & category pages |
Search & vendor detail |
Discovery works |
| 7 |
E7.1–E7.3, E8.1–E8.3 |
Event workspace, RFQ wizard |
Event + RFQ flows |
RFQ round-trip in staging |
| 8 |
E8.4–E8.6, E9.1–E9.2 |
Quote compare, chat UI |
Chat, quote inbox (vendor) |
M3: quote→accept path complete |
| 9 |
E10.1–E10.3, E12.2 |
Booking + deposit checkout |
Booking + payment sheet |
Deposit payment live in sandbox |
| 10 |
E10.4–E10.8, E11.1–E11.3, E9.3–E9.5 |
Reviews, refund request UI, settlement statements |
Reviews, notifications center |
Full lifecycle demo (incl. commission + settlement) |
| 11 |
E13, E14 |
Admin console, CMS, dashboards |
Dashboard polish, E2.7 |
M4: feature-complete freeze |
| 12 |
E15 + bug backlog |
Bug fixes, Lighthouse/RTL audit |
Store submission builds |
M5: launch-ready |
Buffer
Sprint 12 is deliberately light on features. Store review (Apple/Google) and PSP production-account approval (MyFatoorah/Tap merchant onboarding, KNET activation) must start by Sprint 9 — both have multi-week external lead times.
Definition of Done (every story)
What "MVP launch ready" means
All of the following, verified in the release go/no-go review:
- Full happy path in production: register → vendor approved → vendor subscribed (real KNET charge) → profile published → customer creates event → RFQ to 3 vendors → quotes compared → accepted → deposit paid → booking confirmed → completed → review posted.
- All P0 stories done; P1 either done or explicitly waived by the founder with a dated note.
- Payments proven: production KNET + card charge, refund, and webhook replay tested with real (small) amounts; reconciliation report matches PSP dashboard to the fils.
- Supply seeded: approved-vendor minimum met per the Marketing Playbook (100+ approved vendors across priority categories).
- Quality gates: zero open Critical/High bugs; load and security criteria in the QA Plan passed; RTL audit signed off by the designer.
- Apps approved and released (phased rollout) on the App Store and Google Play; web live on the production domain with AR/EN.
- Operations live: support inbox staffed, vendor approval SOP in use, on-call rotation and rollback procedure documented and rehearsed.
- Legal: Terms, Privacy (AR/EN) published via CMS; PSP and data-protection requirements met.