Work/Education
Schoolpager
A school website that runs itself: enter content once, choose any design.
LiveLive platform, with every planned build phase deployed.
Web
The problem
“Our school website died after the developer left.”
A private-school website in Nigeria is usually built once by a freelancer or agency. After that, updating it means calling the developer and paying a fee, so nobody does. The news page is years old. The site was never registered with Google, so a search for the school finds Facebook instead. Nobody remembers who bought the domain, and renewal notices go to an old address. Email is still on a free mail service. Parents compare schools on their phones and see one that looks abandoned.
Who had it
- Proprietors and principalsA website that stays current without a developer on call.
- Secretaries and ICT teachersA tool they can use from a phone to keep the site up to date.
- ParentsCurrent term dates, fees and admissions information, found easily on a phone.
What the answer had to survive
- Staff update the site from a phone
- No technical person available for each school
- Domain and certificate renewals must not be forgotten
- Fees must go straight to the school's own account
- A late payment must not take a live site down
What we built
The school keeps the facts. The platform keeps the site alive.
The school keeps what is true about itself, such as staff, programmes, fees, dates and photos, in one content library. Any design in the library can present it, and switching designs loses nothing. When the school presses Publish, the platform proves ownership to Google, submits the sitemap, issues a certificate that renews itself and sets up school email. A freshness score tells the secretary what parents would notice is missing. Fees are paid into the school's own account. A late payment makes the admin read-only first, and one payment restores everything.
AI inside Schoolpager
-
Drafts that a person approves
AI drafts headlines and summaries for a school's website. Each one stays marked Suggested until a person edits it.
What it does
Content library
- Facts entered once78 kinds of content block and 32 record collections cover staff, fees, admissions, news, events and more.
- Lossless design switchingThe design decides layout and order. The school decides only what is true. Colours and fonts are remembered per design.
- Pages appear when there is contentNo empty menus or links to blank pages. Schools can rename, hide and reorder navigation.
- Drafts, never auto-publishedAI drafts headlines and summaries, marked Suggested until a person edits them.
Getting online
- Five questions to a first draftA short wizard writes the first pages in the school's own voice.
- Import the old websitePages, staff, news and photos arrive as drafts, and old links are redirected.
- Free address, own domainEvery school gets a free address from day one. It can connect or buy a domain in the admin.
- Automatic httpsCertificates are issued and renewed by the platform, with alerts to the operator on failure.
Found and fresh
- Registered with Google on PublishOwnership is verified and the sitemap submitted. The real log shows about three minutes.
- Freshness scoreA score from 0 to 100 names the gap and offers a one-tap fix.
- Photo by emailA photo emailed from a phone becomes a captioned draft gallery item.
- Calendar draftsTerm dates are drafted ahead from a Nigerian school calendar, always as drafts.
- Owner digestA monthly or weekly email shows visits, searches, enquiries and what needs attention.
Parents and money
- Fees through the school's gatewayPayments go into the school's own bank account. Fikazon takes no cut and never holds the money.
- Verified before marked paidEach payment is checked with the provider for amount and currency first.
- PDF receiptsReceipts are emailed and downloadable without a parent account.
- Updates to parentsParents confirm by email, then receive posts from the school's own address.
School email and control
- Mailboxes on the school's domainSet up from the admin in about ten minutes, with all DNS records written and checked.
- Roles and invitationsOwner, Administrator and Editor roles. One login can manage several schools.
- Forms in one inboxApplications, visit bookings and enquiries arrive in one inbox with email alerts.
A day with it
- 1
Start a free trial
The owner opens the marketing site and starts a 14-day trial. No card is needed.
- 2
Get a first draft
The owner answers five questions, or gives the old website's address, and sees draft pages.
- 3
Fill the library
The school reviews staff, programmes, fees, dates and photos once.
- 4
Choose a design
The owner previews the same content on different designs and sets colours.
- 5
Press Publish
Within minutes the site is on https, verified with Google, with its sitemap submitted.
- 6
Stay current
The secretary posts from a phone. Parents subscribe. The owner reads a monthly digest.
How it works inside
One web application serves the school admin and every school's public site, and finds the right school from the web address. Slow work, such as domains, email and image processing, runs in the background. Outside services sit behind adapters, so a supplier can be swapped without a rewrite.
Cut the network to see what this system does without it.This one lives on the internet, so it waits, like any website. Its staying power is on our side: backups, health checks and tested recovery.
Our cloud
- Public school siteWhat parents see, on the school's free address or own domain
- School adminWhere the secretary and owner manage content, design and billing
- Schoolpager applicationContent library, design engine and school isolation
- DatabaseOne database; every record is scoped to a school
- Background workersDomains, email, crawling, images and AI drafting
- Media storage and CDNPhotos, video and documents, served close to visitors
Outside services
- DNS and certificatesDomain records and https certificates
- Google search toolsOwnership verification and sitemap submission
- Email servicesSending, school mailboxes and photo capture
- Payment gatewaysThe school's own gateway account for fees
Every part and every link, as text
- Public school site — What parents see, on the school's free address or own domain (our cloud)
- School admin — Where the secretary and owner manage content, design and billing (our cloud)
- Schoolpager application — Content library, design engine and school isolation (our cloud)
- Database — One database; every record is scoped to a school (our cloud)
- Background workers — Domains, email, crawling, images and AI drafting (our cloud)
- Media storage and CDN — Photos, video and documents, served close to visitors (our cloud)
- DNS and certificates — Domain records and https certificates (outside services)
- Google search tools — Ownership verification and sitemap submission (outside services)
- Email services — Sending, school mailboxes and photo capture (outside services)
- Payment gateways — The school's own gateway account for fees (outside services)
- Public school site → Schoolpager application: Host resolves to a school (needs internet)
- School admin → Schoolpager application: Signed-in actions (needs internet)
- Schoolpager application → Database: School-scoped reads and writes (works offline)
- Schoolpager application → Media storage and CDN: Store and serve media (needs internet)
- Schoolpager application → Background workers: Hand over slow work (works offline)
- Background workers → DNS and certificates: Write records, issue certificates (needs internet)
- Background workers → Google search tools: Verify and submit sitemap (needs internet)
- Background workers → Email services: Send and provision email (needs internet)
- Schoolpager application → Payment gateways: Check each payment (needs internet)
- Payment gateways → Schoolpager application: Payment confirmation (needs internet)
The hard parts
Facts in a library, layout in the design
- The situation
- An earlier product had templates that were the same site in different colours. Content was trapped in layout, so changing design meant rewriting pages.
- What we did
- We rebuilt around one rule: the school keeps facts in typed blocks and collections, and each design decides what shows and in what order. A linter rejects any design that breaks the rule or copies another's layout.
- The lesson
- Flexibility comes from constraints that tooling enforces, not from good intentions.
Twenty-one contracts, nobody at the keyboard
- The situation
- A site that runs itself depends on registrars, DNS, certificates, email, search and payments. Each speaks its own dialect and fails in its own way.
- What we did
- Each outside service sits behind a contract with an adapter. Adapters turn statuses and errors into one vocabulary, and schools only ever see plain English. Multi-step flows are state machines advanced by a scheduler. Tests use recorded responses.
- The lesson
- Swapping a supplier is an adapter change, not a rewrite.
Ten minutes from Publish to found, secure and emailing
- The situation
- Registering with Google, issuing a certificate and setting up correct school email is where school websites usually die. It needs a technical person per school.
- What we did
- On Publish, the app requests a verification token, serves the proof file itself, verifies ownership and submits the sitemap. It also writes the DNS records and checks mailbox records against the wider internet.
- The lesson
- A fragile expert task becomes a log line.
A crawler that learned from a real site
- The situation
- The first real import filed every page as Other, ticked nothing, then reported success. The old site routed every page through one script.
- What we did
- The classifier now reads path, query string and link text, and falls back to sub-headings. It refuses to run with nothing ticked. Paid AI calls are cached and capped per school. Imports arrive as unpublished drafts.
- The lesson
- Features are tested against messy reality, and abuse cases are closed before launch.
The stack
- Apps
- BladeAlpine.jsTailwind CSS
- Backend
- PHP 8.3LaravelQueue workersScheduler
- Data
- MySQLRedisS3-compatible object storage
- Infrastructure
- nginxUbuntusystemdNightly encrypted backups
- Services
- Domain registrarsSearch verificationEmail sendingPayment gatewaysAI drafting
- Testing
- PHPUnitRecorded provider fixturesLighthouseDesign linter
How it came together
- 1The content libraryA library of 78 kinds of content block and 32 collections was built first.
- 2Designs, domains and paymentsThe design engine, custom domains, certificates and tenant payments followed.
- 3A production homeA dedicated production server was set up with storage, email and DNS wired.
- 4Billing and a quick startPlatform billing, a quick-start wizard and an add-ons shelf were built, and the first Lighthouse run made.
- 5Keeping owners and parents informedAn owner digest, updates to parents and the marketing page were written.
- 6Accounts, roles and searchAccounts and roles were built, and the platform registered itself with Google automatically.