A Playbook for Client Websites That Clients Can Actually Run

Not every project needs an agent swarm. Some of my most-used work is websites for Sri Lankan businesses: an HVAC company, a tour guide, an Ayurvedic hospital, a boutique resort, a payroll office, a software studio and three photographers. They have one thing in common — the client has to run it after I leave.

This is the playbook those projects converged on.

---

Rule 1 — one file the client can edit

Clean Air (HVAC, Next.js 14 App Router) has two sources of truth:

• data/data.ts — every piece of content: company info, WhatsApp number, services, areas, FAQ, testimonials, footer links.
• app/globals.css — the entire design system, in numbered sections: tokens, reset, layout primitives, typography, buttons, then one block per component family.

Office staff change prices and holiday notices in data.ts without touching JSX. Restyling the site means editing the tokens in section 1 — no component hardcodes a colour, spacing or radius. Media queries are all min-width: base rules are the phone layout.

Super King Star Holiday Resort does the same with resortData.ts — suites, dining packages and event pricing as typed records, with no database to pay for.

Rule 2 — leads go to WhatsApp, not email

In Sri Lanka, email enquiries are where leads go to die. Clean Air's quoting calculator compiles a pre-formatted WhatsApp message (service, unit type, location) and opens it for the visitor to send. Mahesh Travellers does the same for trip requests. The visitor reviews and sends the message themselves; the site stores nothing, which also means there's no personal data to protect.

Rule 3 — static unless proven otherwise

Tour itineraries change a few times a year, and the audience is in Germany and the Netherlands. Mahesh Travellers uses Next.js static export: the production site is plain files in out/, served by any static host or CDN. No server, no patching, instant loads from Europe.

It's not a small site:

• Five languages (EN, DE, NL, FR, ES) with direct /en/ … /es/ pages
• A nine-stage reference itinerary taken from Mr Mahesh's handwritten plan, plus 6/8/10/14-day journeys with daily programmes
• 19 selectable activities, 8 attraction guides, a five-part Sigiriya village tour
• Four original articles in all five languages (20 article pages)
• 24 real local photographs and locally stored fonts
• Activity selection preserved when you switch language

Photos were converted to WebP with responsive srcsets, cutting page weight by about 75%.

Rule 4 — honest content

Every trip description on Mahesh's site is written for that site, the only experience claim is the owner's own ("10 years"), and prices, hotels and tickets are explicitly "confirmed directly". A competitor directory that came with the original materials was removed. Clients notice when you protect their reputation.

---

The rest of the set

Rule 5 — the boring checklist

• Change default credentials before deploy, and keep them in env vars (Intocare's ADMIN_USERNAME, ADMIN_PASSWORD, AUTH_SECRET).
• Pooled database URL at runtime, direct URL for migrations (Neon).
• Reduced-motion support and visible focus states in the base CSS.
• A README written for the next developer — or the client's nephew.

Browse all client websites →