Design fidelity or self-editing. The platform wouldn't give both, so we asked
A US wellness and nutrition brand
The Brief
A wellness and nutrition brand needed its entire website — ten pages — rebuilt natively inside Kajabi, working from AI-generated HTML files as a design and content reference. After handover, the client had to be able to edit every page directly, with no ongoing developer dependency
Those two requirements pull against each other, and the conflict is structural rather than a matter of effort.
The reference design used custom layouts, grids, animations, and styling that Kajabi’s fixed Section-and-Block editor cannot produce natively. Matching it closely meant writing custom code. But every custom-coded section is a section the client can no longer edit from the visual editor — it becomes a block that has to come back to a developer.
So the closer we got to the design, the further we got from the actual objective. The real work was not building ten pages. It was working out where that trade-off should land, and making sure the client understood the choice well enough to make it.
Before
After
Where the trade-off landed
Each custom-coded section is documented, so the client knows what needs a developer and what does not.
| Element | Built with | Client can edit |
|---|---|---|
| Page content, headings, CTAs | Native blocks | Yes |
| Comparison table | Native blocks (converted from custom code) | Yes |
| Hero split | Minimal custom code | Documented |
| Auto-scrolling marquee strip | Minimal custom code | Documented |
| Footer | Minimal custom code | Documented |
The Approach
Every page was rebuilt through Kajabi’s native editor rather than imported as raw HTML. Importing would have been faster and would have matched the reference more closely. It would also have handed back a website the client could look at but not touch, which is the one outcome the brief ruled out.
Custom code was used only where an element genuinely could not be reproduced natively, and every instance was flagged and documented rather than quietly absorbed into the build.
When the client weighed the trade-off and chose editability over pixel-perfect fidelity, we acted on it: converted custom-coded sections back into native blocks, accepted small documented deviations where the platform forced them, and kept the existing brand-matched theme rather than switching to a new one late in the engagement.
That last decision is worth naming. Changing themes near the end of a build is the kind of move that looks decisive and costs a fortnight.
Before
After
What we Did
Assessed the existing theme, then built on it. It already matched the brand, so we configured global settings site-wide — logo, colors, typography — instead of starting over.
Rebuilt every page section by section in native blocks. Copy, headings, section order, and calls-to-action were extracted from the reference HTML and recreated in the editor. No raw HTML was imported, which is the decision the entire handover depends on.
Built all ten pages and connected them. Dropdown navigation, a styled “Get the Book” call-to-action, and every internal link wired up.
Used custom code in three places, and documented each one. The hero split, an auto-scrolling marquee strip, and the footer could not be reproduced with native blocks. Each is recorded so the client knows exactly which parts of the site need help and which do not.
Before
After
Converted custom-coded sections back to native blocks. Once the client prioritized self-editing, the comparison table and others like it were rebuilt as editable blocks with the visual design preserved. We undid our own work because the brief’s priority had been made explicit.
Before
After
Made it responsive and tested it repeatedly. Desktop, tablet, and mobile, validated across multiple QA rounds against a structured testing document rather than a quick look on a phone.
Set up the things that have to work. Newsletter and contact forms configured and tested, and the legal pages built and linked from the footer.
Explained the platform’s limits instead of hiding them. Non-clickable dropdown parent labels, the two-font cap, credential-logo constraints, italic-heading behavior, and site-wide global CSS effects — each one guidance the client needs before making an edit that breaks something.
Before
After
Results in Detail
Ten pages live on the client’s own domain, built natively, and editable without developer support. The engagement’s primary objective, met in full.
This is the result that everything else was arranged around. A website the owner can change is worth more than one that photographs better, because the second kind quietly stops being accurate the moment the business changes and nobody can fix it.
Clean single-H1 structure across nine of ten pages. The Blog index was escalated as a platform limitation rather than left as a silent error, or patched with a workaround that would break on the client’s next edit.
Nine of ten is the honest number, and the tenth is the more useful part of the story. Kajabi generates the Blog index heading structure itself. It could have been forced with custom code, which would have looked clean in an audit and then collapsed the first time the client edited the page — leaving a broken heading structure and no idea why. Flagging it as a platform constraint means the client knows what it is, why it is there, and that it is not something they broke.
Tools & technologies
What the build runs on
verified