Why a local Apex runtime exists.
A trigger handler change. Small - a field assignment, a condition, maybe ten lines. You know exactly what it needs to do. You push the deploy to the sandbox.
And then you wait.
The deployment sits at Queued. Two minutes. Five minutes. No indication of what's happening or when it will move. You've seen this before. Sometimes it completes. Sometimes it doesn't.
This time it doesn't.
You abort the deployment and open the Developer Console - the old one, the one that looks like it was built for a different decade - and make the change directly in the sandbox.
To test it, you run the test class. But parallel execution on this org is slow - too much contention - so you switch to synchronous. Synchronous only allows one class at a time. You pick the most relevant one and run it.
The test passes. No coverage report. Synchronous runs in the Developer Console don't show aggregate coverage. You have no idea if you've broken the 75% threshold. To find out, you'd have to run everything - which means parallel - which means waiting again.
You make a judgment call and move on.
A test failing with an unexpected value. You try to debug it. You download the log from Setup, open it, and start searching for the variable name across a wall of text.
You try the Apex Replay Debugger. When it works - and it often doesn't - you're stepping through a recording of what already happened, not through live code. You change something. The recording is stale. Redeploy. Re-capture. Start over.
You figure it out eventually - not because the tooling helped, but in spite of it.
The trigger handler change that started this story takes the same ten minutes of thinking. The test-and-verify loop takes thirty seconds.
Edit the class. Run nimbus test "TriggerHandlerTest.*". Results in the terminal. Pass or fail, you know immediately. Change the code, run again. There is no deploy, no spinner, no Developer Console and no log file.
When something fails, you set a real breakpoint in VS Code and run the test in debug mode. Execution pauses with every variable in scope. You step through the logic as it runs. Find the problem, fix it, rerun.
Coverage is always current. Every run produces it. You know your threshold status before you commit, not after CI tells you an hour later.
Deployment wait time doesn't show up in sprint metrics. It shows up as "the ticket took longer than expected" - absorbed into estimates as a permanent, unexamined tax.
A developer running 20 test cycles per day against a sandbox spends somewhere between 2 and 4 hours waiting, not thinking or writing but watching a spinner. That is half a working day, every day, on a problem that's already solved for every other language on the stack.
It stayed this way because Salesforce moved the difficult parts to the platform, and the platform runs in a data center rather than on your laptop. Nimbus moves them back.
Nimbus started from a simple observation: every other language on the stack already had fast local tests, real debuggers, and coverage that was always there. Apex didn't.
That meant a runtime that executes your code locally, with a real database, rather than a watered-down version or a mock framework, so the feedback arrives fast enough to think clearly while working.
Nimbus was built by a Salesforce developer who got tired of waiting.
I built Nimbus because I wanted it to exist, as a tool to use before it was a product to sell. It is the kind of tool that makes the work feel good again.
That shaped every decision. It is simple where simple is enough, transparent about what it does and doesn't support, and fast enough that running tests is something you do rather than something you postpone.
The requirement is that I reach for it instinctively in my own workflow. If I don't, it's not done yet.
Edit, run, and see the result, the way every other language already works.