English
العربية
Deutsch
EspañolNext.js in Jeddah
Next.js development for Jeddah retail and commerce
A Next.js development company working with Jeddah retailers and commerce groups. Traffic that multiplies for one month a year, concentrated after sunset, on mid-range phones.
- Working day overlap
- Nearly complete. Jeddah keeps effectively the same clock as Ankara, with four fully shared working days
- Who buys here
- Retail groups, family conglomerates, distributors and commerce platforms - the private sector rather than the programme office
- What that changes
- Capacity planning is annual rather than gradual, because the largest month of the year is known in advance and arrives all at once
- Local specifics
- Most of the audience is on a mid-range phone, so the JavaScript budget is a commercial number rather than an engineering preference
Jeddah is the commercial half of Saudi Arabia, and the work that arrives from it looks nothing like the work that arrives from Riyadh.
Riyadh buys through programmes. Jeddah buys because somebody is selling something and the storefront is costing them money. The buyers are retail groups, family-owned conglomerates, distributors and commerce platforms, and their problems are the problems of consumer traffic rather than of procurement.
One month a year decides the architecture
Most commerce sites grow gradually and can be scaled gradually. A Saudi storefront has a month where everything multiplies, and it is known about in advance.
That changes the right answer. If pages are generated on first request, the site does its most expensive work exactly when demand peaks - every product page nobody happened to visit in the last hour is a cold build while a thousand people wait. The architecture that holds is one where the pages that matter already exist before the month starts, and revalidation runs on a schedule the business controls rather than being triggered by whoever arrives first.
That is a decision about how caching and revalidation actually work, taken in the quiet part of the year. Taken during the spike, it is an incident.
The spike moves, so the date cannot be hard-coded
Ramadan follows the lunar Hijri calendar, so it arrives roughly eleven days earlier in each Gregorian year.
This sounds like trivia and it quietly breaks things. A cache-warming job scheduled for March is in the wrong place by the following year. A promotional banner with a hard-coded end date expires mid-campaign. A capacity plan written once is wrong twice.
The reliable approach is to treat the date as data the business provides for the year ahead, not as a calculation. Nothing in the codebase should be deriving a lunar date from a Gregorian one.
Jeddah shoppers are on mid-range phones
The second thing that separates this market from a European one is the device.
A site built and tested on a developer's laptop behaves completely differently on a mid-range Android handset, where the cost of parsing and executing JavaScript is several times higher. This is where the server-first default of the App Router earns its keep - a product description rendered on the server costs the phone nothing, and the same description rendered by a client component costs it a bundle download, a parse and a hydration pass.
So the rule on these projects is that interactivity has to justify itself. A size selector or a filter panel genuinely needs client state; a specifications table does not. The use client boundary is the lever, and on this audience it is worth more than it is in most markets.
Commercially
Scope fixed in writing before work starts, priced per project. The country-level ground - data residency, e-invoicing, Arabic interface requirements - is on the Saudi Arabia market page, and the Arabic typography and right-to-left work is set out on the Dubai page rather than repeated here.
Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars, by bank transfer, with no Turkish VAT because exported services are exempt.