When you already know what you need — here's how we build it

The post-discovery technical deep-dive: stack choices, architecture documents, integration points, and what production deployment actually includes. Built for teams that have done the brief.

Architecture in 5 business days · mock server by end of week 1 · runbook on launch day.

Quick answer

Who builds custom web solutions for teams that already know what they need?

A team across Jordan, Saudi Arabia, Iraq, or the GCC that already has a brief gets a Next.js + Postgres platform, a headless storefront on Saleor or Medusa, an API-first backend, or an AI-augmented internal tool, with an architecture document in 5 business days and a mock server running by end of week 1. Ijjad architects and ships to that timeline.

  • Architecture document signed off before sprint 1; no code until the plan is reviewed.
  • Mock server running by end of week 1 so frontend builds against real contracts.
  • Production runbook delivered on launch day, not three weeks later.
  • Privacy requirements and any invoicing handoffs agreed before development, with a named approval owner.

Where this page sits in the Ijjad journey

Three Ijjad pages talk about web development, and they're intentionally not the same. web-development-services is the pre-discovery hub — for teams still deciding which agency to call. website-cost-estimator is the scope-tier overview for any project type. This page is the technical layer underneath both: the architecture documents, stack choices, integration points, and runbooks that come after the brief.

Read this if you already know you need a custom platform — B2B portal, headless storefront for a Saudi retailer, AI-augmented internal tool, multi-region rollout — and you want the engineering detail before you scope it. Skip this if you’re still evaluating agencies or pre-brief.

Custom platform outcomes

First-party, anonymized project figures reported by Ijjad. Client identities and underlying analytics are not public; the linked cases explain the project context and method.

Stack & scope tiers

Four delivery shapes for custom platforms

Pick the stack that matches your scale, compliance needs, and integration depth.

Next.js + Vercel

Content-led, conversion-focused, multi-region brands.

After scope review

6-12 weeks

  • Next.js + TypeScript
  • Vercel edge deployment
  • Headless CMS (Sanity / Payload)
  • Multi-region hreflang
  • Image optimisation pipeline
  • SEO foundations
  • Heavy editorial workflows (use Drupal)
Get Started
Most popular

Headless platform

E-commerce with custom storefronts, multi-tenant SaaS.

After scope review

8-14 weeks

  • Saleor / Medusa / Payload
  • Custom storefront (Next.js)
  • GraphQL or REST API layer
  • Stripe + Mada subscription billing
  • Webhook + queue architecture
  • Observability baseline
Get Started

Custom Postgres + Node

B2B portals, internal tools, AI-augmented platforms.

After scope review

10-16 weeks

  • Node.js + Postgres + Redis
  • Role-based access + SSO
  • Background jobs (BullMQ / Inngest)
  • Admin dashboards (Next.js)
  • API contract + OpenAPI docs
  • Audit logs + observability
Get Started

Enterprise / Gov

Ministries, regulated finance/health, multi-product platforms.

After scope review

16-32 weeks

  • Hosting region and provider agreed in scope
  • Privacy and sector requirements with named approval owner
  • Saudi National Design System alignment where required
  • SSO + RBAC
  • Multi-environment CI/CD
  • 24-month maintenance plan
Get Started

Every tier includes architecture documentation, automated CI/CD, observability, and a 30-day post-launch on-call window. You own the repo and deployment credentials on day one.

For Saudi personal-data handling, review the official Personal Data Protection Law with the person approving your requirements. Article 29 addresses transfers outside the Kingdom; selecting a hosting region does not resolve every data-flow decision.

How a custom build runs

From architecture document to production

Architecture before code. Mock server before frontend. Runbook before launch.

  1. 1

    Architecture doc

    5 business days

    Stack choices with rationale, data model, API contract, deployment topology, integration points, observability plan, and risk register. Signed off before any code begins.

    Deliverable: Architecture document + risk register.

  2. 2

    Mock server + design system

    1-2 weeks

    Backend: OpenAPI mock server running by end of week 1 so frontend can build against real contracts. Frontend: design tokens, component library, RTL parity.

    Deliverable: Mock server + design system.

  3. 3

    Build

    4-24 weeks

    Two-week sprints with weekly previews. Backend and frontend work follows the agreed architecture. Test the privacy controls and invoicing handoffs specified in the scope, with acceptance evidence reviewed by the named owner.

    Deliverable: Weekly previews + sprint demo Loom.

  4. 4

    Hardening + QA

    1-3 weeks

    Load testing, OWASP Top 10 security review, accessibility audit (WCAG 2.2 AA), bilingual QA, and per-country edge-case testing.

    Deliverable: Security report + accessibility report.

  5. 5

    Launch + ops handoff

    1-2 weeks + ongoing

    Production deploy, runbook delivery, on-call rotation setup, and 30-day post-launch window. Optional maintenance retainer stacks on top.

    Deliverable: Live platform + runbook + incident playbook.

Typical end-to-end timeline: 6-32 weeks depending on stack

First-party testimonials

What technical teams say after launch

These anonymized quotes are published by Ijjad. They are not native reviews from Google, Clutch, or another independent platform.

“Ijjad replaced an unclear website with a focused experience that gives prospects a much clearer path to contact us. The team understood our regional market and kept the work tied to the business goal.”
Business Owner, Riyadh
“We needed a website and mobile app on a tight scope. Ijjad gave us a practical plan that made sense for a startup, and Karam stayed directly involved through the important decisions.”
Startup Founder, Amman
“Ijjad rebuilt the storefront around Mada checkout and a mobile-first customer flow. The result is easier for our team to manage and clearer for customers to use.”
E-Commerce Manager, Jeddah
“We launched our online catalog with cash-on-delivery and ZainCash in one checkout. The reconciliation dashboard gives our team a clearer way to manage orders, and the Arabic checkout feels native rather than translated.”
Retail Founder, Baghdad
“The trilingual MVP treated Sorani Kurdish as a first-class language from the start rather than an afterthought. Ijjad also kept the page weight small for customers accessing it outside Iraq.”
SaaS Founder, Erbil
“We needed governorate-level shipping rules, RFP-friendly service pages, and a site that loads well on mobile connections in southern Iraq. Ijjad delivered those requirements and walked our team through the cash-on-delivery operations before launch.”
Logistics Operator, Basra

FAQ

Custom web solutions — the technical questions teams ask

How is this page different from /web-development-services and /website-cost-estimator?

web-development-services is the pre-discovery hub for teams evaluating us. website-cost-estimator is the scope-tier overview for any web project. This page is the post-discovery technical deep-dive: which stack we pick when, how the architecture document looks, and what production deployment includes. Read this when you already know you want a custom platform and want the engineering detail before scoping.

Which stack does Ijjad pick for a custom web platform?

Start with the required workflow and integrations. React and Next.js are our default for custom builds; the CMS and database depend on the content and application needs. Hosting is a separate architecture decision. Review data flows, provider access and any required deployment region before selecting infrastructure. Agree who approves the privacy requirements and acceptance criteria in the scope.

When does Ijjad recommend NOT using Next.js?

Drupal-mandated procurements (we refer to Sprintive). SAP/Oracle-driven enterprise rollouts where the web is one tile (Mozon Technologies fits better). Pure WordPress maintenance retainers (DSTeck-class agencies). Mobile-only products without a web surface. We say so explicitly — forcing the wrong stack costs a rewrite in year two.

What does a typical architecture document include?

Stack choices with rationale, data model (entity relationships + indexing strategy), API contract (OpenAPI or GraphQL schema), authentication/authorization model, integration points (payment rails, ERP, CRM, AI APIs), deployment topology, observability plan (logs, metrics, traces), and risk register. Signed off before sprint 1; no code starts until the architecture is reviewed.

Do you handle API design and third-party integrations?

Yes — about 35% of our custom-platform work is integration-heavy. Payment rails (Mada, STC Pay, Tabby, ZainCash, Stripe), ERP/CRM (SAP, Odoo, Zoho, HubSpot), AI APIs (OpenAI, Claude, Gemini), document workflows, courier APIs (Aramex, regional Iraqi couriers). Every API is versioned, documented (OpenAPI + Postman collection), and tested with end-to-end scenarios.

What does "scalable architecture" actually mean in practice?

Concrete things: connection pooling on Postgres (pgBouncer), Redis or CDN edge caching where it matters, queue-based background jobs (BullMQ, Inngest), read-replica strategy when traffic justifies it, and observability so you can find the bottleneck. Not just ”we picked microservices.” Most platforms scale fine on a single well-tuned monolith for years.

Do you take over half-built projects?

Yes, about 15% of our intake. The standard rescue process: codebase audit (Loom walkthrough in 5 business days), salvage assessment, stabilisation sprint scope, then feature work quoted separately. We'll tell you honestly if the codebase is worth saving. Sometimes the right call is a clean rewrite; sometimes incremental works.

What does post-launch ops look like?

Runbook covering deployment, rollback, incident response, common failure modes, and on-call rotation. Observability dashboards (Datadog, Grafana, or Sentry depending on scope). 30-day on-call window included. Optional maintenance retainer for ongoing security updates, monitoring, incident response, and incremental feature work. Month-to-month with 30-day notice — no lock-in.

Ready to architect the platform?

20 minutes on a technical call. Architecture document in 5 business days. Mock server running by end of week 1.