A product team is arguing about headcount. The backlog is long, half of what's in it never ships, and someone wants to hire two more engineers to clear it faster. Someone else thinks the backlog is the problem, not the team size — too much gets approved that shouldn't have been. Both sides have a spreadsheet. Neither spreadsheet can tell you which one is right, because a spreadsheet can't simulate what happens when you add a person to a system that already has feedback loops in it: an evaluation gate, a build queue, a measurement window, engineers who get pulled onto things that later get killed.
sim.pflow.xyz can. Not because it's specialized for engineering orgs — it's the same what-if engine we've written about before for vet clinics and help desks — but because "should I hire another engineer" and "should I hire another vet tech" are the same question wearing different clothes: a flow with a cost, a benefit, and a knob someone wants to turn without knowing what it actually does to the outcome.
feature-lab is a Petri net of exactly the debate above: ideas land in a
backlog, a pool of analysts scores each one against cost and benefit,
roughly a third get approved and go to a capacity-constrained engineering
pool, and every shipped feature spends a measurement window in telemetry
before it's marked validated or killed. Validated features seed one
follow-on idea back into the backlog — the evolutionary loop that makes
this a build-measure-learn system rather than a one-shot pipeline. A
meter tracks engineer-hours spent building, including on the two-thirds
of shipped features that get killed later — the sunk cost the "just hire
more" argument usually doesn't put a number on.
Every model in the catalog gets the same automated pass: diagnose ranks
every knob — every pool, every source, every patience threshold — by its
measured effect on the model's declared objective, not by intuition
about which one should matter. Run against feature-lab's declared
objective (validated − 0.5·killed − 0.02·eng_hours), it found the
second side of the argument was right, and by more than a hunch: past a
certain team size, adding engineers makes the objective worse, because
a loose evaluation gate lets the extra capacity burn engineer-hours on
features that were always going to be killed. The fix isn't more people.
It's a tighter gate.
The interesting part isn't that one model produced a counterintuitive answer — it's that this same result shape turns up unprompted, across models that were never built to make this point, when you run the same diagnostic pass against the rest of the catalog:
| Model | The resource everyone would assume matters | What diagnose found instead |
|---|---|---|
| ward-flow | Two more ED bays — the question the model's own description asks | Neither ED bays nor ward beds move the needle; raw arrival rate is the only live knob |
| launch-plan | More engineers — the actual build resource | engineer_free is inert; how fast briefs get pulled off the queue is what binds |
| invoice-collections | More collectors and more account managers | Both inert; only demand and write-off timing matter |
| loan-book | More underwriters | Inert — the collections desk is the real lever, not underwriting |
| autoscaler | More compute (instance_slots) |
Inert — a pre-warmed pool is what actually cuts cold-start loss |
| vet-clinic | 8 of 11 specialty rooms and pieces of equipment | Inert — front-of-house staffing (techs, vets, reception) is what binds |
None of these were built to prove a point about capacity. They're an autoscaler, a hospital ward, a lending desk, a launch pipeline — ordinary operational models, each asking its own question. The pattern showed up because the same deterministic pass was pointed at all of them, not because anyone went looking for it.
One finding wasn't even statistical: retry-storm's structural analysis
proved a whole modeled capability — a traffic-spike handler — can
never fire from the model's own starting state, by linear algebra on
the arc structure, no simulation required. In software terms: a feature
that was fully specified and built, wired up in a way that makes it dead
on arrival. That's a defect diagnose catches for free, on every model,
because the check is generic.
Cost-benefit analysis for software decisions has always been done —
RICE scores, WSJF, decision trees with expected value, Monte Carlo
throughput forecasts. Every one of them is a real, useful technique, and
every one of them asks its question at a single point in time, on a
system that doesn't talk back. None of them can tell you that your
evaluation gate and your headcount are fighting each other, because none
of them simulate the queue, the feedback loop, and the sunk cost all at
once, from one declared model. That's the gap feature-lab and the
diagnose pass sitting on top of it fill — not a replacement for those
techniques, a different instrument pointed at the same decision.
The instrument doesn't care whether the flow is customers through a café or ideas through a backlog. That's the actual thesis sim.pflow.xyz is built on now: cost-benefit analysis for anything you can describe as a flow. Staffing a café and deciding what to build next turn out to be the same kind of question, answered by the same engine, with the same honesty about a knob that doesn't do what you assumed.
Connect any MCP client to https://sim.pflow.xyz/mcp, describe your own
team's backlog the way feature-lab describes this one, and ask
sim_diagnose what it finds. For the operational side of this same
instrument — staffing, queues, disruptions — see The Model Is the
App and What-If
Analysis. The spreadsheet told you the backlog
was long. The model tells you why growing the team won't fix it.