Quick answer

I proposed and executed a self-directed frontend engineering initiative in PostX - a WordPress Gutenberg plugin - after identifying that a legacy shared component system was actively blocking feature work I was assigned to do. Rather than work around the constraint again, I fixed it. The work was completed September 2025 across ~60 commits, executed solo.

TL;DR

The call	Stop feature work. Fix the infrastructure blocking it. Do it without being assigned.
The trigger	A 2019-era monolithic stylesheet kept creating regression risk every time I touched any settings panel
What I did	Proposed and solo-executed a component-by-component rebuild of PostX's shared CSS system
Outcome	Core stylesheet shrank 60% (6,262 → 2,529 lines), split into 19 maintainable files
Bundle impact	Affected assets 20-30% smaller, measured in isolation - an expected cost that didn't materialise
Timeline	Completed September 2025
Team	Solo

The situation

PostX is a WordPress plugin for building news sites and blogs. Every block in the plugin - post grids, sliders, lists - has a settings panel. Every settings panel is built from the same shared set of UI components: toggles, color pickers, dropdowns, typography controls. All of those components' styles lived in one file. A 6,262-line file from 2019. I kept running into it. Every time I needed to change anything in a settings panel, I was opening a file that controlled every other settings panel at the same time. Change a toggle's padding for one block, risk shifting a toggle somewhere else entirely. It was a shared blast radius, and it was slowing me down on the actual feature work I was assigned to deliver.

The decision

No one asked me to fix this. It wasn't in a sprint, a ticket, or a roadmap. I raised it because the alternative - working around the same fragile file for the fourth or fifth time - felt like the lower-leverage choice. If the constraint was slowing me down every time I opened it, it was probably slowing everyone else down too. And it was only going to grow. The debt wasn't theoretical - it was actively costing time every week, which is what made pausing feature delivery to fix it the right call. I scoped the fix, proposed it, got alignment, and started.

How I scoped it

Option A - Keep patching. Add to the monolithic file, be careful with regression testing each time. Fast short-term, but the file keeps growing and the risk doesn't go away. Option B - Adopt an existing design system library. Faster to build, but PostX's components are tightly coupled to WordPress's Gutenberg editor APIs. No strong candidate fit that constraint. Option C - Extract each component into its own file, one at a time. More upfront work, but it directly removes the shared blast radius. Each component becomes independently editable, testable, and understandable. I chose Option C because it addressed the root cause, not the symptoms.

What made this hard

The codebase had no automated test suite. The system I was refactoring had 13+ dependent files. I was making structural changes to something every developer on the team touched regularly. I managed that risk by going component by component - one field type per commit - and keeping the working branch in sync with main throughout rather than letting it drift. It worked, but it was riskier than it needed to be. See the full case study on refactoring without a test suite →. The work also paused for two months when I was reassigned to another project. I picked it back up in September and finished the plan - extending the same approach into new controls as the plugin moved toward its next major version. I treated it as one continuous initiative, not two, because the September work was a direct continuation of the same decision.

The result

The core stylesheet went from 6,262 lines to 2,529 lines - a 60% reduction - with that logic now living in 19 dedicated component files under a new editor_styles/ folder. I expected the split to cost bundle size, and I said so before starting rather than discovering it later. It turned out not to: my first before/after comparison was confounded by newly added image assets in the same commit range, and re-measuring without them showed affected assets 20-30% smaller. The decision stands either way - a plugin where every settings screen shares one stylesheet needs long-term editability more than it needs shaved kilobytes - but the cost I was prepared to defend never materialised. See the bundle size case study → for the measurement and what went wrong with the first one.

The actual skill

The technical work - extracting SCSS partials - is documented in the CSS architecture refactoring case study →. The skill demonstrated here is different. It's knowing when to stop feature delivery to fix the thing that's slowing feature delivery down. That call requires:

• Recognizing the constraint clearly (not just feeling frustrated)
• Estimating whether fixing it is worth the cost of pausing other work
• Scoping a fix that addresses the root cause, not the symptom
• Proposing it clearly to a team that didn't ask for it
• Executing it to completion through a project reassignment in the middle

None of that is on a ticket. All of it matters for how fast a team can ship over time.

FAQ

Why did you raise this instead of working around it again? I'd already worked around the same fragile file several times, and each workaround made the next one harder. Raising it was the cheaper option over any horizon longer than the current sprint. Why was it worth pausing feature delivery for? Because the cost was recurring, not hypothetical. Every settings-panel change meant opening a file that controlled every other field type and hoping nothing else moved - that tax was being paid weekly, by everyone, not just once by me. Why scope it as a component-by-component extraction rather than a rewrite? A rewrite would have been a long-running branch with no shippable midpoint and a painful merge at the end. Going one component at a time meant every commit was independently reviewable, the branch stayed in sync with main, and the work could survive being interrupted - which it was. Why finish it after being reassigned for two months, instead of dropping it? A half-extracted component system is worse than either end state: you have two conventions in the codebase and no one knows which is current. Finishing was what turned the work into an actual improvement rather than a second inconsistency.

Part of the PostX frontend refactoring case study series →