Closing the loop on a learning project
The Caleb website launched in September 2025. I built it from scratch – going from first phone call to live site in about three months.
Superficially, it’s all fine. The site looks exactly as it should, and Caleb is happy with it.
However, it was the first time I’d run a proper client engagement as a WordPress designer and developer, end to end, and on my own. I benefit from adult supervision at the best of times and so, behind the scenes, it was a mess.
The project repo had become a catch-all for everything, and it had grown organically over several months: design files, requirements docs, image iterations, font files in three different places, a child theme, a database dump, a WhatsApp conversation export, and a series of documents acting as a build log, project notes and working notes, all with duplications and cross-references that were next-to-impossible to unpick. It’s exhausting just reading through the list, let alone trying to make sense of it all.
If I had for some reason needed to rebuild it from scratch — or hand the project to another developer — I could have spent all afternoon just working out what was what.
That’s what the Wrap-Up was for. And it did take all afternoon, I can assure you.
What the Wrap-Up actually was
I’d describe it as my best effort to salvage some clarity at the end of what had been a chaotic project. Not a post-mortem as such, not quite a retrospective — just a quiet, methodical pass through everything that exists and a review of what each thing is for and where to keep it.
The aim was to end up with three categories:
What you need to rebuild the site
This turned out to be surprisingly compact: a SQL database dump, a child theme, and a folder of uploaded images (including WordPress-generated re-sizes).
The core site content
This is what I’m calling the “content pack” — the portable essence of the site, stripped of WordPress-specific wrapping. Four pages of content as plain markdown. Five images. Four font files. A colour palette with hex values. Typography settings. Layout widths. All the ingredients, in a format that can be handed to any theme or framework.
Everything else
The requirements docs – I had at least shown signs of rigour at some point.
The Figma exports – a record of the design process, respectable-looking in retrospect.
The business card iterations and the poster files – evidence of how the scope had expanded mid-project from more than just a website.
The WhatsApp conversation – the place where the requirements had been refined on the fly but never properly captured as formal design and scope changes.
A planning document – complete with strikethroughs showing an attempt to track progress, but left incomplete, having been abandoned in the chaos.
Other documents serving as a memorial to other failed attempts to manage the design and build process.
What comes next?
The plan is to rebuild calebwhitefield.co.uk using a proper standalone theme and an assembly process that could be repeated for any client. The content pack is the input for that process — it’s the interface between “Caleb’s specific content” and “a theme that doesn’t know anything about Caleb.”
The site that exists now was built as a learning project. The rebuild will be part of developing a new workflow. The wrap-up is the foundation for that transition.
Leave a Reply