We learned this on three consecutive engagements: when an editorial team cannot publish without an engineer, the entire product loses operational momentum. The CMS-first architecture we now adopt by default, the trade-offs, the failure modes and the precise stack choices behind it.
By Hanova Admin
When a marketing team has to file a ticket and wait for a developer just to fix a price or publish a page, the whole product slows down. It rarely shows up on a roadmap, but it shows up everywhere else. Campaigns miss their window, a typo sits live for a week, and the people closest to the customer end up waiting on the people furthest from them.
We have seen this happen enough times that we now treat the content layer as part of the core architecture, decided up front, not bolted on once the "real" features are done.
CMS-first does not mean buying a heavy platform on day one. It means deciding, before the first page is built, that anything a non-developer will need to change lives in a structured store with its own editing screen. The homepage headline, the services, the team, the FAQs, the legal copy: all of it is data, not text baked into a component.
The opposite is what we call CMS-eventually. You ship quickly with the copy hardcoded, promise to make it editable later, and later never arrives, because every change still works when a developer does it.
For most marketing and SaaS builds in the region we use a familiar shape. Postgres is the single source of truth, with a typed schema. Prisma keeps the content models version controlled and the migrations reviewable. Next.js reads the content on each request, so an edit goes live without a redeploy. And a purpose-built admin sits behind login and roles, instead of a generic tool the client has to learn.
Building the admin ourselves costs more up front than dropping in an off-the-shelf CMS, but it pays back fast. The editing screen speaks the client's own language, shows only the fields that should change, and enforces the rules that keep the public site coherent.
Modelling has a real cost. Every editable field is a decision. Model too much and the admin becomes a chore. Model too little and you are back to developer-only changes. We make editable what will genuinely change, and keep structural layout in code.
Preview matters too, because editors will not trust a system they cannot see before publishing, so draft and published states are not optional. And roles prevent accidents. Once content is editable, you have to decide who can change what. A junior editor should not be able to take down the pricing page.
Ship the content layer first and the rest of the product inherits a pace the business can actually keep. Ship it last and you have quietly turned every future copy change into an engineering dependency. That is the difference between a site the team runs and a site the team waits on.
WordPress is fine for a weekend blog. For a business that depends on its website, custom engineering wins where it counts: speed, security, ownership and what it costs you over the years, not just at launch.
Most Kenyan businesses check how their website looks. Very few check how fast it loads. The research says speed is where the money leaks: more than half of mobile visitors leave a page that takes over three seconds.
The exact dependency list we add to every greenfield project, the rationale behind each choice and the libraries we deliberately keep out of every stack, and why.
