// about
An engineering practice built around the inner loop.
InnerLoop Resources is a small, senior team of systems engineers, performance specialists, and platform architects. We work inside your codebase, not above it — measuring, refactoring, and shipping changes that compound.
Why the inner loop matters.
In any sufficiently large engineering organization, three loops decide how fast you actually move. The CPU loop — the dozen instructions that run hot, where a missed cache line is a 200× tax. The developer loop — edit, build, test, deploy, observe — where a 90-second test suite is the difference between flow and frustration. And the system loop — the request path, the queue, the retry — where a single misplaced lock becomes an incident postmortem at 03:00.
Most consulting engagements optimize one loop and break the other two. We don't. Every change we ship is measured against latency, throughput, build time, and developer signal — together. If a refactor speeds up the hot path but doubles CI time, we keep iterating until both move the right direction.
How we work.
A typical engagement starts with a two-week diagnostic: production profiles, CI metrics, a representative slice of pull-request history, and one-on-ones with the engineers closest to the pain. We deliver a written architecture review with three to five concrete moves ranked by expected impact and implementation cost. From there, we embed with your team for 8 to 16 weeks — pairing on the hardest changes, writing the runbooks, and transferring ownership before we leave.
We don't deliver decks. We deliver merged pull requests, regression-gated benchmarks, and a team that can keep moving the numbers after we're gone. Every recommendation comes with a measurement plan; every measurement plan ships as code in your repository.
Principles we operate by.
- 01 · Profile before you guess. Intuition about performance is wrong roughly half the time and confidently wrong the rest.
- 02 · Optimize the loop, not the line. A 5× speedup in a function called once a day is a rounding error.
- 03 · Make regressions a build failure. Anything you measure but don't gate, you eventually lose.
- 04 · Velocity is a system property. A senior team and a slow CI are still a slow team.
- 05 · Leave the keys. We're done when your team can reproduce every result without us.
// what we measure
Velocity is plural.
Developer velocity is not lines per day. It's how often a small change reaches users, how often a regression is caught before it does, and how much of the working day is spent waiting on a machine. We track the four dials below across every engagement.
PR → prod median
Test signal kept
On-call hours cut
Flaky-test rate cut