What-If Simulator
Private betaEvery team change has second-order effects. Now you can see them.
Hiring someone, losing someone, splitting a team, merging two teams — these decisions affect velocity, knowledge distribution, review capacity, onboarding load, and a dozen other dimensions. Gitrevio simulates the impact using your actual team data.
Scenario Types
Eight scenario types
Departure
What happens if X leaves? Knowledge gaps, review bottlenecks, onboarding impact, orphaned services, recovery timeline.
Hiring
What happens if we add an engineer to team Y? Ramp-up drag, long-term velocity gain, break-even point, optimal role profile.
Team restructuring
Split platform into platform + infrastructure? Merge frontend and mobile? See the knowledge fragmentation and communication overhead.
Reassignment
Move Alex from backend to mobile? Measure the impact on both teams — the loss on one side and the ramp-up cost on the other.
Vacation / PTO impact
Key engineer on leave for two weeks? Model the review backlog, blocked PRs, knowledge-gap exposure, and catch-up cost after return.
AI tool rollout
What if we adopt Copilot for the frontend team? Project the productivity lift, ramp-up period, code-quality effects, and ROI timeline across affected contributors.
Framework migration
What if we migrate from React to Next.js? Estimate the velocity dip during transition, retraining cost, long-term throughput gain, and risk to in-flight projects.
Contractor analysis
Add 2 contractors vs 1 FTE? Compare short-term velocity boost against long-term knowledge retention and onboarding cost.
Departure Simulation
Deep dive: departure simulation
IMMEDIATE IMPACT (weeks 1-4)
Code review capacity: -38% (16→10 reviews/week)
Orphaned services: auth, payments, notifications
Knowledge silo risk: CRITICAL (bus factor → 0 for auth)
Onboarding disruption: 2 engineers lose primary mentor
Sprint velocity: -22% estimated
CASCADING EFFECTS (weeks 4-12)
Review bottleneck: Marcus overloaded (+8 reviews/week)
Quality risk: auth PRs reviewed by non-experts
Onboarding delay: Junior engineers +3 weeks to ramp
RECOVERY PATH
1. Cross-train Marcus on auth (2 wks, -15% his velocity)
2. Document payments flow (Sarah: 8h before departure)
3. Redistribute reviews: 4 to Marcus, 2 to Lisa
4. Hire auth-experienced engineer (recovery → 6 weeks)
Without action: 16 weeks to baseline
With mitigations: 6 weeks to baseline
A departure simulation maps the full blast radius — not just the person's direct output, but everything that depends on them. Review load redistribution, knowledge gaps, mentorship disruption, and the cascading effects that compound over weeks.
The recovery path turns a crisis into a project plan. Instead of scrambling when someone gives notice, you have a prioritized list of mitigations with time and cost estimates for each.
Run departure simulations proactively for your highest-risk team members. Combined with attrition risk scoring, you can have recovery plans drafted before a resignation even happens.
Hiring simulation: the other direction
Adding someone to a team does not immediately make it faster. There is an onboarding drag period where the new hire consumes senior engineers' time while ramping up. The simulator models this honestly.
You see the break-even point — the week where net velocity turns positive. For a senior hire on a well-documented codebase, that might be week 6. For a junior hire on a complex monolith, it could be week 14.
The simulator also recommends the optimal hire profile. Based on current knowledge gaps, review bottlenecks, and technology stack, it tells you what skills to prioritize in your next hire.
> Simulate: Add 1 senior engineer to mobile team
ONBOARDING DRAG (weeks 1-8)
Senior engineer time consumed: ~6h/week
Net velocity impact: -8% (weeks 1-4)
Net velocity impact: -3% (weeks 5-8)
BREAK-EVEN
Week 9: net velocity turns positive
Week 16: full productivity reached
LONG-TERM GAIN (steady state)
Team velocity: +18% (P50), +24% (P75)
Review capacity: +6 reviews/week
Bus factor: 3 services gain backup
OPTIMAL HIRE PROFILE
Priority skills: React Native, GraphQL
Nice-to-have: iOS native, CI/CD experience
Rationale: fills knowledge gap in mobile API layer
How It Models
Built on your real data, not generic benchmarks
01
Every simulation runs against your actual team data — commit history, review patterns, knowledge graph, sprint performance.
The model knows who reviews what, who owns which services, and how your specific team dynamics work.
02
The knowledge graph computes dependency and blast radius for every engineer.
When you simulate a departure, the model traces every service, repository, and workflow that person touches — including indirect dependencies other tools miss.
03
Simulations use Monte Carlo sampling to give probability distributions, not single-point estimates.
You get P50, P75, and P90 outcomes because the future is uncertain and pretending otherwise is dishonest.
04
Results improve over time as Gitrevio accumulates more data about your organization.
The first simulation after setup uses 90 days of history. After a year, the model has seen seasonal patterns, team evolution, and real departure outcomes to calibrate against.