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.