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?
Default: Next.js + TypeScript + Postgres on Vercel or Netlify. For content-led platforms: Sanity, Payload, or Strapi as headless CMS. For PDPL-strict Saudi work: same stack, but on STC Cloud or Mobily in-Kingdom. For multi-region B2B: edge-deployed Next.js with country-aware routing. The stack scales from 4-week MVP to 4-year enterprise platform without rewrites.
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.