These are the things that made the biggest difference on the sites I rebuild.

Make every page a plain HTML file

Almost nothing on a school website changes between visitors. Fees, curriculum, staff and admissions steps are the same for everyone. So every page is generated once at build time and served as static HTML.

With Next.js that is the default for any page that doesn't fetch per request. The result is a page that is ready the moment it arrives, with nothing to wait for.

Ship almost no JavaScript

On the newest builds the only JavaScript in the browser is the mobile menu, the enquiry forms and a click-to-play video. Everything else is HTML and CSS.

That rules some things out:

• No CSS framework. The whole design system is one stylesheet of custom properties.
• No third-party scripts by default. Every chat widget and tracker has to earn its place, because each one is code the page has to download and run before it settles.
• No video that loads on page open. A poster image shows until someone presses play.

Fix the images first

The single heaviest file on one of the old sites was a 5 MB PNG on the home page. Converting heavy images to WebP, sizing them for where they actually appear, and lazy-loading anything below the fold usually does more than any other change.

A quick way to find them: open the network tab, sort by size, and look at the top five.

Technical SEO for local search

Parents search for things like "British school in Ajman" or "CBSE school in Al Qusais". To show up, a page needs to say clearly what and where the school is:

• A unique title and description for every page, written for a parent, not for a keyword list.
• Structured data that marks the site as a school, with its address and curriculum.
• A sitemap generated from the same data as the pages, so it is never out of date.
• Real text on the page. A curriculum described in an image is invisible to search.

Keep content out of the components

Every fact on the site lives in a data file: fees, staff, the curriculum, policies, contact details. The components only arrange it.

That means updating next year's fees is an edit to one file, and the sitemap, the structured data and the page all change together.

The checklist

If I had to fit this on a sticky note:

1. Static HTML for every page.
2. JavaScript only where something is interactive.
3. Images in WebP, sized correctly, lazy below the fold.
4. A real title, description and structured data on every page.
5. Content in data, not in components.

None of this needs a new framework. It mostly needs saying no to things.

So I am building Sandglass, a focus app made for the Gulf. These are the parts that were more interesting to build than I expected.

Calculating prayer times on the device

Prayer times depend on where you are and on the calculation method, so the obvious approach is to call an API. I didn't want to. An API means a network round trip, a failure mode, and a reason the app can't work offline.

Instead Sandglass uses adhan, a small library that does the astronomy in JavaScript. You give it coordinates, a date and a method, and it gives you times.

import { Coordinates, CalculationMethod, PrayerTimes } from 'adhan';

const dubai = new Coordinates(25.2048, 55.2708);
const params = CalculationMethod.Dubai();
const times = new PrayerTimes(dubai, new Date(), params);

times.nextPrayer(); // 'asr'

Each emirate has its own coordinates in the app, so someone in Fujairah gets Fujairah's times, not Dubai's. No location permission needed: you pick your city once.

A timer that survives background tabs

Browsers slow down timers in background tabs. If you count down by subtracting one every second with setInterval, a 25-minute session in a background tab can quietly take 30.

The fix is to never count. Sandglass stores when a session started and how long it should last, and works out the remaining time from the clock every time it draws:

const remaining = Math.max(0, session.endsAt - Date.now());

The interval only decides how often the screen updates, not how much time has passed. Close the laptop, come back, and the timer is right.

Arabic is a layout, not a translation

Translating the strings was the easy part. Arabic reads right to left, so the whole layout has to mirror: the timer controls, the task list, the progress bar, even which side a panel slides in from.

Setting dir="rtl" on the page does most of the work, as long as the CSS uses logical properties like margin-inline-start instead of margin-left. Anything written with left and right had to be rewritten. It is worth doing from the first line of CSS.

No account needed

Sandglass works fully as a guest. Everything is saved in the browser. If you sign in, your data syncs through Supabase, with row-level security on every table so no one can read anyone else's sessions.

Most people trying a focus app will not make an account first. Asking them to is the fastest way to lose them.

Small things that make it feel finished

• Share cards for a focus streak are drawn on a Canvas at 1080×1920, the size Instagram stories expect, so they look sharp when posted.
• The ambient sounds are generated with the Web Audio API instead of shipped as audio files. The app stays small and the sound never loops audibly.
• It installs as a PWA, so it sits on your home screen like any other app.

Sandglass is still in development. If you work or study in the UAE and want to try it early, email me.

You can try to enforce that in the front end. It works right up until someone opens the network tab. So the rule lives in the database instead.

Why the database, not the app

The app is Next.js talking to Supabase, which is Postgres underneath. Supabase gives every signed-in user a token, and Postgres can read who that user is on every query. Row-level security (RLS) lets you attach a condition to a table that Postgres checks on every row, for every query, no matter where the query comes from.

That means the app code can ask for "all leads" and still only get the right ones. There is no way to forget the filter, because the filter is not in the app.

The shape of it

Every staff login has a profile with a role and a campus. A lead belongs to a campus. The policy for reading leads says: you can see a row if it belongs to your campus, or if you are a super admin.

alter table leads enable row level security;

create policy "Read own campus leads" on leads
  for select using (
    exists (
      select 1 from profiles p
      where p.id = auth.uid()
        and (p.role = 'super_admin' or p.school_id = leads.school_id)
    )
  );

Notes, the activity log and appointments follow the same pattern, so a lead's history is exactly as private as the lead.

One rule I learned the hard way: keep the policy on profiles itself simple. If a policy on profiles reads profiles again, Postgres can end up recursing, and the error you get is not obvious. Read your own row by auth.uid() and stop there.

A role that can write but not read

Leads also arrive from Facebook and Instagram ads. An outside social media agency exports them from Meta Ads Manager as a CSV, and someone has to get that file into the system.

I did not want that agency to be able to browse leads, phone numbers or notes. So their login gets a socials role with no select policy on leads at all. Without a policy, Postgres returns nothing.

Importing goes through one function instead of a direct insert:

create or replace function import_social_leads(target_school uuid, rows jsonb)
returns integer
language plpgsql
security definer
set search_path = public
as $$
begin
  -- check the caller really has the socials role, skip duplicates,
  -- tag each lead as facebook or instagram, then insert
  ...
end;
$$;

security definer means the function runs with its owner's rights, so it can insert into a table the caller cannot read. The caller gets back a count of rows imported and nothing else. They can do the one job they need to do, and that is all.

Migrations you can run twice

Every change to the schema is a plain SQL file, and every statement in it is safe to run again: create table if not exists, create or replace function, and drop policy if exists before each create policy.

That sounds fussy, but it means anyone on the team can paste a migration into the Supabase SQL editor without worrying about whether it already ran. In a small team without a release process, that matters more than any tooling.

What I would tell myself at the start

• Put access rules in the database from day one. Retrofitting them is much harder than writing them first.
• Test policies by signing in as each role and trying to break them, not by reading the SQL.
• When a role needs to write data it should not see, give it a function, not a table.