The content website plus one feature that makes the difference: maps with travel time, bookings, or media.
A catalog with a map, a site with bookings, a site with audio and ebooks.
This is where the part you cannot buy as a plugin begins. A map with travel-time estimates calibrated on real routes, a schedule read from a calendar server-side with payments, or a player whose mix is produced by the server.
Each of those features has a decision inside it that a language model will not make on its own — and that decision is what separates a demo from something that holds at a hundred users.
A site whose content you change yourself: blog, catalog, events, products. Strapi 5 for the panel, Next.js for the front.
Two separate repositories joined by an OpenAPI contract. The API publishes a static contract file, the front generates a client from it and keeps that client in its own repository.
It sounds like a detail and it decides how calm your Sundays are: the build needs no access to the API, so it is deterministic, and every change to the content model shows up as a change in the front-end code — not as a production outage.
What you getThe content model from a description of the domain, list and detail components, SEO fields, sample data migration.
Model boundaries (what is a relation and what is a component), permissions, query performance, avoiding n+1, caching and its invalidation.
A map with points, distance and drive-time estimates, "nearest to me" sorting — with no per-thousand-view bill.
Haversine gives the straight line; two custom curves turn it into road kilometres and minutes of driving. The curves are calibrated on 460 real car routes from 400 m to 500 km. Median time error: 13.6 percent, and 13.5 on routes outside the training set. Half of the estimates land within 6 minutes of a real router.
A language model will suggest calling an external routing API on every slider move. That works in a demo and stops working at a hundred users: the provider throttles you, the page slows down, and the visitor’s location leaves the browser. Our calculation happens in the browser, so the reader’s location goes nowhere.
What you getA first pass of the map, filtering and interface components.
Calibration on real routes, guards towards the data provider, the zero-coordinate filter, pin accessibility, and deferring the map past first paint.
Free slots read server-side, the date picked on your own page, and payment without leaving for an external widget.
The visitor never sees an external calendar link, only the free slots on the page. Writing the event back through a service account is optional. Stripe payments with webhook handling, an event model with dates and options (room, extras), and email confirmations.
What you getScheduler and cart components, a first pass of the integration.
State consistency under concurrent bookings, webhook handling, keeping amounts and statuses in agreement.
Proof: Payments and the calendar integration live in the repository — we show them on a call, because from the outside you cannot see them without buying something.
A player with features of its own, ebooks in many formats, heavy files kept out of the application image.
In one of the sites, the song player lets you set how loud the vocal is, in five steps. The server does the mix: ffmpeg sums the backing track with the vocal, scales the sum to the peak and puts a finished file into storage. The file name carries a hash of the sources and the recipe, so changing a recording in the panel produces a new file and the old cache simply stops being used.
Why not in the browser: audio mixed through Web Audio cannot be sent to AirPlay, because Safari does not know `AudioContext.setSinkId`. One audio element with a ready file plays everywhere. Things like that are not in the framework docs, and a language model will not check them on its own.
What you getThe player interface, format conversion, a first pass of the processing.
The decisions that are not in the docs: where to mix, how to key the cache, what to keep out of the image.
Filters, state kept in the URL, pagination, full-text search with a synonym dictionary.
Filters by category, location and tags, filter state in the address (the link can be shared), pagination or load-more, full-text search and a synonym dictionary for the words visitors use differently than the editors.
A trap we know from our own outage: a catch-all filter route caches every URL permutation a crawler invents. Ours grew to 38 GB across 1.4 million files and took five services down. So a catalog here gets `noindex, follow` on filtered views by default, an allow-list of parameter values, and a limit on what may enter the cache at all.
What you getList, filter and search components, and a first synonym dictionary.
Cache and indexing boundaries, the parameter allow-list, and query performance as the catalog grows.
Speed work measured with a tool, with a record of what helped and what did not.
Measured with the same engine as PageSpeed, locally, with the flags that cut out the browser artefact on a Mac — without them first paint lands about 1.5 s later and the whole analysis is fiction. A median of several runs, not one result, because a single run sits inside the tool’s own spread.
A result from a real project: mobile 81 → median 91 (spread 87–92), page weight 793 kB → 415 kB, fonts 166 kB → 105 kB and 10 files → 5, accessibility 96 → 100 on mobile and 92 → 100 on desktop.
What you getA first optimisation pass and spotting the obvious losses.
Measurement that tells the truth, and rejecting changes that only look good on paper. One such "57 kB saving" produced CLS 0.22 and minus 11 points — reverted.
One large or a few small ones. We settle the scope during the project review, because that is what drives the hours.
No. We use Leaflet and OpenStreetMap, so there is no per-thousand-view bill and no Google Maps keys.
We estimate in hours, after a phone call and a look at the project. Our latest projects took 15 to 45 hours.
