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. No deploy. No spinner. No Developer Console. No log files.
When something fails, you set a real breakpoint in VS Code and run the test in debug mode. Execution pauses. 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, not writing - watching a spinner. 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, not 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.
Not a watered-down version. Not a mock framework. The actual thing - a runtime that executes your code locally, with a real database, so the feedback loop is tight enough to think clearly while working.
Built by a Salesforce developer who got tired of waiting.
I built Nimbus because I wanted it to exist. Not as a product to sell - as a tool to use. The kind of tool that makes the work feel good again.
That shaped every decision. Simple where simple is enough. Transparent about what it does and doesn't support. Fast enough that running tests is something you want to do, not something you postpone.
Developer joy is not a marketing word here. It's the requirement. If I don't reach for it instinctively in my own workflow, it's not done yet.
Edit. Run. See the result. That's the loop every other language already has.