# Navi CEO Technology Platform Deck - Slide Notes

Generated from repo context on 2026-05-05.

This companion document provides the requested slide-by-slide objective, main content, suggested visual or diagram, speaker notes, and CEO takeaway.

## Slide 1: Technology Vision, Platform Readiness, and Launch Plan
**Slide objective:** Position Navi as a serious UAE tourism technology platform and explain the CTO execution path.

**Main slide content:**
- Navi is a multi-sided travel marketplace, not a single mobile app.
- The architecture separates mobile, website, dashboard, and API so each can scale independently.
- Phase One has strong foundations and clear production blockers that must be handled before real launch.
- This deck turns product ambition into the operating model, team structure, roadmap, risks, and CEO decisions needed.

**Suggested visual or diagram:** cover

**Speaker notes:** Open by making it clear that Navi is being framed as a platform company. The deck is not a UI demo; it is the technology operating plan that lets the CEO understand product ambition, readiness, budget, team, governance, and risks.

**CEO takeaway:** Navi can credibly become a UAE travel platform, but only if we treat it as a connected marketplace with disciplined delivery and production controls.

## Slide 2: Navi Is a Marketplace Platform, Not Just a Travel App
**Slide objective:** Set the top-level message for CEO and investors.

**Main slide content:**
- The product vision is a UAE travel companion that helps tourists discover, plan, book, order, translate, move, and get help.
- The platform connects tourists, premium users, partners, drivers, support agents, admins, and Super Admin operations through one API and data core.
- The current codebase has meaningful foundation work: monorepo separation, shared packages, API/RBAC patterns, seed content, mobile reference screens, QA/store-readiness reports.
- The launch blockers are not design ambition; they are production readiness: real payments, partner onboarding, provider operations, secure uploads, role/data-scope enforcement, store credentials, live hosting, and operational QA.
- The CTO recommendation is to finish Phase One foundations before adding more features, then move into marketplace and commercial expansion.

**Suggested visual or diagram:** summary

**Speaker notes:** The point of this slide is to be direct: the vision is strong and the foundation is real, but there are still serious launch blockers. This gives the CEO confidence because we are not pretending.

**CEO takeaway:** The right CEO decision is to fund a launch-blocker wave, not to keep adding disconnected features.

## Slide 3: What Leadership Should Believe After This Deck
**Slide objective:** Make the target belief explicit.

**Main slide content:**
- Navi can compete in travel services by becoming the operating layer between tourists and UAE service providers.
- The moat is not only app design; it is trusted booking, partner quality, payment/refund reliability, data visibility, Arabic/English readiness, and operational control.
- The CTO role is to protect platform integrity while moving fast: architecture separation, API contracts, security, delivery rhythm, and team accountability.
- The next three months should focus on “real journeys”: register, discover, save, book/order, pay/refund, partner fulfills, dashboard reflects, audit logs prove it.
- Investor confidence comes from traceable execution evidence: tests, dashboards, data records, release runbooks, observability, and honest risk control.

**Suggested visual or diagram:** thesis

**Speaker notes:** Use this as the executive anchor. Navi is attractive only when it proves the loop from customer action to provider operations and admin visibility.

**CEO takeaway:** The CEO should judge progress by completed platform loops, not by the number of screens.

## Slide 4: Navi Product Vision: One UAE Travel Companion
**Slide objective:** Explain what Navi becomes for tourists and partners.

**Main slide content:**
- For tourists: Navi reduces uncertainty across arrival, discovery, transport, services, safety, and language.
- For partners: Navi becomes a demand channel and operating dashboard.
- For admins: Navi provides operational visibility, content control, user management, auditability, and revenue reporting.

**Flow nodes:**
- Open: Splash and onboarding
- Discover: UAE places and services
- Plan: AI itinerary and saved trips
- Book / Order: stays, activities, taxi, food, SIM
- Support: translator, emergency, help
- Return: profile, rewards, premium

**Suggested visual or diagram:** flow

**Speaker notes:** Tell the CEO that the product vision is simple but broad: every tourist need in the UAE can be routed through Navi, while every provider can be operationally managed.

**CEO takeaway:** The platform promise is convenience for tourists and demand plus operations for partners.

## Slide 5: Comparable Ambition: Booking.com, Uber, Airbnb, Careem, GetYourGuide, Talabat
**Slide objective:** Show the ambition without pretending Navi is already at that scale.

**Main slide content:**
- Navi combines marketplace patterns across accommodation, experiences, mobility, local commerce, language assistance, and safety.
- The launch advantage is UAE-specific focus: English/Arabic, Emirates content, local payment readiness, partner operations, emergency trust, and tourism-specific workflows.
- The risk is over-expansion before operational depth. The CTO recommendation is phased expansion with category modes: marketing only, demo, sandbox, live.

**Table content:**
| Comparable pattern | What Navi borrows | What Navi must prove |
| --- | --- | --- |
| Booking.com | Stays, inventory, reviews, booking flow | Availability, pricing, refund policy, partner dashboard |
| Uber / Careem | Taxi flow, driver assignment, live status | Dispatch partner integration and driver scoping |
| Airbnb / GetYourGuide | Experiences and trip discovery | Quality control, cancellation, reviews |
| Talabat | Food/grocery/pharmacy order operations | Menus, inventory, delivery status, provider SLAs |
| Travel assistant apps | AI planning, translator, emergency | Accuracy, privacy, cost control, support escalation |

**Suggested visual or diagram:** matrix

**Speaker notes:** This is not a claim that Navi is equal to these companies today. It is a framing of business architecture patterns and the requirements to earn that ambition.

**CEO takeaway:** Navi’s ambition is valid if execution narrows into real, reliable category loops.

## Slide 6: Business Model: Marketplace Revenue Plus Premium Services
**Slide objective:** Explain how Navi can generate revenue.

**Main slide content:**
- The highest-confidence early revenue is commission on bookings and orders once payments and provider operations are production-grade.
- Partner onboarding and content management turn Navi from demo app into commercial distribution channel.
- Premium user revenue should wait until core trust loops work.

**Table content:**
| Revenue stream | Phase One readiness | What must exist to monetize |
| --- | --- | --- |
| Booking commissions | Partial foundation | Real booking engine, partner contracts, cancellation/refund rules |
| Order commissions | Partial foundation | Order tables, provider dashboard, delivery status, settlement reporting |
| Premium subscription | Concept ready | Member badge, premium offers, priority support, AI limits |
| Partner plans | Website/dashboard path planned | Partner application, KYB, onboarding, payout setup |
| Promoted listings | Future-ready | Content moderation, analytics, reporting, ad policy |
| AI add-ons | Future-ready | Quota, cost guardrails, structured trip output |

**Suggested visual or diagram:** matrix

**Speaker notes:** Keep the financial model grounded. Commission revenue and partner onboarding depend on trust, operational readiness, payment, refunds, and reporting.

**CEO takeaway:** Revenue depends less on adding categories and more on completing booking/order/payment/provider loops.

## Slide 7: Platform Overview: Four Separate Apps Connected by Secure APIs
**Slide objective:** Show the separation rule and how data flows.

**Main slide content:**
- Mobile, website, dashboard, and API remain separate applications.
- Shared packages hold types, validators, config, design tokens, and API clients.
- Business logic belongs in the API, not in the mobile app or dashboard.
- Dashboard changes should flow through APIs into mobile/website content.

**Suggested visual or diagram:** platform

**Speaker notes:** This is a central CTO decision. It protects long-term maintainability and prevents demo UI from becoming production logic.

**CEO takeaway:** Separation is not bureaucracy; it is how Navi avoids becoming a fragile prototype.

## Slide 8: User Ecosystem: Demand, Supply, Operations, Governance
**Slide objective:** Explain all actors and their roles.

**Main slide content:**
- Guests can browse public content and emergency numbers only.
- Tourists and premium users create demand through saves, bookings, orders, trip plans, and translator usage.
- Partners and staff operate supply: listings, prices, availability, orders, bookings, and status updates.
- Admin and Super Admin roles govern quality, access, content, reporting, and audit trails.

**Flow nodes:**
- Guest
- Tourist
- Premium
- Partner Owner
- Provider Staff
- Driver
- Support Agent
- Super Admin

**Suggested visual or diagram:** ecosystem

**Speaker notes:** Make the CEO see Navi as a multi-role operating system. This prevents the company from underestimating dashboard, RBAC, and provider workflow complexity.

**CEO takeaway:** The customer app is only one face of Navi; the platform succeeds when every role has the right access and data scope.

## Slide 9: Phase One Customer Journey Must Be End-to-End
**Slide objective:** Turn the 25-screen PDF reference into a working platform journey.

**Main slide content:**
- Every CTA must either navigate, call an API, open a native action, or be clearly disabled by feature state.
- Every meaningful action should create or update backend data where applicable.
- Dashboard reflection is required for bookings, orders, content, partner actions, support, reports, and audit logs.

**Flow nodes:**
- Onboard: splash, intro, language
- Auth: register, login, guest mode
- Explore: home, discovery, search
- Save: favorites and trips
- Book / Order: stays, taxi, food, SIM
- Operate: dashboard, provider, audit

**Suggested visual or diagram:** flow

**Speaker notes:** This slide directly answers the repeated product concern: is it real or fake? The acceptance test is a full platform loop.

**CEO takeaway:** Phase One is not complete until a user action becomes backend data and the right dashboard role can see it.

## Slide 10: Mobile App Overview: Premium Tourist Experience
**Slide objective:** Summarize the mobile product surface.

**Main slide content:**
- Core screens: splash, onboarding, login/register, home, discovery, stays, hotel detail, room selection, experiences, taxi, food, pharmacy, grocery, SIM, emergency, profile, saved destinations, translator, trip planner, itinerary.
- Architecture: Expo Router, React Query, Zustand, i18next, secure token storage pattern, shared API client, reusable design components.
- Design direction: royal blue, light background, rounded cards, image-led content, clear bottom tabs, iOS-inspired interactions, English/Arabic readiness.
- Current maturity: major UI/reference screens exist and many read real API data; full checkout, provider completion, real OCR/payment/native store signing remain blockers.

**Suggested visual or diagram:** mobile

**Speaker notes:** Position the mobile app as the tourist front door. Be honest that it must continue moving from reference implementation into production-grade flows.

**CEO takeaway:** Mobile can impress in a demo, but market readiness depends on connected data, auth, checkout, and native release controls.

## Slide 11: Website Overview: Marketing, SEO, Sales, and Partner Acquisition
**Slide objective:** Explain why the website matters beyond a homepage.

**Main slide content:**
- The website should explain Navi for tourists and partners, not duplicate the mobile app blindly.
- Required pages: home, tourist landing, partner pages by category, pricing/partner plans, demo request, contact sales, help center, privacy, terms.
- SEO requirements: localized EN/AR metadata, hreflang, sitemap, JSON-LD, destination pages, partner landing pages, cookie consent.
- The website must use API or content sources where appropriate so banners, destinations, and marketing pages are manageable.

**Suggested visual or diagram:** website

**Speaker notes:** The website is a growth engine. It must be bilingual, credible, and connected to partner applications.

**CEO takeaway:** Website investment supports both customer acquisition and the B2B supply funnel.

## Slide 12: Dashboard Overview: The Operating System Behind the App
**Slide objective:** Define dashboard expectations.

**Main slide content:**
- Admin dashboard: users, roles, providers, destinations, listings, bookings, orders, payments, refunds, support, content, reports, audit logs, system settings.
- Provider dashboard: business profile, team, listings, availability, prices, bookings, orders, settlements, reports, support.
- Support dashboard: tickets, customer lookup, booking/order lookup, emergency support, notes, escalation.
- Current maturity: engagement and some API-backed pages exist; broad create/edit workflows, partner onboarding, payments/refunds, staff/driver scoping, content management remain major gaps.

**Suggested visual or diagram:** dashboard

**Speaker notes:** Make clear that a marketplace cannot run from the mobile app alone. The dashboard is where operations, quality, and money are controlled.

**CEO takeaway:** Without a real dashboard, Navi remains a demo; with it, Navi becomes an operating business.

## Slide 13: API and Backend Overview: The Source of Truth
**Slide objective:** Show backend responsibilities.

**Main slide content:**
- Backend owns business rules, not the frontend.
- Every controller should validate input through shared schemas and enforce role/data scope.
- Idempotency, audit logs, trace IDs, rate limits, and webhook verification are platform requirements, not optional polish.
- OpenAPI and typed API clients should become the contract between apps.

**Flow nodes:**
- Clients: mobile, website, dashboard
- API Gateway: NestJS + Fastify
- Guards: auth, RBAC, scope, validation
- Modules: bookings, orders, content, payments
- Data: Prisma + Postgres
- Jobs: Redis/BullMQ

**Suggested visual or diagram:** flow

**Speaker notes:** The CEO should understand that the API is where the company’s trust is encoded. It protects the business from UI shortcuts.

**CEO takeaway:** The API is the platform’s legal and operational source of truth.

## Slide 14: Infrastructure Overview: Production Needs a Managed Cloud Operating Model
**Slide objective:** Summarize target infrastructure.

**Main slide content:**
- Local and demo builds are not production infrastructure.
- Staging must mirror production enough to test payments, webhooks, emails, mobile API, dashboard roles, and release runbooks.

**Table content:**
| Layer | Target architecture | CEO decision / dependency |
| --- | --- | --- |
| Edge | Cloudflare CDN, WAF, DNS, TLS | Choose domain and WAF policy |
| Apps | API, worker, dashboard, website containers | Select hosting provider and region |
| Data | Managed Postgres 16 + Redis | Approve staging/prod databases and backups |
| Storage | S3/R2 private uploads and public CDN assets | Choose vault and storage provider |
| Secrets | Doppler, 1Password, AWS Secrets Manager, or equivalent | Pick source of truth |
| Observability | Logs, metrics, traces, Sentry-compatible errors | Approve tooling and alert rules |

**Suggested visual or diagram:** infra

**Speaker notes:** This slide turns infrastructure from an engineering detail into a CEO decision set. There is no production launch without hosting, secrets, database, and observability ownership.

**CEO takeaway:** The CEO must approve the infrastructure stack and operating budget before production commitments.

## Slide 15: Tech Stack: Modern TypeScript Platform With Shared Contracts
**Slide objective:** List the stack and why it fits.

**Main slide content:**

**Table content:**
| Area | Stack | Why it matters |
| --- | --- | --- |
| API | NestJS, Fastify, Prisma, Postgres | Modular backend, high performance HTTP, typed data access |
| Mobile | Expo, React Native, Expo Router, React Query, Zustand | iOS/Android velocity with native release path |
| Website | Next.js | SEO, marketing pages, localized routes |
| Dashboard | Next.js | Operational UI and admin workflows |
| Shared | packages/types, validators, config, api-client, ui | Contract reuse and lower duplication |
| Ops | pnpm, Turbo, CI, Docker, EAS | Repeatable builds and app releases |

**Suggested visual or diagram:** matrix

**Speaker notes:** The stack is sensible for speed and maintainability. The risk is not stack choice; it is incomplete integration and operational discipline.

**CEO takeaway:** Navi has a credible modern stack; now we must enforce contracts and production processes.

## Slide 16: Monorepo/Application Structure: Separate Apps, Shared Contracts
**Slide objective:** Show repository organization.

**Main slide content:**

**Table content:**
| Path | Ownership | Rules |
| --- | --- | --- |
| apps/mobile | Mobile Lead | Customer app only; no backend business logic |
| apps/website | Frontend Lead / PM | Marketing, SEO, partner acquisition, content consumption |
| apps/dashboard | Frontend Lead / Ops | Admin, provider, support, Super Admin workflows |
| apps/api | Backend Lead | Business logic, auth, RBAC, data, integrations |
| packages/types | Shared | API and domain types |
| packages/validators | Shared | Zod schemas used by backend and frontend |
| packages/api-client | Shared | Typed requests and token handling |
| packages/ui/config | Shared | Design tokens, shared UI, environment contracts |

**Suggested visual or diagram:** monorepo

**Speaker notes:** This slide enforces the architecture rule the user has repeated. Separate applications can still move together through shared contracts.

**CEO takeaway:** The repo is structured for scale if we keep responsibilities clean.

## Slide 17: Database Architecture: Marketplace Entities and Auditability
**Slide objective:** Summarize the data model.

**Main slide content:**
- Postgres and Prisma provide the primary source of truth for users, roles, permissions, businesses, listings, bookings, orders, payments, refunds, saved items, trip plans, translation jobs, content, support, and audit logs.
- Design principles: CUID identifiers, integer minor-unit money, UTC timestamps, soft delete for sensitive entities, scoped queries, and translation/content tables for multilingual readiness.
- Important entity groups: identity, marketplace supply, booking/order commerce, payments/refunds/payouts, user engagement, content, support, compliance.
- Current gaps: some requested dedicated models remain incomplete or merged into generic Listing/Order patterns; partner applications, private upload flows, and full finance reporting need completion.

**Suggested visual or diagram:** database

**Speaker notes:** Explain that a marketplace lives or dies by data correctness and scope. The database has a solid map, but some commercial entities must be completed before launch.

**CEO takeaway:** The database foundation is strong, but missing commercial models block production workflows.

## Slide 18: Security Architecture: Trust Is a Product Feature
**Slide objective:** Explain key protections.

**Main slide content:**
- Authentication: password hashing, OTP/reset flows, short-lived access tokens, refresh token rotation, device sessions, secure mobile storage.
- Authorization: permission-driven RBAC, backend guards, data scoping, partner isolation, driver assignment boundaries, Super Admin governance.
- Transport and app security: TLS, HSTS, CORS allowlist, CSP, CSRF for cookie-based dashboard actions, rate limits, mobile release hardening.
- Data protection: no PAN on Navi servers, private prescription uploads, PII minimization, log redaction, audit logs, privacy notices, secret vault references only.

**Suggested visual or diagram:** security

**Speaker notes:** The CEO should hear that security is not a post-launch task. Travel, payments, IDs, and prescriptions create real trust obligations.

**CEO takeaway:** Security controls must be built into each release gate, not retrofitted after demo success.

## Slide 19: RBAC and Permission Model: Data-Driven, Backend-Enforced Access
**Slide objective:** Show roles and permissions.

**Main slide content:**

**Table content:**
| Role | Allowed access | Critical restriction |
| --- | --- | --- |
| Guest | Public website, onboarding, discovery, emergency | No save, booking, order, profile, dashboard |
| Tourist | Own profile, bookings, orders, saved, planner, translator | Own data only |
| Premium | Tourist plus premium benefits and priority support | No admin/provider data |
| Partner Owner | Own business, team, listings, bookings, orders | Cannot access other partners |
| Provider Staff | Assigned operational items | No bank, payout, ownership, roles |
| Driver | Assigned delivery/ride jobs | No unassigned orders |
| Support Agent | Tickets and lookup tools | No payment/system settings |
| Admin / Super Admin | Operations / full system governance | Super Admin changes require audit |

**Suggested visual or diagram:** rbac

**Speaker notes:** This is a critical investor confidence slide. RBAC needs to exist in data and API, not only in the UI.

**CEO takeaway:** Navi cannot launch commercially until role access and data scope are proven by tests.

## Slide 20: Super Admin Model: Platform Control With Mandatory Audit
**Slide objective:** Define the highest-privilege model.

**Main slide content:**

**Table content:**
| Capability | Super Admin responsibility | Control required |
| --- | --- | --- |
| Roles and permissions | Create, assign, revoke, audit | Two-person policy later, audit now |
| System settings | Countries, Emirates, feature flags, integrations | Change logs and rollback plan |
| Provider governance | Approval, suspension, platform configuration | KYB and approval workflow |
| Payments/refunds | Provider config, disputes, override policies | Audit and finance reports |
| Content and marketing | Content approval and launch controls | Preview, approval, publish history |
| Demo access | Seed, reset, disable demo mode | Never enabled accidentally in production |

**Suggested visual or diagram:** matrix

**Speaker notes:** Super Admin is where the company can accidentally harm itself if unrestricted. The model needs careful controls and clear audit.

**CEO takeaway:** Super Admin access is a governance function, not a convenience role.

## Slide 21: Partner Access Model: Own-Business Scope Is Non-Negotiable
**Slide objective:** Explain partner isolation.

**Main slide content:**
- Provider isolation is a legal, commercial, and trust requirement.
- Every provider query must include membership/business scope, not just user role.

**Table content:**
| Partner role | Can do | Must not do |
| --- | --- | --- |
| Partner Owner | Manage business, team, listings, bookings, orders, reports | See or edit another business |
| Provider Manager | Manage assigned operations and staff | Change payout ownership without permission |
| Provider Staff | Update assigned orders/bookings/availability | Access finance, team roles, unrelated orders |
| Driver / Delivery | Accept and update assigned jobs | See customer data outside active job |
| Support escalation | Interact through support workflow | Bypass partner or customer scope rules |

**Suggested visual or diagram:** partner

**Speaker notes:** This slide should make clear that partner trust is impossible if one provider can see another provider’s data.

**CEO takeaway:** Partner scope enforcement is a launch blocker for any real supply-side rollout.

## Slide 22: Booking Engine Overview: From Discovery to Provider Fulfillment
**Slide objective:** Explain booking lifecycle.

**Main slide content:**
- Booking must support stays, rooms, activities, taxi-like reservations, and future event types through clear listing kinds.
- Quote and booking creation must use backend price rules, not frontend totals.
- Provider and admin dashboards must reflect booking status in real time or near-real time.
- Cancellation, refund, and support escalation are part of the booking engine, not separate afterthoughts.

**Flow nodes:**
- Select: listing, room, activity
- Quote: dates, guests, price
- Reserve: booking record
- Pay: intent and webhook
- Confirm: provider/admin views
- Support: cancel/refund/audit

**Suggested visual or diagram:** flow

**Speaker notes:** This clarifies what must happen before Navi can charge users. A booking is not complete until provider fulfillment and support handling are visible.

**CEO takeaway:** A beautiful booking screen is not enough; booking state and provider operations must be reliable.

## Slide 23: Payments and Refunds Architecture: Hosted Checkout, Idempotency, Webhooks
**Slide objective:** Explain payment posture and blockers.

**Main slide content:**
- Navi should stay SAQ A: no card number, CVV, or PAN touches Navi servers.
- Idempotency keys are mandatory for payment and refund writes to prevent duplicate charges.
- Webhook signature validation and queue processing protect payment correctness.
- Current readiness: payment abstraction and validation concepts exist; full sandbox-to-dashboard payment loop remains a P0 blocker.

**Flow nodes:**
- Mobile checkout: Payment Sheet / hosted page
- API intent: idempotency required
- Provider: Stripe primary, Telr fallback
- Webhook: signature verified
- State update: booking/payment/refund
- Audit/report: finance and support

**Suggested visual or diagram:** flow

**Speaker notes:** This is one of the most important CEO-risk slides. Payments require credentials, sandbox testing, webhook verification, and finance reports before any real users.

**CEO takeaway:** Do not launch paid bookings until Stripe/Telr sandbox flows, refunds, and dashboard finance visibility pass end-to-end QA.

## Slide 24: Third-Party Integrations: Provider Configuration Without Raw Secrets
**Slide objective:** Define integration operating model.

**Main slide content:**

**Table content:**
| Integration type | Example | Required controls |
| --- | --- | --- |
| Payments | Stripe, Telr, Apple Pay, Google Pay | Hosted checkout, webhook verification, vault secrets |
| AI | Claude provider, fallback deterministic planner | Quota, cost logging, structured output |
| OCR/Translation | Vision/OCR provider, translation provider | Private uploads, retention controls |
| Maps/Mobility | Taxi partners, map providers | API keys in vault, rate limits, provider health |
| Email/SMS/Push | OTP, receipts, support, notifications | Templates, retries, audit, opt-outs |
| Storage | S3/R2 private and public assets | Signed URLs, AV scan stub, lifecycle policies |

**Suggested visual or diagram:** matrix

**Speaker notes:** The dashboard should manage references and configuration state, not raw secrets. This is how Navi transitions from demo to real providers.

**CEO takeaway:** Integration readiness requires vault references, health checks, environment modes, and audit history.

## Slide 25: AI Trip Planner Architecture: Structured, Cost-Controlled, UAE-Focused
**Slide objective:** Explain AI planner design.

**Main slide content:**
- AI output must be structured JSON from tools, not free-text parsing.
- User text must be sanitized to defend against prompt injection.
- Daily quotas and max token caps protect costs.
- Failed AI calls should fall back gracefully so the journey does not break.
- Launch focus should stay UAE; international planning can come later.

**Flow nodes:**
- Inputs: Emirates, dates, party, interests
- Context: listings, pricing, availability
- AI Provider: structured tool output
- Fallback: deterministic planner
- TripPlan: DB record and status
- Analytics: cost, success, preferences

**Suggested visual or diagram:** flow

**Speaker notes:** AI should feel magical to users but boring and controlled in the backend. Cost and reliability matter for investor confidence.

**CEO takeaway:** AI is valuable only when it is structured, budgeted, auditable, and connected to real inventory.

## Slide 26: Translator and OCR Architecture: Helpful, Private, and Auditable
**Slide objective:** Explain image translator model.

**Main slide content:**
- Translator is a customer delight feature, but it can process sensitive images.
- The privacy model must be designed before real OCR provider launch.

**Table content:**
| Step | Backend action | Privacy requirement |
| --- | --- | --- |
| Capture / upload | Create upload or translation job | Do not expose private image URL publicly |
| OCR | Extract text through provider or mock layer | No sensitive image in analytics |
| Translate | Store source/target text if allowed | Retention policy and delete option |
| History | Show user-owned translation history | Only user or permitted support scope |
| Analytics | Count usage and failures | Privacy-safe aggregate only |

**Suggested visual or diagram:** translator

**Speaker notes:** Use this slide to show product nuance. The translator can differentiate Navi, but must not become a privacy risk.

**CEO takeaway:** Real OCR launch requires private storage, clear retention policy, and provider credentials.

## Slide 27: Notification System: Receipts, Status Updates, Support, and Re-Engagement
**Slide objective:** Define notification needs.

**Main slide content:**

**Table content:**
| Notification type | Examples | Required foundation |
| --- | --- | --- |
| Transactional | OTP, reset link, booking confirmation, receipts | Email/SMS/push providers, templates, retries |
| Operational | Order status, driver assigned, provider response | Queues, delivery jobs, state changes |
| Support | Ticket reply, refund decision, emergency follow-up | Role-aware messages and audit |
| Growth | Saved item reminder, premium offer, trip prompt | Consent, segmentation, frequency controls |
| Admin | Webhook failure, provider health, payment dispute | Alerts and escalation policy |

**Suggested visual or diagram:** matrix

**Speaker notes:** Notifications are not just marketing. They are necessary for booking trust and operational reliability.

**CEO takeaway:** Notifications should be built as a platform service with consent and audit, not ad hoc alerts.

## Slide 28: Audit Logs and Compliance: Every Sensitive Action Leaves Evidence
**Slide objective:** Define audit obligations.

**Main slide content:**

**Table content:**
| Action class | Examples | Audit metadata |
| --- | --- | --- |
| Identity | login, failed login, password reset, role change | actor, user, IP, device, traceId |
| Commerce | booking created, payment status, refund transition | amount, currency, provider, booking/order |
| Provider ops | listing publish, order status, payout change | businessId, actor role, previous/new state |
| Support | ticket update, customer lookup, emergency action | reason, permission, scope |
| Content | banner, onboarding, marketing, emergency numbers | entity, version, publish state |
| System | feature flags, integrations, demo mode | environment, config key, vault reference |

**Suggested visual or diagram:** matrix

**Speaker notes:** Audit logs are the CEO’s protection layer for disputes, staff actions, refunds, provider conflicts, and compliance reviews.

**CEO takeaway:** Audit-by-default is mandatory before real money, real partners, or sensitive documents.

## Slide 29: DevOps and CI/CD: Repeatable Builds Before Real Launch
**Slide objective:** Describe deployment discipline.

**Main slide content:**

**Table content:**
| Pipeline area | Required checks | Why it matters |
| --- | --- | --- |
| API | typecheck, lint, tests, migration checks, Docker build | Prevents broken backend releases |
| Mobile | typecheck, lint, tests, Expo doctor, EAS profiles | Protects iOS/Android releases |
| Dashboard/Website | typecheck, lint, tests, build, route smoke | Protects admin and marketing paths |
| Security | gitleaks, dependency scan, CodeQL, Trivy, SBOM | Prevents leaked secrets and known CVEs |
| Database | migrate deploy, seed smoke, rollback notes | Prevents schema drift |
| Release | changelog, runbook, staged rollout, rollback | Protects CEO demos and production changes |

**Suggested visual or diagram:** matrix

**Speaker notes:** This slide reframes DevOps as executive risk control. Green local builds are not enough; CI and runbooks must be consistent.

**CEO takeaway:** No production release without repeatable CI, migrations, secrets process, and rollback plan.

## Slide 30: Monitoring and Logging: Trace Every Critical Journey
**Slide objective:** Explain observability.

**Main slide content:**

**Table content:**
| Signal | What to capture | CEO value |
| --- | --- | --- |
| Logs | traceId, route, duration, userId, role, businessId | Debug incidents quickly |
| Metrics | latency, error rate, queue depth, checkout success | Know if platform is healthy |
| Traces | API to worker to provider calls | Find bottlenecks and broken integrations |
| Errors | mobile, API, dashboard, website exceptions | Reduce demo and user crashes |
| SLOs | API uptime, p95 latency, crash-free sessions | Set engineering accountability |
| Telemetry | search, save, click, booking/order intent | Understand user behavior and product fit |

**Suggested visual or diagram:** matrix

**Speaker notes:** This ties directly to the user’s ask about knowing what users search, click, like, and save. Engagement telemetry must become product intelligence.

**CEO takeaway:** Observability and analytics convert Navi from guesswork into an evidence-driven platform.

## Slide 31: Backup and Disaster Recovery: Protect Trust Before Scale
**Slide objective:** Summarize resilience requirements.

**Main slide content:**

**Table content:**
| Area | Target | Launch requirement |
| --- | --- | --- |
| Database | Automated backups, PITR, tested restore | Document RPO/RTO and run restore drill |
| Uploads | Versioned storage, lifecycle rules, private buckets | Protect IDs, prescriptions, avatars |
| Secrets | Vault-backed, rotated, no value-bearing examples | Document owner and break-glass path |
| Deployments | Blue/green or canary with rollback | Rollback runbook per app |
| Incidents | On-call, status page, postmortems | CEO and support escalation process |
| Compliance | Retention and deletion policies | User deletion and data export readiness |

**Suggested visual or diagram:** dr

**Speaker notes:** Resilience is an investor and partner confidence topic. We need a disaster plan before production, not after first incident.

**CEO takeaway:** Backups are not complete until restore has been tested and documented.

## Slide 32: QA and Testing Strategy: Platform Loops, Not Isolated Screens
**Slide objective:** Set the quality bar.

**Main slide content:**

**Table content:**
| QA layer | Scope | Acceptance signal |
| --- | --- | --- |
| Unit | validators, permissions, price rules, token refresh | Fast checks on core logic |
| API integration | auth, RBAC, bookings, orders, payments, webhooks | Database state and audit verified |
| Mobile smoke | iOS/Android navigation, forms, native actions | No crash, no fake buttons |
| Dashboard smoke | role menus, tables, create/edit flows | Live data, no static numbers |
| Website smoke | EN/AR routes, SEO, forms, consent | Marketing readiness |
| E2E journeys | register-save-book-pay-provider-dashboard | Real platform reflection |

**Suggested visual or diagram:** qa

**Speaker notes:** The CEO should understand that test strategy needs to match product reality. A button is not done unless the journey works.

**CEO takeaway:** QA should certify platform outcomes, not only UI appearance.

## Slide 33: Release Management Process: Controlled, Evidence-Based Launches
**Slide objective:** Define release governance.

**Main slide content:**
- Every release needs a named owner, branch/PR scope, changelog, migration notes, rollback plan, QA evidence, and known-risk statement.
- Mobile releases require EAS profiles, store credentials, privacy/data safety artifacts, TestFlight/Play internal testing, crash monitoring, and staged rollout.
- API/dashboard/website releases require environment variables, migrations, smoke tests, health checks, observability, and rollback runbooks.
- CEO demo releases should be tagged and frozen before demos, with a scripted path and known blocked features.

**Suggested visual or diagram:** release

**Speaker notes:** Release management is especially important because the user is asking for APK/TestFlight readiness. Store release is a process with external credentials and gates.

**CEO takeaway:** A release is not “done” until it is reproducible, testable, monitored, and reversible.

## Slide 34: Scrum and Delivery Process: Build in Thin, Real Platform Slices
**Slide objective:** Explain delivery rhythm.

**Main slide content:**
- Avoid giant prompt packs and giant PRs; use focused slices with clear acceptance criteria.
- Definition of Done: frontend action, backend API, database record, role enforcement, dashboard reflection, tests, docs, release notes.
- Scrum Master owns flow, blockers, ceremonies, and cross-team coordination; Product Manager owns priorities and acceptance.

**Flow nodes:**
- Backlog: CEO goals and product scope
- Slice: API + DB + UI + QA
- Sprint: focused build and review
- Demo: working platform evidence
- Release: runbook and rollout
- Measure: telemetry and support

**Suggested visual or diagram:** flow

**Speaker notes:** This slide addresses the execution risk from trying to build everything at once. It proposes disciplined slices.

**CEO takeaway:** Speed comes from smaller complete loops, not bigger unfinished feature batches.

## Slide 35: Product Management Process: Scope, Evidence, and Prioritization
**Slide objective:** Define PM operating model.

**Main slide content:**

**Table content:**
| PM area | Required practice | CEO benefit |
| --- | --- | --- |
| Roadmap | Phase-based scope and category modes | Prevents over-expansion |
| Requirements | User stories with role, API, data, dashboard reflection | Avoids fake UI |
| Metrics | Search, save, booking intent, order intent, support, conversion | Learns user behavior |
| Partner readiness | Category-level operational mode and GTM content | Matches supply reality |
| Launch readiness | P0/P1 blocker tracking and demo scripts | Protects investor demos |
| Feedback loop | Support notes, analytics, partner input | Prioritizes what matters |

**Suggested visual or diagram:** matrix

**Speaker notes:** PM must be technical enough to specify platform reflection and operational readiness, not just screens.

**CEO takeaway:** Product maturity means every feature has a user value, system effect, and measurable outcome.

## Slide 36: Engineering Team Structure: Build Around Platform Responsibilities
**Slide objective:** Show recommended technology org.

**Main slide content:**
- Small senior core first: CTO, VP Engineering/Delivery, backend/platform, mobile, web/dashboard, DevOps, QA/release.
- Add specialists as real production needs emerge: payments, security/compliance, data/analytics, partner integrations, AI, support operations.
- Each lead owns outcomes, not files: reliability, velocity, security, mobile quality, dashboard operations, release evidence.

**Suggested visual or diagram:** org

**Speaker notes:** This slide helps the CEO understand who is needed and why. The platform scope is too large for one engineer to own everything sustainably.

**CEO takeaway:** Navi needs a small senior launch team before a broad junior team.

## Slide 37: CTO Responsibilities: Technology Vision, Risk, and Investor Confidence
**Slide objective:** Define the CTO role.

**Main slide content:**
- Own architecture decisions, stack governance, platform separation, security posture, technical hiring, and technical due diligence narrative.
- Translate CEO ambition into phased technical execution, budget, and risk controls.
- Protect business logic, payments, data, and partner trust from prototype shortcuts.
- Chair architecture reviews, launch readiness reviews, security reviews, and post-incident learnings.
- Make the final technology go/no-go recommendation before investor or partner demos.

**Suggested visual or diagram:** role

**Speaker notes:** This positions the user as CTO leading the technology vision. The message is confident but accountable.

**CEO takeaway:** The CTO role is to make Navi credible, secure, scalable, and executable.

## Slide 38: VP Engineering Responsibilities: Delivery, Quality Gates, and Team Velocity
**Slide objective:** Define VP Engineering role.

**Main slide content:**
- Own sprint delivery, engineering rituals, code review quality, release coordination, staffing plans, and execution reporting.
- Convert architecture and product scope into achievable slices and PRs.
- Ensure each feature has acceptance criteria, tests, documentation, and rollback notes.
- Track blockers across backend, mobile, dashboard, website, DevOps, QA, and external dependencies.
- Report progress in terms of working platform journeys, not activity volume.

**Suggested visual or diagram:** role

**Speaker notes:** VP Eng is the execution counterpart to the CTO. This role protects delivery predictability.

**CEO takeaway:** VP Engineering turns technology vision into reliable weekly progress.

## Slide 39: Backend Lead Responsibilities: APIs, Data, RBAC, Integrations
**Slide objective:** Define backend lead ownership.

**Main slide content:**
- Own API modules, service boundaries, Prisma schema, database migrations, OpenAPI contracts, shared validators, and typed API clients.
- Implement auth, refresh tokens, RBAC, permission guards, data scoping, audit logs, idempotency, webhook verification, and background jobs.
- Build booking, order, payment/refund, provider, content, support, trip planner, translator, and reporting endpoints.
- Ensure no frontend-only business logic becomes a production dependency.
- Maintain API tests for role and data-scope enforcement.

**Suggested visual or diagram:** role

**Speaker notes:** Backend is the highest-risk engineering lane because it controls trust, money, and data.

**CEO takeaway:** Backend completion is the largest lever for turning Navi from UI into a product.

## Slide 40: Mobile Lead Responsibilities: iOS/Android Quality and Premium UX
**Slide objective:** Define mobile lead ownership.

**Main slide content:**
- Own Expo Router architecture, navigation, native capabilities, API client usage, secure token storage, offline/error/loading states, and performance.
- Match the Navi design direction while rebuilding screens as real React Native UI, not screenshots.
- Ensure every mobile button navigates, calls an API, opens a native action, or is feature-gated with reason.
- Own iOS and Android QA, TestFlight/Play readiness artifacts, accessibility, RTL behavior, and crash-free demo paths.
- Partner with backend for token refresh, checkout, saved items, trip planner, translator, notifications, and deep links.

**Suggested visual or diagram:** role

**Speaker notes:** This role bridges design fidelity and production behavior. The mobile app is where CEO demos will feel real or fail quickly.

**CEO takeaway:** Mobile success depends on reliable backend integration and store-release discipline.

## Slide 41: Frontend Lead Responsibilities: Website and Dashboard Operations
**Slide objective:** Define frontend lead ownership.

**Main slide content:**
- Own Next.js website, SEO, localized routes, marketing pages, partner application flow, dashboard routing, shared UI, forms, and API integrations.
- Ensure dashboard tables and metrics read live data and expose real create/edit workflows where required.
- Implement route protection and role-aware menus for admin, provider, support, and Super Admin.
- Use shared validators and API clients to avoid inconsistent rules across apps.
- Own website Lighthouse, accessibility, mobile responsiveness, cookie consent, privacy/terms, and bilingual content readiness.

**Suggested visual or diagram:** role

**Speaker notes:** Frontend here includes two different products: public website and operations dashboard. They need separate intent and quality gates.

**CEO takeaway:** Dashboard and website must be as real as the mobile app for Navi to be market-ready.

## Slide 42: DevOps Lead Responsibilities: Environments, CI/CD, Secrets, Reliability
**Slide objective:** Define DevOps ownership.

**Main slide content:**
- Own local, staging, demo, and production environment design; Docker images; CI/CD; hosting; DNS; TLS; WAF/CDN; secrets; migrations; backups; and rollback runbooks.
- Keep production secrets out of git and out of database rows; use vault references for provider credentials.
- Automate health checks, readiness checks, deploy gates, seed scripts, build artifacts, and security scans.
- Own EAS profiles and store build pipeline with mobile lead.
- Document operations so a release can be repeated without tribal knowledge.

**Suggested visual or diagram:** role

**Speaker notes:** DevOps is the difference between “runs on my machine” and “business can depend on it.”

**CEO takeaway:** Production launch needs environment ownership before more feature expansion.

## Slide 43: Security Lead Responsibilities: Threat Model, Privacy, Access, Payment Safety
**Slide objective:** Define security ownership.

**Main slide content:**
- Own threat model, authentication hardening, permission reviews, data-scope tests, rate limits, PII handling, prescription privacy, logging redaction, secrets policy, and security scans.
- Approve payment architecture to preserve SAQ A and prevent PAN handling.
- Define audit triggers and incident response controls for sensitive actions.
- Review partner isolation, support access, Super Admin controls, and demo mode exposure.
- Maintain compliance path for UAE PDPL, app store privacy, data retention, and breach readiness.

**Suggested visual or diagram:** role

**Speaker notes:** Security should not be painted as slowing down. It unlocks trust with CEOs, partners, app stores, and payment providers.

**CEO takeaway:** Security is a launch enabler when it is designed into the platform.

## Slide 44: QA Lead Responsibilities: Release Gates and Journey Evidence
**Slide objective:** Define QA ownership.

**Main slide content:**
- Own platform QA strategy: API, database, mobile iOS/Android, dashboard, website, roles, accessibility, visual match, performance, release blockers, and store-readiness evidence.
- Define P0/P1/P2/P3 severity and enforce no-release rules for auth, registration, booking/order, payment, role bypass, or crash failures.
- Create end-to-end journey tests proving mobile action to database to dashboard reflection.
- Capture screenshots and logs for investor/demo readiness.
- Keep QA honest: do not pass fake buttons, static dashboard numbers, frontend-only success, or disconnected APIs.

**Suggested visual or diagram:** role

**Speaker notes:** QA owns the truth. This is important because the user repeatedly asked whether the journey is fake or real.

**CEO takeaway:** QA must certify working platform loops before CEO demos and production releases.

## Slide 45: Release Manager Responsibilities: App Stores, API Releases, Rollbacks
**Slide objective:** Define release manager ownership.

**Main slide content:**
- Own release calendar, branch strategy, changelog, versioning, release notes, approvals, staging validation, store submissions, rollout windows, and rollback plans.
- Coordinate API, dashboard, website, and mobile releases so contracts remain compatible.
- Ensure TestFlight, Play internal testing, privacy manifests, data safety, signing credentials, screenshots, and release artifacts are ready.
- Freeze demo branches before CEO/investor meetings and maintain a scripted demo path.
- Report release readiness score with blockers and owner assignments.

**Suggested visual or diagram:** role

**Speaker notes:** Release manager protects the CEO from showing unstable work. This is a critical role before investor demos.

**CEO takeaway:** A release is an orchestrated business event, not just a build command.

## Slide 46: Product Manager Responsibilities: Roadmap, Requirements, Acceptance
**Slide objective:** Define PM ownership.

**Main slide content:**
- Own product scope, user stories, acceptance criteria, roadmap phases, stakeholder alignment, category modes, and feedback loops.
- Translate CEO ambition and partner needs into buildable slices with API/data/dashboard impact.
- Define MVP and Phase Two boundaries to prevent overbuilding before trust loops work.
- Use analytics and user behavior to prioritize what users search, click, save, book, abandon, and request support for.
- Maintain product gap list and CEO decision log.

**Suggested visual or diagram:** role

**Speaker notes:** Product management is how we keep Navi focused while still respecting the broad vision.

**CEO takeaway:** The PM keeps the team building the right slice at the right time.

## Slide 47: Scrum Master Responsibilities: Flow, Blockers, and Execution Hygiene
**Slide objective:** Define Scrum Master ownership.

**Main slide content:**
- Own sprint rituals, backlog readiness, dependency tracking, blocker removal, WIP limits, retro follow-through, and cross-role communication.
- Ensure each prompt/task becomes a manageable ticket, not a giant mixed change.
- Track external blockers: Apple, Google, Stripe, Telr, Anthropic, Sentry, hosting, legal, provider credentials.
- Protect the team from hidden work by making acceptance criteria, QA evidence, and release blockers visible.
- Support predictable delivery without weakening technical quality gates.

**Suggested visual or diagram:** role

**Speaker notes:** Scrum is not ceremony for its own sake. It creates a rhythm for a complex multi-app platform.

**CEO takeaway:** Execution hygiene is a CTO and CEO asset when the platform is broad.

## Slide 48: Report of Work Completed: Strong Foundation, Not Yet Full Production
**Slide objective:** Summarize completed work honestly.

**Main slide content:**
- Repo foundation: pnpm/Turbo monorepo, separate apps, shared packages, Git baseline, docs and audit artifacts.
- API foundation: NestJS/Fastify patterns, Prisma schema, migrations, auth routes, RBAC patterns, DTO mappers, validators, seed data, public content/search/home APIs.
- Mobile foundation: PDF-aligned reference screens, navigation shells, auth/OTP/reset flows, token refresh, saved items, trip planner, translator history, native action fixes, store-readiness checks.
- Dashboard/website foundation: API helper, permission map, API-backed pages, engagement dashboard, SEO/legal readiness work.
- QA/release foundation: route audits, CI checks, EAS config, release docs, Android/iOS local build reports, demo access seed and RBAC reflection audit.

**Suggested visual or diagram:** evidence

**Speaker notes:** Celebrate the foundation without overselling it. This creates credibility.

**CEO takeaway:** The project has moved beyond idea stage, but not beyond launch-blocker stage.

## Slide 49: Work Still Missing: Production Loops and Operational Depth
**Slide objective:** List core missing work.

**Main slide content:**
- Real payment loop: sandbox card, webhook, booking confirmation, refund state machine, finance dashboard.
- Partner onboarding: application model/API, KYB uploads, approval, business creation, owner login, first listing publishing.
- Provider/staff/driver operations: own-business scoping, assigned orders, status updates, availability, reports.
- Content management: onboarding, banners, emergency numbers, marketing pages, asset management, audit logs.
- Secure upload flows: prescription privacy, private documents, signed URLs, retention policy.
- Store/release external dependencies: Apple/Google accounts, signing, TestFlight/Play, live API domain, production secrets, legal/privacy approvals.

**Suggested visual or diagram:** gap

**Speaker notes:** This slide is intentionally direct. It tells the CEO what prevents real launch.

**CEO takeaway:** The missing work is concentrated around money, partners, private data, and operations.

## Slide 50: Current Risks: What Could Break CEO Demo or Market Launch
**Slide objective:** Rank risk areas.

**Main slide content:**
- Risk should be managed explicitly by owner and acceptance criteria.
- No risk should be hidden behind visual progress.

**Risk bars:**
- Payment readiness: 10/10 - Finish sandbox flow, webhook, refunds, finance dashboard
- Partner onboarding gap: 9/10 - Build application, approval, KYB, first listing flow
- Role/data-scope bypass: 9/10 - Backend RBAC and provider isolation tests
- Private upload/privacy: 8/10 - Signed URLs, private buckets, retention policy
- Dashboard static/partial flows: 8/10 - Replace shells with API-backed create/edit workflows
- Store credentials/signing: 7/10 - Apple/Google/EAS setup by owner
- Arabic/RTL QA: 6/10 - Visual and functional QA on mobile/web/dashboard
- Monitoring gaps: 6/10 - Sentry/OTel/logging alerts before launch

**Suggested visual or diagram:** risk

**Speaker notes:** Use this slide in leadership discussion. It is the CTO’s honest risk map.

**CEO takeaway:** The largest risks are solvable but must be funded and sequenced before launch.

## Slide 51: Technical Debt: What We Must Not Carry Into Production
**Slide objective:** Identify technical debt categories.

**Main slide content:**
- Partial APIs and placeholder flows must either become real, be feature-gated, or be removed from demo paths.
- Dashboard pages with static numbers or read-only shells create false confidence and must be converted to real data views.
- Some domain models are still generic or missing dedicated commercial structures; this is acceptable in MVP only when documented and tested.
- Mobile UI has improved but still needs full native QA, accessibility, RTL, offline/error states, and store release polish.
- CI/security gates need to cover validation bypass, OpenAPI drift, secrets scanning, Docker scanning, Playwright/Maestro smoke, and coverage thresholds.

**Suggested visual or diagram:** debt

**Speaker notes:** Frame technical debt as business risk. The team can carry some debt only when it is visible and has an owner.

**CEO takeaway:** Debt becomes dangerous when it hides fake readiness.

## Slide 52: Product Gaps: What Users and Partners Still Cannot Complete
**Slide objective:** List product readiness gaps.

**Main slide content:**
- Tourist gap: full checkout/payment, order tracking, support escalation, reliable saved/booking/order history, profile completeness, notification preferences.
- Partner gap: application, approval, onboarding, team, listing creation, pricing, availability, order/booking management, payouts, reporting.
- Admin gap: content management, emergency numbers, user/provider lifecycle, reports, support tools, payment/refund review, audit export.
- Website gap: complete bilingual marketing and partner sales funnel, SEO pages, demo request/contact sales, legal pages, consent.
- AI/translator gap: real provider credentials, privacy, cost controls, fallback, history retention, dashboard analytics.

**Suggested visual or diagram:** product-gap

**Speaker notes:** This slide organizes gaps by user type so the CEO can see what each stakeholder still needs.

**CEO takeaway:** Product completeness means every stakeholder can finish their primary job.

## Slide 53: Infrastructure Gaps: From Local Demo to Production System
**Slide objective:** List infra blockers.

**Main slide content:**

**Table content:**
| Gap | Impact | Owner / next action |
| --- | --- | --- |
| Production hosting not finalized | No reliable public API/dashboard/website release | DevOps + CEO choose provider and region |
| Secrets vault not selected | Risk of unsafe credentials handling | CEO approves vault; DevOps implements |
| Managed Postgres/Redis staging/prod missing | Cannot test production-like flows | DevOps provisions and documents |
| Sentry/OTel/logging incomplete | Hard to debug payment/AI/provider failures | DevOps + backend wire observability |
| Backups/restore not proven | Data loss risk | DevOps run restore drill |
| Store signing external | Cannot submit TestFlight/Play | CEO/mobile owner provide Apple/Google access |

**Suggested visual or diagram:** infra-gap

**Speaker notes:** Infrastructure gaps are not glamorous but block market launch. This slide gets CEO approval moving.

**CEO takeaway:** Production readiness requires named infrastructure decisions, not only code.

## Slide 54: Security Gaps: Must-Fix Before Real Users, Payments, or Prescriptions
**Slide objective:** List security blockers.

**Main slide content:**
- Complete backend permission enforcement and tests for admin, provider, staff, driver, support, guest, tourist, and Super Admin flows.
- Finish refresh token rotation/revocation and device session management if not already complete across all apps.
- Implement private upload architecture for prescriptions and KYB documents with signed URLs and no public exposure.
- Add CSRF protection for cookie-based dashboard POSTs, auth rate limits, security headers, and log redaction verification.
- Complete payment webhook verification, idempotency, no-PAN assurance, and secrets-vault integration.
- Document privacy, deletion, retention, breach response, and app store data disclosures.

**Suggested visual or diagram:** security-gap

**Speaker notes:** Do not soften this slide. Security gaps become legal and reputational risk.

**CEO takeaway:** Security must be a release gate for real users and partners.

## Slide 55: QA Gaps: What Must Be Tested Before CEO Demo and Store Submission
**Slide objective:** List QA gaps.

**Main slide content:**

**Table content:**
| QA gap | Why it matters | Acceptance signal |
| --- | --- | --- |
| Full iOS/Android journey smoke | CEO demo and store readiness | Screenshots + no crash + no warnings |
| Platform reflection tests | Proves real product behavior | Mobile action appears in DB and dashboard |
| Role/data-scope tests | Prevents security failure | Unauthorized API returns 403/401 |
| Payment sandbox E2E | Protects revenue and trust | Booking confirmed after webhook |
| Dashboard create/edit tests | Ensures operations can run | Admin/provider changes visible in mobile |
| Website SEO/RTL/Lighthouse | Supports growth and Arabic launch | Scores and screenshots documented |

**Suggested visual or diagram:** qa-gap

**Speaker notes:** QA needs to produce evidence, not just say it was checked.

**CEO takeaway:** Release readiness should be scored by evidence across mobile, API, dashboard, website, and roles.

## Slide 56: Recommended Roadmap: Finish Platform Loops Before Broad Expansion
**Slide objective:** Show phase plan.

**Main slide content:**
- Keep category modes explicit: disabled, marketing-only, inquiry-only, demo-only, sandbox-ready, live-ready.
- Do not mark a category live until provider operations, payment/refund, support, and dashboard reporting work.
- Use demo paths for investor storytelling, but keep production records and fake records clearly separated.

**Roadmap items:**
- Phase 1 (4-6 weeks): Foundation: auth, RBAC, API contracts, mobile shell, content, dashboard basics, release gates.
- Phase 2 (6-8 weeks): Marketplace: discovery, stays/activities, partner listings, bookings, saved items, support, provider dashboard.
- Phase 3 (6-8 weeks): Commerce: payments, refunds, payouts, orders, SIM, food/grocery/pharmacy, webhooks, notifications.
- Phase 4 (ongoing): AI/growth: real AI planner, OCR, analytics, multi-country, A/B, B2B APIs, advanced reporting.

**Suggested visual or diagram:** roadmap

**Speaker notes:** This roadmap matches current project documents and prevents overbuilding. It makes the CEO approve a sequenced strategy.

**CEO takeaway:** Navi should expand category by category only after each one has a real operational loop.

## Slide 57: Phase 1 Foundation Plan: Stabilize What Investors Will Inspect
**Slide objective:** Detail Phase 1.

**Main slide content:**

**Table content:**
| Workstream | Must complete | Acceptance evidence |
| --- | --- | --- |
| Architecture | App separation, shared contracts, API validation | No duplicated business logic, typed clients |
| Auth/RBAC | Login, registration, refresh, roles, permissions, route guards | Role tests and access matrix pass |
| Mobile core | Onboarding, home, discovery, saved, profile, emergency | iOS/Android smoke screenshots |
| Dashboard core | Users, content, listings, bookings/orders read models | Live API data and empty states |
| Website core | EN/AR home, tourist, partner, legal, SEO basics | Lighthouse/metadata/hreflang evidence |
| Release gates | Typecheck, lint, test, build, QA reports | Green checks and release notes |

**Suggested visual or diagram:** phase

**Speaker notes:** Phase 1 is not about every service being commercially complete. It is about a credible, stable foundation.

**CEO takeaway:** Phase 1 should earn confidence that the platform is real and controlled.

## Slide 58: Phase 2 Marketplace Plan: Supply, Booking, and Provider Operations
**Slide objective:** Detail Phase 2.

**Main slide content:**

**Table content:**
| Capability | Scope | Definition of Done |
| --- | --- | --- |
| Partner onboarding | Application, approval, business, owner login | Partner creates first listing |
| Stays/activities | Inventory, detail, room/activity booking | Tourist booking appears to provider/admin |
| Provider dashboard | Listings, availability, bookings/orders | Provider can manage only own data |
| Support | Tickets, lookup, notes, escalation | Support role cannot access finance settings |
| Reviews/saved | Favorites, ratings, analytics | User behavior visible in reports |
| Content ops | Banners, onboarding, emergency, destination content | Admin edits reflect in mobile/website |

**Suggested visual or diagram:** phase

**Speaker notes:** Phase 2 turns Navi into a marketplace, not just a content app.

**CEO takeaway:** Marketplace readiness requires supply operations as much as customer discovery.

## Slide 59: Phase 3 Service Expansion Plan: Real Commerce Across Categories
**Slide objective:** Detail Phase 3.

**Main slide content:**

**Table content:**
| Category | Commercial need | Readiness gate |
| --- | --- | --- |
| Payments/refunds | Stripe/Telr, webhooks, refund state | Sandbox E2E and finance dashboard |
| Food/grocery/pharmacy | Cart, inventory/menu, orders, provider status | Order appears to provider/admin/driver |
| SIM cards | Plan inventory, ID requirements, activation status | Provider dashboard and support flow |
| Taxi | Estimate, booking, assignment, status | Driver assignment and customer status |
| Payout/commission | Partner finance visibility | Commission and settlement reports |
| Notifications | Receipts, status, support, push | Templates, retries, opt-in/out |

**Suggested visual or diagram:** phase

**Speaker notes:** Commercial expansion should happen only with money, order state, provider responsibility, and support flows in place.

**CEO takeaway:** Phase 3 makes Navi revenue-capable; it should not start before Phase 2 provider operations are credible.

## Slide 60: Phase 4 AI and Growth Plan: Intelligence, Scale, and Expansion
**Slide objective:** Detail Phase 4.

**Main slide content:**

**Table content:**
| Growth area | What to build | Why it matters |
| --- | --- | --- |
| AI planner | Real provider, structured output, inventory-aware plans | Differentiates Navi and increases conversion |
| OCR/translator | Real OCR, translation, history, privacy controls | Tourist utility and daily value |
| Analytics | Conversion, saved, search, partner performance, funnel | Data-driven product decisions |
| Multi-country | Country/region expansion, currency, locale, providers | Long-term scale beyond UAE |
| Personalization | Preferences, recommendations, premium offers | Retention and monetization |
| Partner APIs | B2B integrations and webhooks | Scales supply operations |

**Suggested visual or diagram:** phase

**Speaker notes:** Phase 4 is where ambition gets bigger, but only after foundation, marketplace, and commerce loops are stable.

**CEO takeaway:** AI and growth should amplify a working marketplace, not mask missing operations.

## Slide 61: Hiring Plan: Small Senior Launch Team First
**Slide objective:** Recommend team buildout.

**Main slide content:**

**Table content:**
| Role | When | Why |
| --- | --- | --- |
| Backend/platform lead | Now | Own API, data, RBAC, payments, integrations |
| Mobile lead | Now | Own iOS/Android quality, checkout, store readiness |
| Frontend/dashboard lead | Now | Own website, dashboard, operations UI |
| DevOps/security lead | Now or fractional | Own environments, CI/CD, secrets, monitoring, security gates |
| QA automation lead | Now or fractional | Own E2E, mobile smoke, dashboard/API evidence |
| Product manager | Now | Own scope, acceptance, analytics, partner workflows |
| Partner integration engineer | Phase 2/3 | Provider APIs, health checks, category launch |
| Data/analytics engineer | Phase 3/4 | Reports, funnels, personalization, executive dashboards |

**Suggested visual or diagram:** hiring

**Speaker notes:** This slide gives the CEO a practical staffing plan. Avoid hiring too many juniors early; senior architecture decisions matter now.

**CEO takeaway:** A compact senior team can move faster and reduce rework.

## Slide 62: Budget and Resource Needs: Fund the Launch Blockers
**Slide objective:** Show resource categories.

**Main slide content:**
- People: senior backend, mobile, web/dashboard, DevOps/security, QA automation, product management.
- Cloud and tooling: hosting, managed Postgres/Redis, CDN/WAF, object storage, secrets vault, Sentry/observability, CI minutes, EAS, app store accounts.
- Commercial infrastructure: Stripe/Telr accounts, legal terms/privacy, provider contracts, KYB/document workflow, support tooling.
- AI and maps: Anthropic or selected AI provider, OCR/translation provider, maps/location provider, quota budgets and monitoring.
- Design/content: bilingual content, destination imagery, marketing copy, sales pages, app store assets, screenshots, brand polish.

**Suggested visual or diagram:** budget

**Speaker notes:** Keep this high-level unless CEO asks for numbers. The goal is to establish categories requiring approval.

**CEO takeaway:** The budget should prioritize launch-critical platform loops, not broad feature expansion.

## Slide 63: CEO Decisions Needed: The Next Gate Cannot Be Solved by Code Alone
**Slide objective:** List decisions needed from CEO/founders.

**Main slide content:**

**Table content:**
| Decision | Why it matters | Recommended action |
| --- | --- | --- |
| Launch scope | Avoid overpromising every category | Approve Phase One demo scope and live category modes |
| Provider strategy | Need real supply and contracts | Select first 2-3 provider categories for live readiness |
| Payment provider | Required for paid bookings/orders | Approve Stripe primary and Telr UAE fallback path |
| Infrastructure budget | Production environment required | Approve hosting, DB, Redis, storage, vault, observability |
| Store ownership | TestFlight/Play blocked without accounts | Assign Apple/Google owner and credentials process |
| Security/legal | Privacy, terms, PDPL, payments, uploads | Approve legal review and compliance owner |
| Hiring | Execution risk too high for one person | Approve senior launch team plan |

**Suggested visual or diagram:** decision

**Speaker notes:** This slide shifts accountability. Some blockers are business decisions and external access, not engineering effort.

**CEO takeaway:** CEO decisions determine whether Navi moves from demo to launch.

## Slide 64: Final Recommendation: Launch a Controlled Platform Readiness Wave
**Slide objective:** Close with clear CTO recommendation.

**Main slide content:**
- Do not keep adding random features until the foundation loops are complete.
- Approve a 60-90 day launch-blocker wave focused on real APIs, RBAC, partner onboarding, payments/refunds, dashboard operations, telemetry, QA, and store readiness.
- Keep the PDF design direction, but judge success by connected platform behavior: mobile action, API, database, dashboard, audit, QA evidence.
- Use demo mode for CEO/investor storytelling, but keep demo data isolated and never confuse it with production readiness.
- Run a weekly executive readiness review: completed loops, P0/P1 blockers, demo evidence, budget decisions, risk owners.

**Suggested visual or diagram:** recommendation

**Speaker notes:** End the main deck decisively. The recommendation is not to stop; it is to continue in a disciplined way.

**CEO takeaway:** Navi is worth continuing, but the next investment must complete real platform readiness.

## Slide 65: CTO Tickets: Architecture, Governance, Investor Confidence
**Slide objective:** Ticket report for CTO role.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | App separation, monorepo direction, architecture docs, audit reports | P0 | N/A | Use as governance baseline |
| WIP | Platform readiness tracker and CEO decision log | P0 | Scope drift and hidden blockers | Create weekly CTO readiness review |
| Missing | Architecture decision records for payments, AI, provider modes, secrets vault | P0 | Rework, unsafe launch choices | Approve ADRs before implementation |
| Missing | Technical due diligence package for investors | P1 | Lower investor confidence | Package architecture, QA, security, roadmap evidence |

**Suggested visual or diagram:** tickets

**Speaker notes:** This appendix slide gives the CTO ticket group in an executive table.

**CEO takeaway:** CTO work should convert ambition into governed architecture and credible evidence.

## Slide 66: VP Engineering Tickets: Delivery System and Quality Gates
**Slide objective:** Ticket report for VP Engineering.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Repo checks, local build reports, prompt tracker, release docs | P1 | N/A | Use as baseline |
| WIP | Slice-based Wave execution and blocker ownership | P0 | Giant PRs and mixed work | Enforce one platform loop per slice |
| Missing | Definition of Done across all apps | P0 | Fake completion | Adopt API+DB+dashboard+QA criteria |
| Missing | Sprint dashboard with P0/P1 blockers and owner status | P1 | Leadership lacks visibility | Report weekly to CEO |

**Suggested visual or diagram:** tickets

**Speaker notes:** VP Eng owns execution reliability. The tickets are about workflow, not only code.

**CEO takeaway:** Delivery must be managed by platform outcomes, not individual task volume.

## Slide 67: Backend Lead Tickets: API, DB, RBAC, Commerce
**Slide objective:** Ticket report for backend.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Auth, seed data, public APIs, search, saved, trip planner basics | P0 | N/A | Stabilize with tests |
| WIP | RBAC reflection, engagement events, dashboard analytics endpoints | P0 | User behavior invisible | Expand event catalog and API docs |
| Missing | PartnerApplication + KYB upload + approval workflow | P0 | No provider acquisition loop | Build public apply to dashboard approval |
| Missing | Payment/refund/webhook/idempotency E2E | P0 | No paid launch | Implement sandbox loop and tests |
| Missing | Provider/staff/driver scoped APIs | P0 | Data leakage and broken operations | Enforce business/assignment scope |
| Missing | Content management write APIs | P1 | Dashboard cannot control app/website | Build audited content endpoints |

**Suggested visual or diagram:** tickets

**Speaker notes:** Backend has the densest set of launch blockers. This slide helps prioritize.

**CEO takeaway:** Backend P0s are the main production launch blockers.

## Slide 68: Mobile Lead Tickets: Native Quality, Checkout, Store Readiness
**Slide objective:** Ticket report for mobile.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | PDF-aligned screens, navigation, API reads, native warning fixes, local iOS/Android build reports | P0 | N/A | Preserve demo path |
| WIP | Search, save, trip planner, translator, profile API integration | P0 | Partial user journey | Finish error/loading/empty states |
| Missing | Full checkout/payment sheet and order flows | P0 | No revenue-capable app | Integrate with payment backend |
| Missing | iOS TestFlight and Android Play signing | P0 | Cannot distribute externally | Requires Apple/Google/EAS access |
| Missing | Full RTL/accessibility/device matrix QA | P1 | Poor Arabic/user experience | Run iOS/Android QA and fix layout |

**Suggested visual or diagram:** tickets

**Speaker notes:** Mobile has strong demo value but needs checkout and store readiness to become market ready.

**CEO takeaway:** Mobile can be demo-ready before it is store-ready; do not confuse the two.

## Slide 69: Frontend Lead Tickets: Dashboard, Website, Shared UI
**Slide objective:** Ticket report for frontend.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Dashboard API helpers, permission map, website SEO/legal groundwork | P1 | N/A | Use as base |
| WIP | Engagement dashboard and API-backed pages | P0 | No product insight | Expand to bookings/orders/content |
| Missing | Partner apply website flow and dashboard review queue | P0 | No B2B funnel | Build apply/approve/login/listing flow |
| Missing | Admin/provider create/edit workflows | P0 | Static operations | Use shared validators and API clients |
| Missing | Bilingual marketing/sales pages and SEO evidence | P1 | Weak acquisition | Complete EN/AR pages and Lighthouse |

**Suggested visual or diagram:** tickets

**Speaker notes:** Frontend lead owns two CEO-visible surfaces: website and dashboard. Both must feel real.

**CEO takeaway:** Dashboard and website are commercial infrastructure, not secondary UI.

## Slide 70: DevOps Tickets: Environments, CI, Store Builds, Reliability
**Slide objective:** Ticket report for DevOps.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Local build reports, EAS config, release docs, CI groundwork | P1 | N/A | Keep green checks |
| WIP | Store build readiness and artifact validation | P0 | Unreliable release path | Resolve Android 16KB alignment and signing |
| Missing | Staging/prod hosting, managed DB/Redis, domains | P0 | No live test environment | Provision infrastructure |
| Missing | Secrets vault and environment matrix | P0 | Secret leakage/unsafe config | Select vault and document ownership |
| Missing | Sentry/OTel/logs/alerts/backups restore drill | P1 | Slow incident response | Wire observability and DR proof |

**Suggested visual or diagram:** tickets

**Speaker notes:** DevOps tickets mostly need CEO resource decisions. They are critical for production.

**CEO takeaway:** Infrastructure must move from local evidence to managed environments.

## Slide 71: Security Tickets: RBAC, Privacy, Payments, Secrets
**Slide objective:** Ticket report for security.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Security architecture docs, RBAC model docs, demo-mode safety requirements | P1 | N/A | Use as control baseline |
| WIP | Role and permission matrix implementation | P0 | Access bypass | Complete backend tests |
| Missing | Private prescription/KYB upload architecture | P0 | PII/privacy incident | Signed URLs, private buckets, AV scan stub |
| Missing | Payment webhook/signature/idempotency hardening | P0 | Duplicate charges or spoofed updates | Implement and test |
| Missing | CSRF, rate limits, security headers, gitleaks/CodeQL/Trivy | P1 | Security regression | Add CI and runtime controls |

**Suggested visual or diagram:** tickets

**Speaker notes:** Security tickets protect both users and company reputation.

**CEO takeaway:** Security P0s are tightly coupled to payments, partners, and private documents.

## Slide 72: QA Tickets: Evidence, Regression, Store Acceptance
**Slide objective:** Ticket report for QA.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | QA/release reports, local checks, iOS/Android build readiness evidence | P1 | N/A | Use as evidence baseline |
| WIP | Button/action scans and platform reflection audits | P0 | Fake readiness | Keep registry current |
| Missing | Automated API/RBAC/provider isolation tests | P0 | Security and data scope failures | Add test suite and CI gate |
| Missing | Mobile iOS/Android full screenshot matrix | P1 | Demo/store defects | Capture device evidence |
| Missing | E2E journeys: partner apply, booking, payment, order, dashboard reflection | P0 | Market flows unproven | Build Playwright/Maestro/API tests |

**Suggested visual or diagram:** tickets

**Speaker notes:** QA’s tickets are about proof. They close the trust gap between demo and production.

**CEO takeaway:** QA should produce the evidence package leadership can rely on.

## Slide 73: Release Manager Tickets: Controlled Demo, Store, and Production Readiness
**Slide objective:** Ticket report for release manager.

**Main slide content:**

**Table content:**
| Status | Ticket / work | Priority | Risk if skipped | Next action / outcome |
| --- | --- | --- | --- | --- |
| Completed | Release docs, store-readiness report, branch/push evidence | P1 | N/A | Track artifacts |
| WIP | Demo freeze and scripted journey | P0 | CEO demo instability | Freeze known-good branch |
| Missing | TestFlight and Play internal testing submissions | P0 | No external mobile testing | Requires account credentials |
| Missing | Production release runbooks per app | P1 | Unclear rollback | Create API/dashboard/website/mobile runbooks |
| Missing | Release readiness scorecard and sign-off process | P1 | Ambiguous go/no-go | Adopt weekly release review |

**Suggested visual or diagram:** tickets

**Speaker notes:** Release manager ensures the company does not show or ship unstable work.

**CEO takeaway:** A strong release process protects the CEO, investors, and first customers.

## Slide 74: Next 90 Days: Executive Operating Cadence
**Slide objective:** End with actionable operating rhythm.

**Main slide content:**
- Weekly CTO readiness review: completed platform loops, blockers, risks, QA evidence, CEO decisions.
- Do not move a feature to demo-ready unless it has route/API/DB/dashboard/audit/test evidence.
- Prepare separate investor demo, partner demo, and internal operations demo scripts.

**Roadmap items:**
- Weeks 1-2 (Stabilize): Freeze demo branch, close P0 auth/RBAC gaps, provision staging, confirm accounts.
- Weeks 3-6 (Platform loops): Partner apply/approve, provider listing, booking/order reflection, dashboard write flows.
- Weeks 7-10 (Commerce): Stripe/Telr sandbox, refunds, webhooks, payments dashboard, receipts/notifications.
- Weeks 11-12 (Demo/launch gate): Full QA, TestFlight/Play internal, investor demo script, release scorecard.

**Suggested visual or diagram:** roadmap

**Speaker notes:** This final appendix slide gives the CEO an operating plan that can start immediately.

**CEO takeaway:** The next 90 days should prove the business system, not only polish screens.