Some releases add features.
Some releases improve performance.
And then there are releases that quietly redefine what a product wants to become.
WP Project Manager v4 was one of those releases.
When users see the new interface, the Kanban boards, Gantt charts, AI-powered workflows, invoices, or the smoother navigation, they see the final product. What they do not see is the pressure, experimentation, uncertainty, technical debt, rapid decisions, and relentless collaboration that made this release possible in such a short amount of time.
This is the story behind that revamp.
The Old Interface (Check the video)
It Was Supposed to Happen Later
Originally, the revamp was not meant for this quarter at all.
The initial target was Q3.
That made sense at the time because this was not a small redesign task. The scope was enormous. We were talking about rebuilding the overall experience of WP Project Manager while introducing some of the biggest features the product had ever received.
At the same time, our design queue was already overloaded. Waiting for a traditional full design cycle would delay the project even further.
But there was a growing realization inside the team:
The product had reached a point where incremental UI updates were no longer enough.
We needed to rethink how project management should feel inside WordPress itself.
Not just visually. Structurally.
The Goal Was Never “A Better WordPress Plugin”
Very early in the discussions, one thing became clear:
We did not want this to feel like a traditional WordPress admin panel with extra screens attached to it.
The ambition was bigger than that.
We wanted users to open WP Project Manager and feel something closer to modern SaaS tools—faster navigation, smoother interactions, less friction, cleaner workflows, and a more connected experience overall.
That vision shaped almost every decision during the revamp.
Instead of waiting for complete design handoffs, the product side started sketching flows directly in Figma. The discussions became highly practical and iterative.
- How should the sidebar behave?
- How should Pro modules blend naturally into the core experience?
- How do we reduce context switching?
- How do we keep workflows fast without overwhelming the interface?
Although the revamp was initially considered a future-quarter initiative, the project manager [Sharif Rakib vai] strongly pushed for the work to be completed within the current quarter instead of delaying it to Q3. That shift created urgency across the team and changed how everyone approached planning, collaboration, and delivery.
There were multiple sessions between me and Arif vai where ideas evolved in real time. Often, these were not formal long meetings at all. Sometimes it was simply opening ClickUp or other PM tools, observing interaction patterns for a few minutes, and discussing how those ideas could translate into WordPress without breaking usability.
The instruction repeated throughout the process was simple:
“It has to feel like SaaS inside WordPress.”
Then the Pace Changed Completely
At one point, we scheduled a meeting to discuss how implementation would begin.
Instead, something unexpected happened.
Arif vai opened his laptop and showed that most of the core work had already been started. A huge portion of the revamp was already functioning.
That moment completely changed the momentum of the project.
During the Eid break, he had requested Claude Code Max access from the PM side and started building aggressively. What followed was an intense implementation sprint filled with nonstop iteration, experimentation, refinement, and architectural restructuring.
Within roughly a week, the product had transformed visually and structurally in ways we originally expected to take much longer.
Of course, this also meant we were now entering the most dangerous part of any large revamp: stabilization.
Rebuilding While Carrying Years of Legacy
One of the hardest parts of the project was not creating the new interface.
It was making the new system coexist with years of existing functionality.
The transition toward a React SPA-style experience introduced major architectural challenges. WP Project Manager had evolved over years with mixed rendering approaches, legacy assumptions, integrations, and workflows deeply tied into the old structure.
Modernizing the experience exposed hidden problems everywhere.
Some bugs were newly introduced.
Others had silently existed for years and only became visible once the architecture changed.
Things that looked simple on the surface suddenly became complicated:
- task detail rendering,
- sidebar activity synchronization,
- custom field loading,
- reporting consistency,
- state management,
- integration compatibility,
- Pro module communication,
- frontend behaviors,
- inline updates,
- modal workflows.
And because Pro features were now being unified directly into the core experience instead of feeling like disconnected add-ons, the complexity increased even further.
There were moments where fixing one issue revealed three more underneath it.
That became the reality of the revamp phase.
QA Became More Than QA
One of the most important things that happened during this project was how the role of QA evolved.
Traditionally, QA reports issues and product teams decide solutions.
This release became much more collaborative than that.
The PM side intentionally encouraged Rubaiyat-QA vai to make smaller refinement decisions independently whenever it improved usability or consistency. Instead of waiting for unnecessary approval chains, QA was empowered to contribute directly to the product experience itself.
That meant discussions were no longer limited to:
- “This is broken.”
They became:
- “This interaction feels confusing.”
- “This spacing interrupts workflow.”
- “This label could be clearer.”
- “This behavior feels inconsistent.”
Those tiny decisions added up quickly.
And honestly, many of the smoothest parts of the final experience came from these small iterative refinements.
Special appreciation goes to Ruabiyat for actively contributing to that refinement process throughout the release cycle.
The Final Stretch
After implementation, the team entered nearly 20 days of rigorous QA, refinement, and retesting.
This was not ordinary bug fixing.
The revamp touched almost every major area of the product, meaning even small changes could create unexpected side effects elsewhere.
A huge amount of effort went into reviewing pull requests, validating flows, checking regressions, and repeatedly testing edge cases across both Free and Pro experiences.
Ifat vai reviewed more than 600 files during PR testing alone.
That level of attention became one of the reasons the final release reached stability despite the aggressive timeline.
More Than Just Features
Internally, this release represented something bigger than a feature list.
It showed what can happen when:
- engineering moves with ownership,
- product thinking becomes collaborative,
- QA participates in experience decisions,
- and teams stop waiting for “perfect conditions” before executing.
This release moved incredibly fast.
At times, probably uncomfortably fast.
But everyone stepped up.
And because of that, WP Project Manager v4 became one of the most transformative releases we have shipped.
Special Thanks
A special thanks to:
- Arif vai for carrying the massive engineering execution behind the revamp
- Ifat vai for the extraordinary review and testing effort across hundreds of changed files
- Ruabiyat vai for helping shape refinement decisions during QA and stabilization
And thanks to everyone involved in making this release possible.
WP Project Manager v4 was not just redesigned.
It was reimagined.
Find the chaneglog here: https://headwayapp.co/project-manager-changelog
Leave a Reply