For the past month, I've been doing something most people threaten to do in Slack channels at 11:48 PM: I left my 9–5 and started building what has frustrated me for years. Not some "founder journey" sitcom. Not a productivity app. Not another dashboard on top of a dashboard.
I hit the point where maintaining the old way felt worse than risking everything to build the new way.
I'm building the system I kept waiting for someone else to make.
Once I stepped away from the job, the fog finally lifted.
The moment it clicked
No dramatic "I can't take this anymore" resignation. Slow clarity settling in. Everywhere I looked, developers were writing more code than ever, AI was producing even more on top of that, and yet we were all still bottlenecked by the same brittle CI/CD machinery that predates half the frameworks we use.
The industry accepted it. I didn't.
What finally pushed me over the edge: watching tools built a decade ago struggle to keep up with how fast we now generate code.
We build modern software with tools that guess their own dependencies, lose their own state, and take far too long to tell you something you already know.
Consider what we've normalized: a 200-line YAML file that defines a workflow, then re-runs everything from scratch because it can't remember what changed, then fails on step 47 because a dependency it should have known about wasn't cached correctly.
# This is what "normal" looks like now
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
- run: npm ci
- run: npm test
- run: npm run build
# ... 40 more steps that run every time# This is what "normal" looks like now
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
- run: npm ci
- run: npm test
- run: npm run build
# ... 40 more steps that run every timeEvery commit. Every PR. Every time. Starting from zero. Recalculating what it already calculated. Guessing what it should know.
The last month
I had space to think instead of patch and to rebuild instead of babysit. I spent the past month doing three tasks.
1. Seeing the real problem for what it was
Not the surface-level "CI is slow," but the deeper structural issues that make it slow, flaky, and unpredictable. When you look past the YAML and the logs, the actual problem is that the systems we rely on have no memory and no causality.
Everything felt like guesswork, and I was done patching guesswork.
The systems we use today treat every run as if it's the first time. They don't understand that if src/utils.ts didn't change, then the tests that only depend on src/utils.ts don't need to run. They don't know that the Docker image you built last week is still valid because nothing in the dependency chain changed. They throw away information that should be preserved.
# What happens now:
$ git push
→ CI starts from scratch
→ Installs all dependencies (even if package.json didn't change)
→ Runs all tests (even if only one file changed)
→ Builds everything (even if nothing that affects the build changed)
→ 15 minutes later: "All checks passed"# What happens now:
$ git push
→ CI starts from scratch
→ Installs all dependencies (even if package.json didn't change)
→ Runs all tests (even if only one file changed)
→ Builds everything (even if nothing that affects the build changed)
→ 15 minutes later: "All checks passed"# What should happen:
$ git push
→ CI understands what changed
→ Skips steps that don't need to run
→ Reuses work from previous runs
→ 2 minutes later: "All checks passed"# What should happen:
$ git push
→ CI understands what changed
→ Skips steps that don't need to run
→ Reuses work from previous runs
→ 2 minutes later: "All checks passed"The difference isn't just speed, it's about building systems that actually understand the work they're doing.
2. Reimagining the foundations
I mapped out what a compute engine would look like if you started fresh instead of dragging a decade of compromises behind you, something that can understand changes, reuse work with precision, and treat time as a first-class dimension instead of something to throw away run after run.
3. Putting it into motion
Less talking, more code. I'm not going to reveal architecture diagrams or secrets here; that's something you don't hand competitors as a snack platter. But the core pieces are real, the engine is taking shape, and the results are why I quit.
When you build something from first principles, the pieces click together in a way you don't get by "optimizing" old systems.
One month in, I've written more code that I'm proud of, and more code that solves real problems, than I did in the past year of pushing against legacy processes.
What is Layerun?
Layerun is the name, but it's not "another CI tool," and I'm not building a slightly faster version of something you already tolerate.
It's a new approach to validating, executing, and trusting code, a system that doesn't panic at scale, doesn't start from zero every run, and serves developers who want to move fast without rolling dice on whether their build will pass today.
The rest will make more sense once people can actually use it.
But here's what I can say: Layerun understands causality. It knows that if you change a comment in README.md, your TypeScript tests don't need to run. It knows that if your Dockerfile didn't change and your base image didn't change, the image you built yesterday is still valid. It treats time and change as first-class concepts, not something to ignore and recalculate.
The system automatically understands what needs to run and what can be skipped, without manual configuration or guessing. No YAML. No manual caching. No approximation.
This is the kind of system that should have existed years ago.
Why share this now?
I want people to understand the context. I didn't wake up one day and decide to "be a founder." I hit the point where ignoring the problem felt irresponsible.
Here I am, full-time, focused, and actually building the thing that should have existed already.
If you care about the future of how code gets validated and shipped, or you're tired of tools that stall out while the rest of the industry speeds up, stick around.
I'm building the thing I always wished existed, and I'm doing it without compromise.
Onward.