Four apps became one product in six weeks.
A consolidation of Workshopr's four core applications into a single product with four phases, built around one object — the workshop record — that the whole lifecycle is derived from.
Fourteen properties, and nothing held them together.
By mid-2026 Workshopr had grown to roughly fourteen web properties. Four were load-bearing (Planner, Facilitator, Library and MyWorkshopr), and the other ten were microsites that had each seemed like a good idea in isolation.
The problem wasn't that they looked inconsistent. That was the symptom. The problem was structural, and when I mapped it as a service blueprint the failures were specific enough to name.
The product was three shells, not one. Library, Planner and Facilitator each owned a header, a CSS bundle, a JS module set and a cache-bust scheme. A user crossing the spine of the product crossed three interfaces.
State lived in the wrong place for the handoff. Library to Planner was a bare URL parameter. Anonymous work died at the app boundary every single time. You could do twenty minutes of real thinking in one app and lose all of it by moving to the next.
Underneath all of it was a policy problem: saving was login-gated, the builder and deck export were Pro-gated, and the Library's Pro rules were never enforced at all. The entitlement logic and the code disagreed with each other. The usage data told the same story the architecture did — people lived in one app, and they didn't cross.
One app, four phases, one record.
Workshopr is now one core application with four phases (Strategize, Plan, Facilitate, Synthesize) and a persistent workshop record running underneath all of them.
The record is the part that matters. It starts almost empty at Strategize, when the workshop is still an argument you're making to someone who controls a budget. It accumulates through Plan as the agenda takes shape, through Facilitate as the room generates notes, polls and decisions, and through Synthesize as that raw material becomes themes and commitments. By the end it is a complete account of what happened — not a folder of artifacts from four tools, but one object.
Crucially, lifecycle state is derived, never stored. A workshop is "delivered" because a completed session exists with a linked plan. It is "synthesized" because a synthesis record exists against that same plan. There is no status column for the system to lie about, and no way for the label to drift from reality.
Ten microsites were triaged. Library and the intervention cards stayed deliberately outside the spine as supporting references rather than lifecycle phases. The reference material didn't belong in a linear flow, and forcing it in would have made both worse. That was a sequencing decision, not an unfinished job.
"I used to spend a full afternoon building an agenda. Last week I built a three-hour offsite in about twenty minutes and it was better than the one I'd have written."
Claire · Design Lead, fintech
Something I'd rather state than have someone find.
I can't claim the consolidation caused that growth. Acquisition came from marketing: writing on Substack several times a week, free and paid ebooks, engaging with facilitation communities. The honest framing is that the marketing engine brought people in and the consolidated lifecycle gave them a reason to stay. Retention and cross-stage adoption are the numbers that would actually prove that, and I don't have them yet.
Fifteen interviews, one data model, and a demotion.
I built Workshopr for myself first, which was the right way to start and the wrong way to continue. When I finally ran proper research (fifteen user interviews plus a survey of existing users), the central assumption broke. I had been designing for people like me: designers who run workshops. A large share of my actual users are Learning & Development practitioners, who approach facilitation with different goals, different constraints and a different definition of success.
The clearest signal came earlier, and I'd half-ignored it. The Library (three months of work, 380 exercises, 90 icebreakers) landed with users as "nice, but so what?" That reaction is what drove me to build the Planner in the first place. Research didn't tell me to build something new; it told me what the centre of gravity already was, and that my information architecture was pointing at the wrong thing.
The workshop record was the unlock, and it had to come first.
plans.id as the spine, every capture table keyed to it, and the lifecycle computed at read time. Click to view full size.Consolidation was impossible while every app owned its own state. You cannot merge four applications into a lifecycle if nothing survives the trip between them. So the first thing built inside the new shell wasn't a screen. It was a federated read model keyed on the plan. One plan, one workshop. Everything else hangs off that spine. This is why the sequence was charter, then record, then interface: the shell shipped before any of the phases did, so the chrome could be settled once rather than four times.
Collapsing the IA meant demoting my own work.
The hardest call was the Library. It was the most content-rich thing I'd built and the thing I was most attached to, and the research was unambiguous that it wasn't the product's centre. Promoting it would have meant designing the lifecycle around reference material instead of around the job. It became a supporting surface.
Strategize went the other way. It began life as a standalone "getting to yes" toolkit, a microsite about winning approval for a workshop before you plan it. Research kept surfacing that the job doesn't start at the agenda; it starts at the argument. So the microsite was promoted into the first phase of the lifecycle, with five steps: make the case, build a strategy kit, draft the pitch, practise the conversation, sanity-check the scope.
The design system had to be rebuilt before the merge, not after.
You can't consolidate four applications onto four stylesheets. Canvas (tokens first, components second, theming third) was the precondition. I'd learned this the expensive way: the first microsite I built copied every token into its own stylesheet and drifted within weeks. Extension, not duplication.
AI restraint was a design decision, not a technical one.
The temptation in an AI product is to use it everywhere. The actual work was deciding where not to. Recommendations are constrained to exercises that already exist in the library, so the Planner cannot invent an exercise that isn't real. Strategize uses AI for exactly one thing, a sixty-second pitch, and the rest of the phase is structured input, not generation. The "draft it for me" button cycles canned drafts rather than calling a model, because the user needs a starting point, not a surprise.
The right start, the wrong finish.
Building for myself was the right start and the wrong finish. I should have talked to the people who weren't me at app three, not app fourteen. The fourteen-app sprawl wasn't a failure of discipline (each one was a reasonable local decision) but a failure to check, early enough, whether the person I was building for existed.
The gap I'd name now is dependency. Strategize and Synthesize both lean on a single AI provider, and while others are configured, only one is live. I built provider fallback elsewhere in the platform specifically because I don't trust a single dependency, and these two phases don't have it yet.
The other honest gap is measurement. I can show that the architecture consolidated and that users grew. I can't yet show that someone who starts at Strategize is more likely to finish at Synthesize, which is the entire thesis of the redesign. That's the next instrument to build, and until it exists, the strongest claim I can defend is a structural one: four applications became one product, and the object that made it possible is the thing I'd design first if I did it again.