Client work, published with permission.
The story separates what can be stated publicly from what must stay confidential, and links outcomes to approved evidence.
The problem being explored
The client sells learning products through an online marketplace, such as past papers by quarter and learning cards. Its back-office team creates, updates and archives those items all the time.
What made delivery difficult
The team needed a content system that treated every item as something with a history, without storage costs running away.
- No lost work. Changes had to save automatically, even if someone forgot to press save.
- Any version, any time. Editors needed to see and restore any earlier version, draft or published.
- Easy for non-technical staff. Previewing, comparing and restoring versions had to be simple.
- Safe publishing. Rolling back one item must never break other live items in the marketplace.
- Sensible costs. Frequent saves and many versions could not be allowed to push up storage costs.
- Regulated content. Healthcare content needed clear audit trails and role-based access.
Connect product thinking to implementable decisions
We led the design and delivery of the platform.
- Solution architecture and technical leadership
- The editor,
- The storage design
- Preview, compare and rollback tools
- Access control, audit trails and admin tools
- Delivery automation,
- Documentation, runbooks and training
How the work was shaped
The work maps to seven stages of our delivery lifecycle, from Discovery to Closure & Handover.
- Discovery. We mapped the catalogue and how the editorial team works day to day.
- Delivery Planning. Phased deliverables got value to the team early, and their feedback shaped each phase.
- Build & Test. A background-saving editor with a timeline of every version, instant preview and one-click rollback. Snapshots for published versions, changes only for drafts.
- UAT & Launch Readiness. Staged rollouts, checked by back-office users.
- Operational Readiness. Documentation, runbooks and training prepared the team.
- Hypercare. After each release, we gathered feedback and refined the editor.
- Closure & Handover. The back-office team took over, with documentation, runbooks and training.
Technology and structure
The system is built around one idea: every content item has a full, recoverable history.
- An editor. Responsive, with background autosave and clear draft and publish steps.
- A version timeline. Every saved version, with time, author and change notes.
- Hybrid storage. Snapshots for published versions, change records for drafts, and lifecycle rules that tidy up older autosaves.
- Preview, compare and rollback. See a version, compare it with another and restore it in one click.
- Admin tools. Retention settings, roles and audit records.
Risk, assurance and release boundaries
The controls protect both the content and the people editing it.
- Role-based access. Each editorial role can do only what it should.
- Audit logs. Every change recorded, to support governance in a regulated setting.
- Retention rules. Older autosaves are cleared on a schedule, balancing recovery against cost.
- Safe rollback. Restoring one item never disturbs other live items.
- Automated tests. Integration tests for every versioning workflow, run on each release.
What can be stated publicly
The client got a production content system with automatic and manual versioning, preview, comparison and one-click rollback.
- No more lost work. Autosave and version history stopped accidental data loss and cut time spent recreating content.
- Faster, safer updates. Preview and rollback gave the team the confidence to publish more often, so catalogue changes and promotions went out sooner.
- Predictable costs. The storage design controlled growth and kept hosting costs predictable.
- Better traceability. Audit logs and role controls supported governance requirements.
- Ahead of schedule. Phased delivery and user testing led to an early rollout and strong take-up by the back-office team.
What transfers to the next programme
What we carry into similar work.
- Design for the forgetful moment. Autosave matters most on the day someone forgets to press save.
- Version history needs a storage plan. Keeping every version is only practical if storage is designed for it from the start.
- Make rollback boring. When restoring is safe and simple, teams publish more often.