Confidential — Enterprise eCommerce Procurement Document
Ajlan & Bros Holding
Headless Commerce Replatforming — Complete Gap Analysis, Risk Assessment & Enterprise Requirements Document
Deliverable A
Executive Summary
This document provides a complete enterprise-level gap analysis of V4Tech's Headless Commerce proposal (Ref: V4TECH-PID-HL26533) for Ajlan & Bros. It identifies critical gaps, commercial risks, and missing requirements across all functional domains. The proposal must not be signed in its current form without addressing the items flagged herein.
67
Clarification Questions
⚠ Critical Finding: The V4Tech proposal is a high-level marketing document masquerading as a technical Scope of Work. It contains no SLAs with defined response times, no PCI DSS compliance commitment, no disaster recovery plan, no data migration plan, no acceptance criteria, no definition of "go-live," and only 1 month of warranty. The GCC Oracle Fusion Integration SOW (Magento-side) is the only technically rigorous document in the package — and it explicitly excludes the Fusion team's side. Do not sign until all 23 critical items are resolved in writing.
✅ What the Proposal Covers
- Tech stack selection (Magento + Next.js + Flutter + Golang)
- High-level ERP sync mention (inventory, price, orders)
- Shipping carriers named (Aramex, Barq, Ajex)
- BNPL providers named (Tabby, Tamara, Neo)
- Payment gateway options listed
- AWS hosting commitment (no spec)
- Bulk AWB + invoice printing
- 16-week Phase 1 timeline
- Full payment lifecycle (auth / capture / refund)
- GCC Phase 2 — 4 countries listed
❌ What Is Critically Missing
- No PCI DSS compliance statement
- No SLA table (response/resolution times)
- No DR / RTO / RPO commitments
- No data migration plan or scope
- No loyalty / Qitaf program specification
- No acceptance criteria for go-live
- No IP ownership of AWS accounts
- No source code delivery timeline
- No performance benchmarks (load, LCP)
- No security audit / pentest commitment
- No mobile app store ownership
- No marketplace integration detail
Deliverable B
Missing Requirements Report
| ID |
Domain |
Missing Requirement |
Severity |
Impact |
| MR-01 | Commercial | No SLA table with defined P1/P2/P3 response and resolution times | Critical | No contractual basis to hold vendor accountable for outages |
| MR-02 | Security | No PCI DSS compliance scope, responsibility, or certification commitment | Critical | Financial and regulatory exposure for card payments |
| MR-03 | Infrastructure | No AWS architecture diagram, instance types, Auto-Scaling policy, or CDN config | Critical | Cannot evaluate scalability or cost; vendor controls all infrastructure |
| MR-04 | Infrastructure | No Disaster Recovery plan — no RTO or RPO commitments | Critical | No recovery guarantee during outage events |
| MR-05 | Ownership | AWS account ownership not stated — will accounts be in client's name? | Critical | Vendor lock-in; losing vendor means losing infrastructure |
| MR-06 | Ownership | Mobile app store accounts (Apple Developer, Google Play) ownership undefined | Critical | Cannot publish updates or remove vendor without losing app ratings/installs |
| MR-07 | Data Migration | Zero mention of existing data migration — products, customers, orders, catalog | Critical | Major hidden cost and timeline risk; current site continuity not guaranteed |
| MR-08 | Commerce | Loyalty program / Qitaf integration not mentioned anywhere | Critical | A core KSA retail requirement missing entirely |
| MR-09 | Commerce | No promotion engine specification — stacking rules, exclusion logic, scheduling | Critical | Risk of discount abuse and revenue leakage |
| MR-10 | Testing | No acceptance criteria defined for go-live sign-off | Critical | Dispute risk over what constitutes project completion |
| MR-11 | Commercial | No change request process, governance, or pricing for changes defined | Critical | Every post-freeze request becomes a commercial dispute |
| MR-12 | Support | Only 1 month warranty — industry standard is minimum 3–6 months | Critical | Post-launch bugs must be paid for within 30 days |
| MR-13 | Security | No penetration testing or VAPT commitment | Critical | Production deployment of unaudited enterprise eCommerce platform |
| MR-14 | ERP | Return/refund flow between Magento and Oracle Fusion not specified | Critical | Returns will require manual intervention and ERP reconciliation errors |
| MR-15 | Payments | No specification for Sadad, mada, Apple Pay, STC Pay in KSA checkout | High | Missing KSA-critical payment methods |
| MR-16 | Mobile | No deep link strategy, push notification spec, or App Store review timeline | High | App store rejections can delay go-live by weeks |
| MR-17 | Analytics | GA4 eCommerce data layer spec not defined (Enhanced Ecommerce events) | High | No baseline analytics at launch; marketing blind |
| MR-18 | SEO | No redirect mapping plan for existing URLs during replatforming | High | 100% organic traffic loss at launch is possible |
| MR-19 | Performance | No Core Web Vitals targets or LCP/CLS/INP commitments | High | Platform may fail Google's ranking thresholds |
| MR-20 | Customer Service | No CRM / helpdesk integration (Zendesk, Freshdesk, etc.) | High | Customer service team has no order context visibility |
| MR-21 | Commerce | No gift card, store credit, or voucher functionality defined | High | Common retention mechanic missing |
| MR-22 | Commerce | No wishlist, compare, or saved-for-later specification | High | Reduced conversion features |
| MR-23 | Marketplace | No marketplace integration specification (Noon, Amazon.sa, Salla) | High | Mentioned as channel but completely unscoped |
Deliverable C
Risk Assessment Report
| Risk |
Category |
Severity |
Probability |
Mitigation Required |
| Vendor lock-in via infrastructure ownership. All AWS resources provisioned by V4Tech with no commitment to transfer accounts to client. |
Ownership | Critical | High |
Require client-owned AWS account with vendor as IAM user. Confirm in writing before signing. |
| Source code withheld during active support. Source code handover is conditional on "no longer under Support/Maintenance" — vendor can perpetually delay handover by renewing SLA. |
Commercial | Critical | High |
Remove this condition. Source code must be delivered to an escrow or client Git account at project sign-off, unconditionally. |
| 16-week timeline for a full headless replatform + Oracle Fusion ERP integration + Flutter mobile app is extremely aggressive. Comparable projects typically require 9–18 months. |
Technical | Critical | Very High |
Demand a detailed sprint-by-sprint project plan with milestone definitions, dependency mapping, and explicit delay penalty clauses. |
| No data migration plan. Moving thousands of products, customer accounts, and order history from the existing Magento PWA to the new platform is entirely unscoped. |
Operational | Critical | Certain |
Require a dedicated data migration SOW covering mapping, validation, rollback, and downtime window. |
| Payment security (PCI DSS) responsibility unassigned. Handling card payments without a PCI DSS scoping and compliance plan exposes Ajlan & Bros to regulatory fines and data breach liability. |
Security | Critical | High |
Require vendor to specify PCI DSS scope (SAQ vs. ROC), tokenization approach, and certify compliance before go-live. |
| ERP integration scope mismatch. V4Tech's proposal and the Magento-side SOW scope only Magento's side. The Oracle Fusion team SOW (the receiving side) is a separate document with its own dependencies and risks. |
Integration | Critical | Very High |
Establish a joint integration governance board. Both SOWs must be reviewed together before any development begins. |
| SAR 20,000/month SLA plan caps at 120 hours. For an enterprise platform serving 5 GCC countries, this is insufficient for production incidents that may require hundreds of hours to resolve. |
Commercial | High | High |
Define P1 incident response outside the hour cap. Require 24/7 on-call for production outages. |
| Phase 2 GCC timeline undefined. 4 additional stores in 16 weeks immediately following Phase 1 with no buffer, no separate requirements phase, and no mention of country-specific regulatory differences. |
Operational | High | High |
Require a dedicated Phase 2 discovery and requirements phase before Phase 2 development begins. |
| Flutter single-codebase mobile app carries performance risk. Cross-platform apps regularly fail App Store and Play Store performance benchmarks and review criteria, causing launch delays. |
Technical | High | Medium |
Require app performance benchmarks, confirmation of native device features (biometrics, push notifications, deep links) and App Store review timeline buffer. |
| AWS cost not included in contract. AWS infrastructure costs are passed to the client but no estimate is provided, creating an open-ended financial commitment. |
Commercial | High | Certain |
Require an AWS cost estimate per month for each phase, including reserved instance sizing and traffic assumptions. |
| Third-party SaaS license costs not included. Prerender.io, Elastic Suite, Stamped.io/Yotpo, Mailchimp, Amazon Personalize, Hotjar, Mixpanel — all carry separate subscription costs not in the proposal price. |
Commercial | High | Certain |
Require a complete total cost of ownership (TCO) table including all third-party SaaS tools with annual subscription estimates. |
| SEO continuity risk during replatforming. No redirect mapping, no URL structure freeze, no sitemap migration plan — the existing search equity can be completely lost at go-live. |
Operational | High | High |
Require a pre-go-live SEO audit, URL mapping document, and post-launch monitoring commitment of minimum 4 weeks. |
| Unauthorized code modification voids warranty. Any bug fixed by Ajlan & Bros' internal team voids the 1-month warranty, making client completely dependent on vendor for all fixes. |
Vendor Lock-in | High | High |
Negotiate warranty terms to allow client's team to make fixes without voiding warranty, or require separate escrow with fix rights. |
| Golang middleware is a non-standard addition to the Magento ecosystem, creating a custom dependency that only V4Tech can maintain. |
Technical | Medium | Medium |
Require complete middleware architecture documentation, API specs, and developer handover documentation. |
| Requirements freeze clause creates change request trap. Vendor can declare any feature a "change" and charge extra even if it was implied in the original scope. |
Commercial | Medium | High |
Define explicit scope boundary in writing, including a list of "implied but not listed" features that are covered. |
Section 1
Commercial & Payment Terms
1.1 Pricing & Payment Milestones
Critical: Phase 1 payment breakdown in the proposal does not add up. 40% + 40% + 20% = 100%, but the totals shown are SAR 102,938 + 102,938 + 51,468 = SAR 257,344 — yet the discounted price is SAR 357,344. The missing SAR 100,000 is unaccounted for. This must be corrected before signing.
REQ-COM-01
Payment Tied to Verifiable Milestones
Payment stages must be tied to written, verifiable, signed-off deliverables — not dates. "Before go-live" is not a milestone. Define exactly what must pass UAT before each payment triggers.
REQ-COM-02
Change Request Process & Pricing
A formal change request (CR) process must be defined: CR template, assessment timeline (max 5 business days), pricing method (day rate or fixed), approval chain, and impact on timeline. Day rate for additional work must be agreed in advance.
REQ-COM-03
Penalty Clauses for Delay
Define financial penalties for vendor-caused delays. Standard is 0.5%–1% of contract value per week delay, capped at 10%. Without this, the 16-week timeline is aspirational with no commercial consequence for overrun.
REQ-COM-04
Total Cost of Ownership (TCO) Disclosure
Vendor must provide a 3-year TCO including: Phase 1 development, Phase 2 development, AWS monthly estimate, all third-party SaaS subscriptions, SLA monthly cost, estimated change request budget, and Magento license/upgrade costs.
1.2 Clarification Questions
Is VAT at 15% applied to all line items including the SLA monthly fee? Confirm the total VAT-inclusive amounts for each payment stage.
The Phase 2 down payment triggers "after the warranty period" — what date does this calculate to if Phase 1 go-live is delayed? Is Phase 2 pricing fixed or subject to change?
What constitutes "all payments due to V4Tech are settled" before source code is handed over? Can a dispute over a final invoice delay code handover indefinitely?
Are Magento Commerce/Adobe Commerce license fees included in the project price? Which Magento edition is being used (Open Source vs Adobe Commerce)?
Section 2
Scope Ownership Matrix
Legend: V = Vendor (V4Tech) · C = Client (Ajlan & Bros) · S = Shared · T = Third Party
| Deliverable | Owner | Confirmed in Proposal? | Risk / Note |
|---|
| Magento backend development | V | ✓ Yes | Magento edition (Open Source vs Commerce) not stated |
| Next.js frontend development | V | ✓ Yes | Number of page templates not specified |
| Flutter mobile app (iOS + Android) | V | ✓ Yes | Feature parity with web not confirmed |
| Golang middleware | V | ✓ Yes | Proprietary — no documentation commitment |
| UI/UX Design | V | ✓ Yes | Number of screens, design rounds not specified |
| AWS infrastructure setup | V | Partial | AWS account ownership not confirmed as client-owned |
| AWS monthly cost | C | ✗ Not stated | Open-ended financial commitment |
| Oracle Fusion ERP configuration | C | ✓ Yes (separate SOW) | Fusion team's SOW must be reviewed jointly |
| Magento–Fusion integration (Magento side) | V | ✓ Detailed SOW | Fusion side is separate and not V4Tech's responsibility |
| Staging database provisioning | C | ✓ In integration SOW | Client must provision before Phase 1 environment setup |
| ERP Integration (returns/refunds channel) | S | ✗ Not scoped | Critical gap — no return/refund ERP sync defined |
| Payment gateway accounts | C | Assumed | Client must provide gateway credentials; who sets up merchant accounts? |
| Payment gateway development | V | Partial | Only one gateway confirmed — which one? |
| BNPL integration (Tabby, Tamara) | V | ✓ Listed | Which BNPL provider is confirmed in scope? All three or one? |
| Shipping integration (Aramex, Barq, Ajex) | V | ✓ Listed | All three or pick one? Confirm all three are in scope |
| SMS gateway (Value First) | T | Partial | Integration by V4Tech; account/cost is client's |
| Data migration (products, customers, orders) | S? | ✗ Not mentioned | Major scope gap — must be explicitly assigned |
| DNS & domain management | C | ✓ Client provides domain | Confirm SSL provisioning is vendor's responsibility |
| SSL certificates | V? | ✗ Not confirmed | Must be explicit |
| Apple Developer Account | C | ✗ Not stated | Must be in client's name |
| Google Play Console Account | C | ✗ Not stated | Must be in client's name |
| Analytics accounts (GA4, GTM, Hotjar) | C | ✗ Not stated | Must be in client's name with vendor as user |
| Git repositories | C | ✗ Not confirmed | Client must own all repos from day one |
| Loyalty / Qitaf integration | ? | ✗ Not mentioned | Critical KSA requirement with no owner assigned |
| Training | V | ✗ Not specified | No training plan, hours, or materials defined |
Section 3
Security, Compliance & Infrastructure
The proposal contains zero security specifications. "Emphasis on Security" in the intro is a marketing statement with no technical content. Every item below must be explicitly committed to in the contract.
REQ-SEC-01 — PCI DSS Compliance
Payment Card Industry Compliance
Vendor must specify PCI DSS scope: is the platform in-scope (SAQ D) or using tokenization to reduce scope (SAQ A)? Provide written confirmation of compliance approach. If tokenization is used, which payment gateway handles cardholder data, and is it confirmed as out of Ajlan & Bros' scope?
REQ-SEC-02 — Penetration Testing
VAPT Before Go-Live
A third-party penetration test (VAPT) must be completed on the full platform before production go-live. Vendor must remediate all Critical and High findings. Test must cover web application, mobile app, APIs, and AWS infrastructure. Report must be delivered to client.
REQ-SEC-03 — AWS Architecture
Infrastructure Specification
Vendor must provide a full AWS architecture diagram including: VPC design, public/private subnet layout, EC2 instance types (Magento, middleware, Redis), RDS configuration (Multi-AZ?), CloudFront CDN, S3 media storage, WAF configuration, auto-scaling groups and policies, and estimated monthly cost. All must be confirmed before signing.
REQ-SEC-04 — Disaster Recovery
RTO, RPO & DR Plan
RTO (Recovery Time Objective): Maximum tolerable downtime must be stated (suggested: ≤4 hours for P1 incidents). RPO (Recovery Point Objective): Maximum data loss window (suggested: ≤1 hour). Vendor must provide a written DR runbook covering database failover, static asset recovery, and DNS failover procedures.
REQ-SEC-05
Backup Policy
Daily automated backups of database, media, and configuration. Minimum 30-day retention. Weekly backup restore tests. Backups stored in a separate AWS region. Client must have direct access to backup files.
REQ-SEC-06
HTTPS & SSL
All 5 country domains (Phase 1: KSA + Phase 2: UAE, Kuwait, Bahrain, Qatar) must have SSL certificates provisioned and auto-renewed (Let's Encrypt or ACM). HSTS must be enabled. No mixed content.
REQ-SEC-07
WAF & DDoS Protection
AWS WAF must be configured with OWASP Top 10 rule sets, rate limiting, bot mitigation, and SQL injection/XSS protection. AWS Shield Standard at minimum; Shield Advanced required if handling high-value transactions. Vendor must confirm WAF is in scope and not an add-on.
REQ-SEC-08
Admin Access & IAM
Magento Admin panel must use 2FA. AWS IAM follows principle of least privilege with no shared root accounts. All vendor access must use named IAM users (not root). Client must have root access to all AWS accounts from day one.
REQ-SEC-09
Data Residency
All customer PII must be stored in AWS region me-south-1 (Bahrain) or me-central-1 (UAE) to comply with Saudi PDPL and UAE data sovereignty requirements. Confirm primary and backup regions.
REQ-SEC-10
Vulnerability Management
Vendor must commit to patching Magento security patches within 72 hours of release for Critical, 7 days for High. All third-party extensions must be from reputable sources with active maintenance. Monthly security scan reports must be delivered to client.
Section 4
Platform Architecture
4.1 Architecture Clarifications Required
Is Magento Open Source or Adobe Commerce (formerly Magento Commerce)? Adobe Commerce carries significant licensing costs that must be included in TCO. If Open Source, which critical features (B2B, Advanced Reporting) will be custom-built?
What version of Magento will be deployed? Latest stable at time of signing or a specific pinned version? Who is responsible for version upgrades during the support period?
Is the Golang middleware a proprietary V4Tech product or an open-source framework? Will complete source code and API documentation be delivered? Are there any licensing restrictions?
How is the Next.js frontend hosted — Vercel, AWS CloudFront/S3, or an EC2-based Node.js server? Each has different performance, cost, and maintenance implications.
What is the API strategy between Next.js and Magento? Does Next.js call Magento REST directly, or does everything route through the Golang middleware? Provide an API architecture diagram.
Is GraphQL supported in addition to REST? Many PWA headless implementations require Magento's GraphQL API for performance. Confirm which protocol is primary.
4.2 Architecture Requirements
REQ-ARCH-01
API Contract Documentation
All custom APIs (Golang middleware endpoints, Magento custom endpoints) must be documented in OpenAPI/Swagger format and delivered as part of project handover. This is mandatory for future vendor independence.
REQ-ARCH-02
High Availability Configuration
Production environment must be multi-AZ. RDS must be Multi-AZ. Magento application servers must be behind an Auto Scaling Group with a minimum of 2 instances. Redis must be ElastiCache with Multi-AZ replication. Single points of failure are unacceptable for enterprise retail.
REQ-ARCH-03
Headless Architecture Documentation
Vendor must deliver a complete architecture document covering: frontend-backend API contract, middleware data flow, caching layers (Redis, CDN, Varnish/FPC), session management, authentication flow (JWT/OAuth), and media asset pipeline.
Section 5
Product Catalog & PIM
REQ-CAT-01
Product Types in Scope
Vendor must confirm which Magento product types are in scope: Simple, Configurable, Grouped, Bundle, Virtual, Downloadable. For Ajlan & Bros textile/apparel products, Configurable products with color/size attributes are likely the primary type — confirm this is fully supported including swatch rendering in the headless frontend.
REQ-CAT-02
Number of Products & Bulk Operations
State the current catalog size and expected growth. Confirm bulk import (CSV/XLSX) for product data, bulk price updates, bulk image uploads, and bulk status changes. Performance must be maintained with 10,000+ SKUs.
REQ-CAT-03
Media Management
Product images stored on S3. Vendor must confirm: image CDN delivery, automatic WebP conversion, multiple image angles per product, video support, and zoom functionality. Migration of existing product images must be included.
How many custom product attributes does the current platform have? Are these migrated to the new platform or rebuilt? Who is responsible for the attribute mapping?
Is a separate PIM system (Akeneo, etc.) in scope, or is Magento Admin the sole source of truth for product content?
Section 6
Pricing, Promotions & Loyalty
REQ-PROMO-01
Promotion Engine Specification
The proposal mentions "Advanced features for promotions" but provides zero detail. The following must be explicitly confirmed in scope: Cart price rules, Catalog price rules, Coupon codes (single-use and multi-use), Tiered pricing, Customer group pricing, Date-scheduled promotions, Free shipping promotions, Buy X Get Y rules, Promotion stacking (allow/deny), Coupon exclusion rules, and maximum discount caps.
REQ-PROMO-02
Qitaf Loyalty Program Integration
Qitaf is a mandatory loyalty requirement for major Saudi retailers. Vendor must confirm: Qitaf points earning on purchase, Qitaf points redemption at checkout, real-time Qitaf API integration, points balance display in customer account, and Qitaf reporting. If not in scope, this must be a separate costed item.
REQ-PROMO-03
Store Credit & Gift Cards
Confirm whether store credit issuance (for returns, compensation), gift card generation and redemption, and partial payment with store credit + cash are in scope.
REQ-PROMO-04
Country-Specific Pricing
The Magento integration SOW references per-country price lists from Oracle Fusion. Confirm that each GCC store supports independent pricing, that price updates from Fusion are applied per-country in the correct currency, and that no cross-country price contamination is possible.
Section 7
Checkout, Payments & Refunds
REQ-PAY-01
KSA Payment Methods — Mandatory
The proposal does not mention mada, which is the dominant debit card network in Saudi Arabia and mandatory for KSA retail. The following KSA payment methods must be confirmed in scope: mada, Visa, Mastercard, Apple Pay, STC Pay, Cash on Delivery (COD), Tabby, Tamara, Neo. Sadad (bill payment) should be evaluated. Confirm which gateway supports mada (Checkout.com, PayTabs, and ClickPay all support mada but APS integration must be confirmed).
REQ-PAY-02
Which Payment Gateway Is Actually in Scope?
The proposal lists APS, Checkout, ClickPay, PayTabs as options but does not commit to any specific one. The contract must state the exact gateway(s) to be integrated. Each gateway has a different integration complexity, feature set, and cost. This ambiguity cannot survive into a signed agreement.
REQ-PAY-03
Refund Process — Full & Partial
Vendor confirms auth/capture/refund lifecycle. Must also confirm: partial refund support (refund one item from a multi-item order), refund to original payment method vs. store credit, BNPL provider refund handling (Tabby/Tamara have specific refund APIs), refund sync to Oracle Fusion ERP, and refund notification to customer via SMS/email/WhatsApp.
REQ-PAY-04
GCC Payment Methods (Phase 2)
Each GCC country requires confirmation of local payment methods: UAE (Apple Pay, Google Pay, Tabby, Tamara, FAB, ENBD), Kuwait (KNET — mandatory debit network), Bahrain (BenefitPay), Qatar (QPay, QNBFS). Confirm which methods are included in Phase 2 scope and which require a separate change request.
REQ-PAY-05
Checkout Experience
Confirm: guest checkout, address autocomplete (Google Places API for GCC addresses), saved addresses for logged-in users, order summary with VAT breakdown, promo code field, BNPL eligibility check, multi-step vs. single-page checkout, and Arabic RTL support on all checkout screens.
REQ-PAY-06
Fraud Prevention
Confirm fraud screening mechanism: payment gateway's built-in fraud tools, 3D Secure 2.0 (mandatory for KSA card payments), velocity checks, and blacklist management.
Section 8
Shipping & Delivery
REQ-SHIP-01
All Three Carriers Must Be Confirmed
The proposal mentions Aramex, Barq, and Ajex but does not commit to integrating all three. The contract must explicitly confirm all three carriers are in Phase 1 scope with real-time rate calculation, AWB generation, tracking webhook integration, and status update mapping.
REQ-SHIP-02
AWB Management & OMS
Confirmed in scope (per Magento Fusion SOW and additional features): Bulk AWB generation, bulk AWB printing, bulk invoice printing, shipment tracking integration. Confirm: failed AWB handling (retry, manual override), carrier failover logic, and return AWB generation for reverse logistics.
REQ-SHIP-03
Store Pickup — Fulfillment Logic
Confirm the full store pickup flow: store location inventory check in real-time, customer-selectable pickup location, pickup slot scheduling, ready-for-pickup notification (SMS/email), pickup verification (OTP or ID check), and how partial order pickup is handled.
REQ-SHIP-04
Delivery Slot Scheduling
"Scheduled Delivery" is mentioned but not specified. Confirm: customer-selectable delivery windows, calendar integration with warehouse capacity, cut-off times per region, and same-day/next-day eligibility logic.
Who is responsible for setting up merchant accounts with Aramex, Barq, and Ajex — client or vendor? Are shipping costs passed through at cost or marked up?
Is the shipping integration using each carrier's native API or an aggregator (Shipsy, Bosta, etc.)? Native APIs require separate onboarding with each carrier.
Section 9
Business Rules Engine
REQ-BRE-01
Rules Engine Capability
Define what business rules can be configured by the client's operations team without developer involvement: shipping eligibility by product/region/weight, free shipping thresholds per store, COD availability by city/region, product-level promotion exclusions, customer group–based pricing, and tax calculation rules per GCC country.
REQ-BRE-02
Admin Configurability
All business rules must be configurable from the Magento Admin UI without code changes. Rules must be testable in staging before applying to production. Changes must be audited (who changed what, when).
Section 10
Customer Experience
REQ-CX-01
Arabic RTL — Full Parity
The Arabic store view must have full RTL parity with the English version. This includes: checkout flow, email templates, SMS notifications, PDF invoices, error messages, push notifications, and mobile app screens. RTL must be validated by a native Arabic speaker as part of UAT.
REQ-CX-02
Page Templates in Scope
Vendor must list all page templates included in the UI/UX scope: Homepage, Category, Product Detail, Search Results, Cart, Checkout (multi-step), Order Confirmation, My Account (dashboard, order history, addresses, returns), Wishlist, CMS pages (About, Contact, FAQ, Terms, Privacy, Size Guides), 404, and Maintenance mode.
REQ-CX-03
Wishlist, Compare & Save for Later
Confirm whether wishlist (shareable), product comparison (min 3 products), and save-for-later (move from cart to wishlist) are in scope. These are standard conversion features that must not become change requests.
Section 11
Customer Accounts
REQ-ACCT-01
Account Features
Confirm all customer account features: registration (email, mobile OTP, social login), profile management, multiple saved addresses, order history with reorder functionality, return/refund request submission, loyalty points balance, store credit balance, communication preference management, and account deletion (PDPL compliance).
REQ-ACCT-02
Social Login
Confirm which social login providers are in scope: Google, Apple (mandatory for iOS), and optionally Meta. Apple Sign-In is an App Store requirement for any app offering social login — this must be implemented if Google or Meta login is included.
How are existing customer accounts migrated from the current platform? Are passwords migrated (hashed) or do customers receive a password reset email? Who handles the migration communication?
Section 12
Reviews & Ratings
REQ-REV-01
Reviews Platform — Stamped.io vs Yotpo
The proposal lists both Stamped.io and Yotpo but does not commit to either. The contract must specify which platform is integrated. Both have significantly different pricing and feature sets. Confirm: verified purchase badge, star ratings, written reviews, photo/video review support, Arabic language support, moderation tools, and review widgets on product pages and category pages.
Are existing product reviews from the current platform migrated to the new reviews system? What is the migration format and who is responsible?
Section 13
Customer Service & Case Management
REQ-CS-01
CRM / Helpdesk Integration
The proposal has no mention of a CRM or helpdesk system. Customer service agents must be able to see order status, payment history, and return requests without logging into Magento Admin. Confirm whether Zendesk, Freshdesk, or another platform integration is in scope. If not, this is a critical operational gap.
REQ-CS-02
WhatsApp Integration
WhatsApp is listed as a notification channel. Confirm: order confirmation via WhatsApp, shipping updates, return request updates, and CS team–to–customer WhatsApp from admin panel. Specify whether this uses WhatsApp Business API (requires Meta approval, typically 4–8 weeks) — this approval timeline must be factored into go-live planning.
REQ-CS-03
Order Cancellation & Returns
Define the full returns journey: customer initiates return online, CS agent approval workflow, return label generation (reverse AWB), warehouse receiving confirmation, refund trigger, and ERP reconciliation. Confirm this is in scope or explicitly out of scope.
Section 14
Personalization
REQ-PERS-01
Amazon Personalize — Scope & Cost
Amazon Personalize is mentioned but not specified. Confirm: which recommendation types are implemented (similar items, frequently bought together, recommended for you, trending), minimum dataset size required for meaningful recommendations, approximate monthly AWS cost at expected traffic volumes, and cold-start strategy for new users and new products.
REQ-PERS-02
Segmentation
Confirm whether customer segmentation (by purchase history, geography, RFM score, device type) is available in Magento Admin for targeted pricing and promotions.
Section 15
ERP Integration (Oracle Fusion)
Note: The Magento-side integration SOW (v1.0) is the most technically rigorous document in the package. The requirements below augment and fill gaps in that SOW. The Oracle Fusion–side SOW is outside V4Tech's scope and must be reviewed separately with the Fusion implementation team.
REQ-ERP-01
Returns & Refunds Channel to ERP
The integration SOW defines two channels: A (Fusion → Magento product/price/inventory) and B (Magento → Fusion order export). There is no Channel C for returns, refunds, or credit memos syncing back to Oracle Fusion. This is a critical financial reconciliation gap. Define: return order creation in Fusion, credit memo sync, inventory return to warehouse, and refund financial posting.
REQ-ERP-02
Invoice Sync from ERP to Magento
The proposal mentions "Invoice" in ERP sync but the integration SOW does not define an invoice sync channel. Confirm: does Oracle Fusion generate the tax invoice and push it to Magento, or does Magento generate invoices independently? VAT invoice compliance in KSA (ZATCA e-invoicing, Fatoorah Phase 2) requires clarity on which system generates and stores the legally valid invoice.
REQ-ERP-03
ZATCA (Fatoorah) Phase 2 E-Invoicing Compliance
Saudi Arabia's ZATCA e-invoicing Phase 2 (integration phase) requires real-time invoice submission to ZATCA before issuance to the customer. Confirm: which system (Magento or Oracle Fusion) submits invoices to ZATCA, who is responsible for ZATCA integration, and whether this is in Phase 1 scope. Non-compliance carries significant fines.
REQ-ERP-04
Inventory Sync Frequency & Latency
The integration SOW states Oracle Fusion calls Magento REST API "on a schedule" but does not define the frequency. For retail, stock-out scenarios require near-real-time inventory. Confirm: sync frequency (5 min? 15 min? real-time webhook?), maximum acceptable latency, and how overselling is prevented during high-traffic events.
REQ-ERP-05
Customer Data Sync
The proposal mentions "Customer data: Seamless syncing" but the integration SOW does not define a customer sync channel. Confirm direction: does Magento push new customers to Oracle Fusion, or does Fusion pull? What customer fields are synced (name, email, phone, address, customer group)? Is this real-time or batch?
REQ-ERP-06
Integration Health Dashboard
The Magento Admin order staging dashboard (defined in the integration SOW) covers orders. Require an equivalent dashboard for product/inventory sync failures, with alert email and SMS to the operations team when sync error rates exceed 5% per hour.
Section 16
Integration Monitoring & Error Handling
REQ-MON-01
Integration Monitoring Stack
Confirm what monitoring tools are in scope: AWS CloudWatch for infrastructure metrics, custom dashboards for ERP sync status, real-time alerting via SNS/PagerDuty/email for P1 failures, and log retention policy (minimum 90 days for compliance).
REQ-MON-02
Dead Letter Queue & Manual Replay
The integration SOW defines dead-letter logging for product sync failures. Require the same mechanism for all integration channels (orders, customers, inventory). Dead-letter records must be reviewable and individually re-triggerable from Magento Admin without developer involvement.
REQ-MON-03
Payment Gateway Error Monitoring
Payment failures must be logged with error codes, amounts, and timestamps. Operations team must receive daily payment failure reports. Failure patterns (specific error codes spiking) must trigger automated alerts.
Section 17
Search, Merchandising & Discovery
REQ-SRCH-01
Elastic Suite Specification
Elastic Suite (Elasticsearch-based) is listed as the search engine. Confirm: Arabic language tokenization and stemming support, fuzzy search (typo tolerance), synonym management (admin-configurable), searchable attributes configuration, instant search / autocomplete, "Did you mean?" suggestions, and out-of-stock product handling in search results.
REQ-SRCH-02
Merchandising Rules
Confirm admin-configurable merchandising: pin/boost specific products to top of category, bury out-of-stock items, create visual merchandising rules by date range, and override search ranking for specific queries. This must be operable by the eCommerce team without developer involvement.
REQ-SRCH-03
Layered Navigation & Filters
Confirm: multi-select filters, price range slider, color/size swatch filters, filter persistence in URL (bookmarkable/shareable), and filter SEO optimization (canonical tags to avoid duplicate content from faceted navigation).
Section 18
SEO Requirements
REQ-SEO-01
URL Migration & Redirect Mapping
Replatforming without a 301 redirect strategy will result in catastrophic organic traffic loss. Vendor must: audit all existing indexed URLs before go-live, create a complete URL mapping document (old URL → new URL), implement all 301 redirects in the new platform, and monitor crawl errors for 4 weeks post-launch. This must be an explicit deliverable in the contract.
REQ-SEO-02
Technical SEO — Confirmed Features
Confirm the following are in scope (the Magento Fusion SOW lists some): SEO-friendly URLs per store, hreflang tags for Arabic/English per country, XML sitemap per domain, robots.txt per domain, canonical tags (including for faceted navigation), Open Graph / Twitter Card meta tags, structured data / Schema.org markup (Product, Organization, BreadcrumbList), and Prerender.io for crawler SSR optimization.
REQ-SEO-03
Core Web Vitals Targets
The Next.js + headless architecture has the potential for excellent Core Web Vitals but requires explicit commitments. Require: LCP ≤ 2.5s, CLS ≤ 0.1, INP ≤ 200ms on mobile (4G) as contractual targets measured on real devices. Confirmed in Magento Fusion SOW: page load < 2 sec, uptime 99.9%.
Section 19
GEO — Generative Engine Optimization
Generative Engine Optimization is the emerging discipline of optimizing content for AI-powered search surfaces (Google AI Overviews, ChatGPT Shopping, Perplexity, Bing Copilot). This is not addressed anywhere in the vendor proposal but is a forward-looking requirement for a platform launching in late 2026.
REQ-GEO-01
Structured Content for AI Surfaces
All product pages must have complete Schema.org Product markup including: name, description, image, offers (price, currency, availability, priceValidUntil), aggregateRating, and brand. FAQ schema on relevant content pages. Organization schema on homepage and About page.
REQ-GEO-02
llms.txt Implementation
Implement an llms.txt file at the domain root to guide LLM crawlers on which content is authoritative and shareable. Define which product categories and brand content should be discoverable by AI systems.
REQ-GEO-03
Content Authority Signals
Product descriptions must be unique, substantive (minimum 150 words), and written in natural language that answers real customer questions. Avoid duplicate content across Arabic and English versions — translate meaningfully, not literally. This content strategy must be agreed with Ajlan & Bros' content team before launch.
Section 20
AI Search Optimization
REQ-AI-01
Knowledge Graph Readiness
Brand entity disambiguation: ensure Ajlan & Bros appears correctly in Google Knowledge Graph as a distinct entity from individual brand lines. Use sameAs properties in Organization schema linking to Wikidata, LinkedIn, and official social profiles.
REQ-AI-02
AI-Readable Product Data
Product titles must follow a consistent pattern (Brand + Type + Key Attribute) that AI search systems can parse. Attributes (material, color, size, origin) must be structured in machine-readable format (JSON-LD) in addition to being displayed on the page.
Section 21
Mobile Applications
REQ-MOB-01
App Store Account Ownership
Apple Developer Account and Google Play Console Account must be registered in Ajlan & Bros' name before development begins. Vendor acts as an authorized developer within the client's accounts. If vendor registers the accounts, Ajlan & Bros cannot publish updates, respond to reviews, or transfer the app without vendor cooperation.
REQ-MOB-02
Mobile Feature Parity
Vendor must provide a feature parity matrix confirming which web features are in the mobile app. Specifically confirm: full checkout including all payment methods, push notifications (promotional and transactional), biometric login (Face ID, Touch ID, fingerprint), deep links, Arabic RTL support on all screens, and offline browsing of recently viewed products.
REQ-MOB-03
Push Notification Infrastructure
Confirm push notification provider (Firebase FCM for Android, APNs for iOS), notification categories (order updates, promotional, abandoned cart, back-in-stock), opt-in/opt-out management in account settings, and rich push (image + CTA button) support.
REQ-MOB-04
App Store Review Timeline
Apple App Store review averages 2–3 days but can take up to 2 weeks for first submission or if the app is rejected. The go-live plan must include buffer time for App Store review. Rejection is common for apps that don't meet Apple's guidelines — confirm vendor has experience with Flutter apps on the App Store and their historical approval rate.
REQ-MOB-05
App Analytics
Mobile app must integrate with Firebase Analytics (or equivalent) with eCommerce events matching the web GA4 schema so that cross-channel reporting (web + app) is possible in a unified dashboard.
Section 22
Marketplace Integrations
REQ-MKT-01
Marketplace Scope Undefined
Marketplaces are listed as a channel in the project context but are not mentioned anywhere in V4Tech's proposal. Clarify: is Noon.com (KSA/UAE) integration in scope? Amazon.sa? Salla? Each marketplace has a separate seller API, product feed format, order management system, and shipping requirements. None of this is scoped or costed. If marketplace integrations are required in Phase 1 or Phase 2, they must be added as a separate work item with full specification.
Section 23
Reporting & Analytics
REQ-REP-01
AWS QuickSight — Scope & Cost
The Magento Fusion SOW references AWS QuickSight for advanced reporting. Confirm: which datasets are connected (Magento orders, ERP inventory, shipping), which reports are pre-built vs. client-configurable, AWS QuickSight subscription cost, and who builds the initial dashboards (vendor or client).
REQ-REP-02
GA4 Enhanced Ecommerce
GTM integration is confirmed. Require full GA4 Enhanced Ecommerce event implementation: view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info, purchase, refund. All events must fire on both web and mobile app. A GA4 measurement plan document must be delivered as a project handover item.
REQ-REP-03
Operational Reports (OMS)
Per the Magento Fusion SOW, confirm the following OMS exports are in scope: AWB number export, SKU/order status report, city/address report, daily sales by country/store, hourly sales monitoring, and saleable quantity monitoring per country.
Section 24
Data Migration
This is the single most dangerous gap in the entire proposal. Zero mention of data migration from the existing Magento platform. This is not optional — it is mandatory for business continuity. A separate Data Migration SOW is required before signing.
REQ-MIG-01
Data Migration Scope
The following data must be migrated from the current Magento PWA platform: Products (all attributes, images, categories, variants), Customer accounts (hashed passwords, address books, customer groups), Order history (minimum 3 years), Product reviews and ratings, CMS pages and static blocks, URL rewrites (for SEO continuity), Promotions and coupon codes (active ones), Loyalty points balances (if applicable), and Wishlists.
REQ-MIG-02
Migration Strategy & Rollback
Define: migration approach (big bang vs. phased), data validation methodology (row counts, spot checks, automated comparison scripts), rollback plan if migration fails, downtime window for cutover, and post-migration data integrity sign-off process. Migration must be executed in staging first with client sign-off before production cutover.
Section 25
Environment & DevOps
REQ-DEV-01
Environment Architecture
Require four environments as a minimum: Development (vendor development), Staging/UAT (client testing, production-equivalent data), Pre-Production (optional but recommended for load testing), and Production. The Magento Fusion SOW and the standalone Magento SOW both recommend 3 environments — this should be standard. Confirm each environment has its own integration tokens, payment gateway sandbox, and shipping carrier test accounts.
REQ-DEV-02
CI/CD Pipeline
GitHub Actions is confirmed as CI/CD tool. Require: automated test suite execution on every PR, deployment to staging on merge to main, manual approval gate before production deployment, automated rollback trigger on health check failure, and deployment notifications to the project Slack channel.
REQ-DEV-03
Git Repository Ownership
All Git repositories (Magento backend, Next.js frontend, Flutter mobile, Golang middleware, infrastructure-as-code) must be hosted in a GitHub/GitLab organization owned by Ajlan & Bros. Vendor team members are added as collaborators. No exceptions.
Section 26
Testing & Acceptance Criteria
REQ-TEST-01
Go-Live Acceptance Criteria
The proposal has no acceptance criteria. The following must be defined and signed by both parties as the go-live gate: All P1 and P2 bugs resolved, Payment gateway end-to-end test with real transactions (SAR 1 test purchases), ERP integration end-to-end test per country, Shipping carrier AWB generation and tracking test, Mobile app approved on both App Store and Play Store, Core Web Vitals within target on production, Load test passed (define peak traffic scenario), Security VAPT completed with all Critical/High findings resolved, and UAT sign-off from Ajlan & Bros' team on all critical user journeys.
REQ-TEST-02
Load Testing
Define peak traffic scenarios: expected concurrent users on a normal day, expected peak during campaigns (National Day, Ramadan, White Friday). Load test must simulate these peaks with auto-scaling enabled. Failure criteria: response time > 2s at peak, error rate > 0.1%, or any P1 error.
REQ-TEST-03
UAT Process
UAT must be conducted in the staging environment with production-equivalent data. Ajlan & Bros' team must have minimum 2 weeks of UAT time before go-live. All UAT defects must be logged in a shared tracking system (Jira/Trello). P1 defects must be fixed before UAT sign-off. P2 defects must have an agreed fix timeline. P3 defects can be deferred with client agreement.
REQ-TEST-04
Code Coverage
The Magento integration SOW sets a minimum of 80% unit test code coverage for the ERP bridge module. Require this same standard for all custom modules developed by V4Tech. Test suite must be delivered as part of handover.
Section 27
Training & Documentation
REQ-TRAIN-01
Training Plan
The proposal has no training plan. Require: Admin training for eCommerce operations team (catalog management, order processing, promotions, reports), Technical handover session for client's IT team (deployment process, monitoring dashboards, integration management), Mobile app OTA update process training, and Training materials in both English and Arabic. Minimum training hours must be specified in the contract.
REQ-TRAIN-02
Technical Documentation
The following must be delivered as part of the handover package: System architecture document, API documentation (OpenAPI/Swagger), Database schema documentation, Integration interface specifications (Magento ↔ Fusion payload contracts), Deployment runbook, Monitoring and alerting runbook, AWS infrastructure documentation, and Custom module documentation for all V4Tech-developed modules.
Section 28
Go-Live & Hypercare
REQ-GL-01
Hypercare Period
The Magento integration SOW includes a 4-week hypercare period. V4Tech's proposal provides only 1 month of warranty with no hypercare definition. Require: a dedicated hypercare period of minimum 4 weeks post go-live with defined escalation paths, on-call availability for P1 incidents, daily stand-up calls for the first 2 weeks, and a formal hypercare exit criteria.
REQ-GL-02
Go-Live Runbook
A detailed go-live runbook must be prepared and shared 2 weeks before cutover. It must cover: DNS cutover sequence, SSL verification, payment gateway activation (live mode), smoke test checklist, rollback trigger criteria, and on-call contact list. A go/no-go meeting must be held 48 hours before cutover with all stakeholders.
REQ-GL-03
SLA Table — Post Go-Live
The SLA plan (SAR 20,000/month) must include a defined SLA table. Require: P1 (site down/payment processing failure) — response 15 min, resolution 4 hours; P2 (major feature unavailable) — response 1 hour, resolution 24 hours; P3 (minor bug) — response 4 hours, resolution 5 business days. Working hours must be extended to 7 days for the first month post-launch.
Section 29
Ownership & Administrative Access
| Asset | Required Owner | Current Proposal Status | Action Required |
|---|
| Source Code (all repos) | Ajlan & Bros | ⚠️ Conditional — tied to support contract | Remove condition. Client owns code unconditionally upon final payment. |
| Git Repositories | Ajlan & Bros | ❌ Not stated | All repos in client GitHub/GitLab org from day one |
| AWS Account(s) | Ajlan & Bros | ❌ Not stated | Client root account. Vendor as IAM user only. |
| AWS Billing | Ajlan & Bros | ❌ Not stated | Client pays AWS directly, not via vendor markup |
| Apple Developer Account | Ajlan & Bros | ❌ Not stated | Registered in client name before development |
| Google Play Console | Ajlan & Bros | ❌ Not stated | Registered in client name before development |
| Domain & DNS | Ajlan & Bros | ✅ Confirmed | Client manages DNS; vendor requires access for setup only |
| SSL Certificates | Ajlan & Bros | ❌ Not stated | Issued via ACM (AWS) or Let's Encrypt in client account |
| Google Analytics 4 Account | Ajlan & Bros | ❌ Not stated | Client property; vendor as Editor only |
| Google Tag Manager Container | Ajlan & Bros | ❌ Not stated | Client account; vendor as Editor only |
| Google Search Console | Ajlan & Bros | ❌ Not stated | Client account per domain |
| Magento Admin (super admin) | Ajlan & Bros | ❌ Not stated | Client must have super admin credentials from day one in staging |
| Database Root Access | Ajlan & Bros | ❌ Not stated | Client IT team must have root access to all databases |
| Elasticsearch/Elastic Suite | Ajlan & Bros | ❌ Not stated | Client-owned AWS OpenSearch or Elastic Cloud subscription |
| Redis (ElastiCache) | Ajlan & Bros | ❌ Not stated | Client AWS account |
| Payment Gateway Merchant Account | Ajlan & Bros | Assumed | Confirm client is merchant account holder, not vendor |
| Stamped.io / Yotpo Account | Ajlan & Bros | ❌ Not stated | Client subscription; vendor integrates only |
| Amazon Personalize | Ajlan & Bros | ❌ Not stated | Must be within client's AWS account |
Section 30
Vendor Assumptions That Must Be Challenged
ASS-01
"Requirements once frozen shall not undergo major changes"
This is a vendor-protective assumption that shifts all risk to the client. In an enterprise replatforming, requirements evolve. Require: a formal change management process rather than a freeze-or-pay model. Discovery phase must be long enough (minimum 4 weeks) to produce complete requirements before development begins.
ASS-02
"Client shall provide clear, detailed requirements"
The vendor's proposal was submitted without having received detailed requirements — meaning V4Tech scoped and priced the project based on their own assumptions. The proposal price may not cover actual client requirements. A proper requirements discovery phase must precede final pricing.
ASS-03
"Client shall promptly deliver credentials by kickstart date"
This is a valid dependency but must be bilateral — vendor must also commit to resource availability on the kickstart date and not re-assign team members to other projects during this engagement.
ASS-04
Timeline starts from "UX/UI approval AND requirements freeze"
This means the 16-week clock has not started. If UX/UI approval takes 4 weeks and requirements freeze takes another 2 weeks, the effective delivery date is 22+ weeks from signing. Require a hard calendar date for go-live, not a relative timeline.
Section 31
Critical Dependencies
| Dependency | Owner | Required By | Risk if Delayed |
|---|
| Oracle Fusion inventory org codes + BU codes for 5 countries | Oracle/Client ERP Team | End of Phase 1 Discovery | Order export module development blocked |
| Oracle Fusion pricing model confirmation (per-country or shared) | Client ERP Team | End of Phase 1 Discovery | Price sync implementation blocked |
| Order payload contract sign-off (Magento ↔ Fusion) | Shared (V4Tech + Fusion team) | End of Phase 1 Discovery | ERP bridge development blocked |
| Staging database server provisioning | Client IT Team | Before Phase 2 (Env Setup) | Integration testing cannot begin |
| Payment gateway merchant account setup | Client Finance/Treasury | Week 6 | Payment integration development blocked |
| WhatsApp Business API approval (Meta) | Client | Week 1 (apply immediately) | 4–8 week approval window; missed go-live target |
| Apple Developer Account creation | Client IT/Legal | Week 1 | Flutter development cannot target iOS without valid provisioning profiles |
| Google Play Console account | Client IT/Legal | Week 1 | Android deployment blocked |
| Shipping carrier accounts (Aramex, Barq, Ajex) | Client Operations | Week 6 | Shipping integration development blocked |
| Domain transfer/DNS access | Client IT | Week 14 (cutover) | Go-live blocked |
| ZATCA Fatoorah Phase 2 integration | TBD | Pre go-live | Legal/compliance risk for KSA operations |
| SMS gateway (Value First) account | Client | Week 6 | OTP and transactional SMS blocked |
Section 32
What Must Be Explicitly Out of Scope (and Costed Separately)
OOS-01
Items That Are Likely Out of Scope But Must Be Confirmed
The following items are NOT mentioned in the proposal and are likely out of scope. Each must be explicitly confirmed as out-of-scope or added to the contract:
• Data migration from current platform
• Qitaf loyalty integration
• Marketplace integrations (Noon, Amazon.sa, Salla)
• ZATCA Fatoorah Phase 2 e-invoicing
• CRM / helpdesk integration (Zendesk, Freshdesk)
• Product photography or content creation
• Return-to-warehouse reverse logistics setup
• Magento/Adobe Commerce license purchase
• Third-party SaaS subscriptions (Prerender.io, Yotpo, Hotjar, Mixpanel, etc.)
• AWS monthly infrastructure costs
• WhatsApp Business API monthly costs
• SMS gateway per-message costs
• Post-hypercare bug fixes (after 1-month warranty)
Deliverable E
Additional Recommendations
🛑 Before Signing — Non-Negotiable
- Resolve the payment discrepancy in the financial table (SAR 357,344 vs. SAR 257,344)
- Get a written, detailed SLA table signed as an exhibit
- Confirm AWS accounts will be in Ajlan & Bros' name
- Remove the source code hostage clause
- Add data migration as a separate scoped SOW
- Require a VAPT commitment before go-live
- Add ZATCA Fatoorah compliance responsibility
- Confirm mada payment method in KSA scope
- Add a 4-week hypercare period to the contract
- Extend warranty to minimum 3 months
⚡ Timeline Reality Check
16 weeks for this scope is achievable only if all of the following are true simultaneously:
- Requirements are 100% complete at kickoff
- No change requests during development
- All credentials delivered in Week 1
- Oracle Fusion team delivers API specs in Week 2
- No App Store rejection
- UAT team available and responsive
A realistic Phase 1 timeline for this scope is 22–28 weeks. Build this into the contract or accept the risk of a delayed go-live.
📋 Procurement Process Recommendation
- Conduct a formal Discovery Phase (4 weeks, paid) before finalizing the SOW
- Run Phase 1 (KSA) and Phase 2 (GCC) as separate contracts with separate sign-offs
- Retain a technical advisor to review the final contract and architecture
- Establish a joint steering committee with V4Tech and Oracle Fusion teams
- Create a risk register and review it weekly
🔍 Due Diligence Checklist
- Request 3 reference clients with similar-scale headless Magento + Flutter projects
- Request the team CVs and confirm key resources are not freelancers
- Confirm team is not double-booked on another enterprise project during this engagement
- Review V4Tech's existing Magento headless live sites for performance benchmarks
- Confirm V4Tech has experience with Oracle Fusion integration (not just generic ERP)
- Verify Flutter app published on App Store by V4Tech with review history
Bottom Line: V4Tech's proposal represents reasonable technical capability at a competitive price for the Saudi market, but the commercial terms, support commitments, and ownership provisions are significantly below enterprise standards. The proposal is best understood as a starting point for negotiation, not a complete contract. Ajlan & Bros should not sign the current document. With the 23 critical items addressed, this can be restructured into a sound, protectable enterprise agreement.