Dap didn’t just make FutVolt faster — it made the multi-app platform build possible

Meet FutVolt

FutVolt builds technology for football training and player development — a multi-app platform that ties training product, coaching workflows, and quality gates into one delivery system. The company came in as a growing startup still finding its shape: they asked for a flexible, adaptive development environment rather than a fully-determined spec — the product was not 100% defined before kickoff.

Challenges

FutVolt’s hardness was different, but real:

• Multi-app surface area

  — not a single CRUD app; a platform of products that have to move together

• Product depth

  — on the order of ~22 game modes, each with behavior, edge cases, and regression risk

• Quality under pace

  — test coverage was low and the existing suite was hard to rely on, while throughput needed to climb

• Small headcount

  — two software engineers and a designer, with a lot of surface area to cover for a team that size

• Unformed requirements

  — the product wasn’t fully locked before kickoff; the build had to define the product while converging on it

That mix creates a familiar trap: keep the team small and the roadmap slips, add headcount and coordination cost eats the gain, or — for a startup still mid-shape — stall in endless theoretical definition while the product never gets concrete. An agent in the loop is what breaks that trap: it multiplies execution without multiplying headcount, so the real question isn’t whether AI can write a function, it’s whether a small team can ship platform-scale work, keep the codebase honest, and turn a client’s fuzzy intent into something concrete — fast.

Approach

FutVolt needed capacity that could flex while the product was still taking shape — not a rigid, fully-spec’d build plan locked on day one.

Engagement shape:

• What the client bought

  — a project — scope agreed up front, the way projects are conventionally sold.

• What actually happened

  — with Dap and flexible capacity underneath — the same dedicated people rotating on and off different attended sessions, and spawning unattended sessions to maximize work. FutVolt asked for an adaptive environment, and that’s what it got: Crunchloop and Dap spun quick trials and put them straight into the client’s own environment to try — not just into a deck.

A lean, dedicated delivery unit — the same two software engineers, one designer, and Dap from start to finish — on one shared path to production, sized to absorb change rather than freeze scope up front. Dap was capacity on that unit, not a side plugin: same repo reality, same quality bar.

Results

1. Platform-scale throughput on a lean team

~5 PRs/day at peak (Jun 2026); on the order of ~150 PRs/month at the high month; 336 PRs — the initial-delivery-stint benchmark. Weekly commit activity ramped through May–Jun 2026 as the loop tightened, peaking on the order of ~47–48 commits/week.

The point: pace without a matching headcount spike.

2. Process and collaboration under load

GitHub Flow held while throughput climbed — the path to production always deployable, short-lived feature branches, every change via PR, CI green before merge, merge shipped straight to production. Fewer collisions in how the squad shipped together.

The point: speed did not mean skipping process or burning collaboration.

3. A measurable agent share on the path to production

PR-level attribution across 336 PRs:

• 20.5%69 PRsUnattended Dap PRs — fully Dap-authored, no human intervention
• 79.5%267 PRsAttended Dap PRs — Dap + engineers running the sessions

The point: 20.5% of PRs were delivered unattended — substantial features shipped end-to-end, not an AI-suggested snippet. The remaining 79.5% carried direct human guidance or intervention.

4. Quality and communication stay in the loop

Quality and client communication stayed part of delivery, not a weekend tax:

Automations that made the difference:

• E2E Story Builder

  — built the E2E suite from nothing: 0 to 29 feature files over the engagement, covering 100% of the planned story backlog. Without it, this would have been impractical, or would have taken a much larger team much longer.

• Improve Test Suite

  — 11 PRs to fix flaky tests; RSpec coverage now sits at 92.27% — so throughput doesn’t come at the cost of a suite nobody trusts.

• Code Quality Refactor

  — 18 PRs refactoring already-existing routes; makes continuous refactoring viable, where it would otherwise be sporadic while technical debt grew.

• Weekly Report

  — a client-facing changelog that tells FutVolt what changed and why.

The point: the same system that adds throughput also spends cycles on the suite — quality work that doesn’t happen without agent capacity on the team.

With Dap on the team, engineering capacity stopped being the constraint — not because headcount exploded, but because the loop absorbed more of the build, test, and refactor load while humans kept judgment on the path to production.