Building HeadTeacher.ng as a Product, Not Just a WordPress Website

HeadTeacher.ng began with a publishing problem: teachers need useful classroom resources, organised well enough that they can find the right material quickly. The engineering became more interesting when the website stopped being the whole product.

Once mobile apps, offline access, curriculum versions, structured filters, downloads and thousands of lesson resources entered the picture, WordPress had to behave less like a conventional blog and more like a content platform.

Content structure became product infrastructure

A lesson note has a title and body, but those fields are not enough to power a useful teacher experience. Class, subject, term, curriculum version and week all affect how a teacher expects to browse. Those relationships therefore need to exist as dependable taxonomies or metadata rather than words buried inside prose.

That structure lets the same content serve different interfaces. The website can build useful archives and internal links around it while mobile products can request the exact subset a teacher needs.

The web product and the mobile product need the same rules

A common mistake is to expose whatever a website currently renders and call it an API. I prefer to make important rules explicit: which subjects belong to a class, how curriculum versions are separated, how lessons are ordered and what should happen when data is incomplete.

Once those rules are clear, the website and the app can look completely different without becoming logically inconsistent.

Scale changes what matters

At a few dozen posts, nearly any query feels fast. At thousands of structured resources, inefficient taxonomy queries, repeated API calls, image handling and cache invalidation become visible. Performance has to include database access patterns, payload size, cache boundaries and what the client can safely keep offline.

Publishing tools became part of the product

A large resource library is difficult to maintain manually. I built supporting tools for content quality, taxonomy repair, curriculum migration, canonicalisation, week assignment and app-facing filters because administrative tooling eventually determines the quality of the public product.

The lesson I keep returning to

WordPress can be a strong application platform when the data model, APIs and editorial workflow are designed around the product that depends on them. The interesting engineering is rarely the CMS itself; it is the set of contracts that keep content, people and interfaces aligned as the product grows.