I've been a software engineer for almost 20 years and watched wave after wave change the industry. With AI, I didn't want to look back a few years later and think, "I should have done something with that." I wanted to use my skills to build something and share it with the community.
The problem was time. I worked full-time as a DevOps engineering manager, often for very long hours. I had ideas for little apps, but very little time to build them.
Whatever I did had to somehow build itself.
An automated agency
My experience in web agencies gave me a starting point. I imagined an autonomous agency: give it a prompt, and it turns that prompt into a project. It writes acceptance criteria, creates tickets, and assigns the work to agents with different roles. A manager, QA, frontend, backend, infrastructure. They work through the project together.
It sounded simple: an automated way to go from an idea to a proof of concept in a matter of minutes.
In practice, there was a lot of ground to cover between that idea and what AI tools could reliably do at the time, plus I was also still learning how to build with them. So I put it on hold and went back to the drawing board.
That led me to AI infrastructure. I saw how fast the sandboxing providers were moving and felt the need to write a single service that could work with any of them. That sandbox service became the foundation for another startup idea: focused AI agents built on OpenClaw.
Back to Druks
Then I ran into the same problem again: I had no time to build all this. So I came back to Druks, starting with Software Factory to take a ticket through the stages needed to produce a pull request.
I built the workflows, connected the sandboxes, and added durable execution so work could recover after a restart.
Software Factory followed my own development process. As I built it, I realized someone else could use the same foundation to build a software factory around theirs.
But then why stop there?
The next app I built was Review. It responds to a mention on a pull request and gives feedback on the code. It was a smaller, separate job, and it could use the same foundation.
That helped me see what Druks could become: a home for agent apps, each with its own workflows and, where useful, its own interface. A task that started as a prompt or a loose automation could become an app inside Druks.
I put the other startup ideas on hold and focused on Druks and Drukbox together. Drukbox remained a standalone service, providing the sandboxes that Druks needed to run its agents.
How I use it today
These days, Druks helps me build both projects. A feature usually starts as a conversation with Claude Code, where we work through the details and anything that's unclear. Once the task is ready, I ask Claude to hand it over to Druks. Through the Druks MCP connection, Claude creates the Linear ticket and sets it in motion, and Druks picks it up from there.
It can handle small to medium-sized tickets with little intervention. I still review the code most of the time. I am building on the same system I am changing, so I watch for regressions and sometimes give it more direction.
Little by little, I'm using Druks to automate more of what it takes to build and run these products. It scans my Twitter feed and suggests things worth engaging with. It also watches my mailbox and proposes actions for me to consider.
If you want to try Druks for your own projects, here's the quickstart.