Pabbly Connect · Development Review
Bug Load vs. Feature Delivery — Where We Stand & The Plan Forward
A live, editable look at how the team's time is actually split, why recurring issues are surfacing now, and the plan to reduce them while protecting new-feature velocity.
The Question Raised
"Is the entire team occupied with fixing bugs?"
Leadership's concern is that recurring issues are consuming development capacity, leaving little room for new features and revenue-driving work. This dashboard answers that with actual work-item data — kept live, so it stays true as the mix shifts.
Bug load by developer
Expand a row for the breakdown. Edit the exact numbers any time in the Data section below — this chart updates instantly.
Bug load is uneven by design — some developers carry more core-engine bug work than others. That distribution matters for staffing a rotation that protects builders' time (see Action Plan).
Work Mix — What The Team Actually Shipped
Team-wide category distribution
Edit counts
Bugs is computed automatically from the Data section. Adjust the rest as work gets reclassified — the bar above recalculates immediately.
In parallel with bug work, the team delivered major initiatives: the New Integration Developer Portal, a platform performance & lag optimization program, new modules (Delay-in-seconds, Clear-Queue, Secure Workflow Deletion & Recovery), infrastructure upgrades (polling capacity, PM2, CRON cleanup, monitoring), and near-daily integration releases.
Root-Cause Analysis
Why recurring issues are surfacing now
The bugs are not random regressions of stable code. Grouped by module, they cluster around a small number of predictable, explainable sources — most of them tied to major systems being rebuilt while the old ones stay live. Update the status on each as mitigations land.
1. Three core subsystems are being rewritten at once
The New Workflow Builder, New Dev Platform (v2), and New Task History are all mid-migration. New code interacting with legacy behaviour is the single largest bug source (routes/router paste, node structure, step sequence, dropdown mapping, JS execution differences). These are transition-period defects — expected, and temporary.
2. The core engine is deeply interconnected
Routers, iterators, delays, and auto re-execution share state. A change in one path (e.g. delay-resume) can surface in another (duplicate iterator runs, extra steps). High interconnection means high regression risk without automated coverage.
3. Integration surface grows almost daily
New integrations ship continuously (Zoho, Airtable, Dropbox, AiSensy, Airmeet, Facebook Lead Ads…). Each new or updated app is a new failure surface that depends on third-party API behaviour we don't control.
4. Testing & release safety nets are manual
There is limited automated regression testing on core flows, so some defects reach production before being caught. This is the most fixable root cause — and the centre of the action plan.
The Plan — Reducing Bugs Permanently
Action plan
Structured to fix root causes (not symptoms), catch regressions before release, and protect feature-development time. Check off steps as they land.
Automated regression suite for core flows
Build automated tests around the highest-traffic paths — trigger→action, routers/routes, iterator, delay & re-execution — so regressions are caught before release rather than by users.
Root-cause hardening sprint
Dedicated sprint to fix the underlying node/route/re-execution model behind the recurring Builder cluster — one structural fix instead of repeated one-off patches.
Stronger staging QA gate
Mandatory test-case pass on staging before production for any change touching the core workflow engine or a shared component.
Bug taxonomy + monthly RCA review
Tag every incoming bug by module. Track which modules recur, review monthly, and feed the top offenders into the hardening backlog.
Stabilization gating for new-platform migrations
Treat New Builder / New Dev Platform rollouts as staged beta with a stabilization window before full cutover, so migration bugs are contained.
Dedicated bug rotation
A rotating owner handles incoming production issues each cycle, so the rest of the team's feature time is protected — directly preventing the whole team from being pulled onto bugs.
Proactive monitoring & alerting
Leverage the upgraded monitoring stack to detect anomalies early and catch issues before users report them.
Code-review discipline for shared modules
Require peer review for any change to core/shared components, where most cross-feature regressions originate.
Aligning on "Bug-Free Development"
Let's measure quality, not chase zero
In a product where new features, integrations, and existing workflows are highly interconnected, zero production bugs isn't a realistic benchmark. A measurable quality standard is more useful and lets us show real, trackable progress. Set the target and update the current state as it moves.
Data
Work-item breakdown by developer
Edit any cell — the Overview bars, Work Mix chart and totals recalculate everywhere automatically.
| Developer | Status | Bugs | Non-bug | Total | Bug % |
|---|---|---|---|---|---|
| 38 | 66% | ||||
| 20 | 60% | ||||
| 90 | 11% | ||||
| 38 | 42% | ||||
| Team | — | 63 | 123 | 186 | 33.9% |
Non-bug = features, enhancements, improvements, design, investigations & research.
Pabbly Connect — Development Quality Analysis & Action Plan