Rebuilding a Product — and the Team Behind It
At Midigator, I helped rescue DisputeFlow 2, stabilized its architecture and delivery practices, evolved it into the more extensible DisputeFlow 2.1 platform, and coached a disconnected engineering group into a confident team that grew into larger responsibilities.
When I joined Midigator, I inherited DisputeFlow 2 after the previous lead left. It was more than a difficult project: the product had lost its direction. The architecture carried significant technical debt, requirements lacked clarity, parts of the system relied on custom extensions around deprecated dependencies, and the engineering group had become disconnected. Everyone was working hard, but the team was often fighting the product instead of improving it. Before we could build the future, we needed to create a stable foundation for both the software and the people responsible for it.
Two systems transformed together
Rebuilding the product and the team behind it
Product system
- Unstable architecture
- Technical debt and unclear requirements
- Stabilized foundation
- Configurable platform capabilities
- Reduced Customer Success burden
People system
- Disconnected group
- Shared context through pairing and planning
- Clearer ownership
- Promotions and new team leads
- Confident, cohesive delivery team
Foundation enables flexibility
Architecture created room to say yes
Critical dependency modernization
Preserving customer workflows while replacing risk
- Deprecated editor dependency
- Pairing, research, and technical spikes
- Extended replacement library
- Cross-team integration testing
- Established workflows preserved
Leadership legacy
The product became easier to extend, and the people became more capable of extending it.
The impact path
Inherited
I inherited DisputeFlow 2 after the previous lead left. The product had accumulated architectural problems, unclear requirements, high-risk technical debt, and dependencies on custom extensions built around deprecated functionality.
Owned
I assessed the inherited architecture, codebase, product stories, delivery risks, and team dynamics before committing the group to another round of feature work.
Changed
I began with technical review, architecture mapping, stakeholder conversations, story cleanup, technical spikes, and direct investment in rebuilding trust within my team.
Result
2 → 2.1 — From rescue to extensible platform
What I inherited
The problem and the reality around it
The problem
- I inherited DisputeFlow 2 after the previous lead left. The product had accumulated architectural problems, unclear requirements, high-risk technical debt, and dependencies on custom extensions built around deprecated functionality.
- The engineering group had become disconnected and disjointed. People were working hard, but the team lacked a shared technical direction, clear ownership, and confidence in how to move the product forward.
- The platform needed to support different merchant data, content, and dispute-package requirements without turning every customer request into a separate engineering implementation.
The constraints
- A mature chargeback platform with document-heavy workflows, complex business rules, and customer-specific requirements.
- Existing functionality had to remain available while the architecture and critical dependencies were stabilized.
- A heavily used rich-text-editing capability depended on deprecated behavior that was being discontinued, while available replacement libraries did not provide the specialized content conversion the product required.
- Product rescue and team rebuilding had to happen while delivery continued across multiple stakeholders and teams.
What I owned
My responsibility in the work
I assessed the inherited architecture, codebase, product stories, delivery risks, and team dynamics before committing the group to another round of feature work.
I helped establish a clearer architectural direction, improved development and testing practices, and translated product needs into more actionable engineering work.
I led the evolution from DisputeFlow 2 into DisputeFlow 2.1, balancing stabilization with reusable customization capabilities and continued product delivery.
I coached engineers through technical growth, expanded ownership, promotions, and transitions into leadership roles while advocating for quality engineering as a valuable discipline.
How I approached it
Decisions, tradeoffs, and delivery
Rather than immediately adding features, I stepped back to understand what was actually happening. I reviewed the architecture and codebase, mapped technical risks, worked with stakeholders to clarify priorities, improved stories, used technical spikes to reduce uncertainty, and invested in rebuilding trust within my team. Once DisputeFlow 2 was stabilized, we could evolve it into DisputeFlow 2.1. My team added merchant-defined custom fields, reusable content snippets, more flexible templates, and continued improvements to reporting, dashboards, document generation, and rule-driven workflows. These capabilities let merchants express business-specific needs through configuration and reusable building blocks instead of requiring engineering to hard-code every variation.
- I began with technical review, architecture mapping, stakeholder conversations, story cleanup, technical spikes, and direct investment in rebuilding trust within my team.
- My team stabilized the product foundation so we could extend it rather than repeatedly fight the same architectural constraints.
- For DisputeFlow 2.1, we introduced merchant-defined custom fields, reusable content snippets, more flexible templates, and continued improvements to dashboards, reporting, document generation, and rule-driven workflows.
- We designed customization as reusable product capability: merchants could add business-specific key/value data and insert reusable content into full-length templates without requiring a one-off feature for every request.
- When a critical rich-text dependency was being discontinued, my team spent roughly four sprints pairing, mobbing, researching, and prototyping before extending an existing library to preserve the required content-conversion behavior.
- We followed the implementation with approximately one month of cross-team integration testing because the editor touched many package-building workflows and needed to change without disrupting established customer behavior.
- I created clearer expectations, meaningful ownership, collaborative problem-solving, and coaching paths that helped engineers grow from mid-level to senior roles and from senior roles into team leadership.
- After repeatedly advocating for the value of dedicated quality engineering, I helped coach the last remaining QA engineer, who later grew into the company’s QA Lead.
How I led
The team and stakeholder system
The technical work and team development reinforced each other. One critical dependency required several sprints of pairing, mobbing, research, and experimentation before my team extended an existing rich-text library to preserve specialized behavior the product relied on. We then coordinated approximately a month of integration testing across multiple teams to protect dependent workflows. At the same time, I established clearer expectations, encouraged shared ownership, and coached engineers into larger technical and leadership roles. I also advocated consistently for dedicated quality engineering and helped coach the last remaining QA engineer, who later grew into the company’s QA Lead. Over time, my team became a confident and cohesive group that respected one another’s ideas and could deliver larger work together.
Results
What changed
2 → 2.1
From rescue to extensible platform
After stabilizing DisputeFlow 2, my team evolved the product with reusable customization, templating, data, reporting, and document-building capabilities that could support multiple merchant needs over time. · Shared outcome
Lower workload
Customer Success impact
After the successful launch, Customer Success carried less operational burden because merchants could accomplish more through configuration and reusable product capabilities. · Team outcome
Team growth
Engineers advanced into larger roles
Multiple engineers grew into senior and team-lead responsibilities, additional developers went on to support new teams, and the remaining QA engineer later became QA Lead. · Team outcome
Leadership evidence
How I moved the people system
- — I treated product rescue and team health as connected problems: the product needed a stable foundation, while the engineers needed clarity, trust, ownership, and room to grow.
- — I redirected the team from disconnected individual effort toward collaborative delivery where people respected one another’s ideas and could solve increasingly ambitious problems together.
- — I coached engineers who earned promotions into senior and lead roles, helped prepare developers to support additional teams, and contributed to the growth of the remaining QA engineer into QA leadership.
- — I advocated for the business value of the working legacy product and for the people maintaining it, helping shift conversations away from dismissing imperfect systems or underestimating the engineers behind them.
- — I left both the product and the people stronger than I found them.
Technical evidence
How I moved the product system
- — Architecture assessment and stabilization of an inherited chargeback-management platform.
- — Evolution from DisputeFlow 2 to DisputeFlow 2.1 through reusable custom fields, content snippets, templates, dashboards, reporting, document generation, and business-rule-driven workflows.
- — Extension of an existing rich-text library to preserve a specialized content-conversion capability after deprecated functionality was discontinued.
- — Several sprints of collaborative technical investigation followed by approximately one month of multi-team integration testing across dependent package-building workflows.
- — A product design approach that converted recurring customer variation into configurable platform capabilities rather than isolated one-off implementations.
Technical footprint
Technologies and system areas
What I took from it
The lesson I carry forward
By the successful launch of DisputeFlow 2.1, Customer Success workload had decreased, and the company was investing in additional product and engineering capacity to support more products and features. The accomplishment I remain proudest of, however, is the growth of my team. Midigator reinforced that product architecture and engineering leadership cannot be separated cleanly: stable architecture gives people room to make progress, while a healthy team gives them the confidence to challenge assumptions, share responsibility, and build solutions larger than any one contributor could create alone. DisputeFlow was both a product rescue and a team transformation. It strengthened a principle I have carried into every role since: leave both the product and the people stronger than you found them.
Related work · Architecture