Built for the work.
Improved in the work.

01 / SoloPilot · 2025

It began with a question.

Somewhere in 2025, I realised that AI was going to change how software is developed. With my IT background, I was watching the first steps of large language models producing code. The technology was still immature, but I could see its potential to improve the repetitive processes we deal with in our work.

I started SoloPilot as a hobby project to find out how far this could go. It gave me a practical way to learn: build something, try it, see where it breaks, and improve it.

Visit SoloPilot ↗

Currently opens the application sign-in page.

02 / Swimlaner · From learning to project work

A first version in days.
A useful tool through use.

A year later, I had developed a framework that lets me build a first version of a smaller tool in a matter of days. That made it practical to act on the frustrations I encountered in projects.

Swimlaner was the first tool I built specifically to improve my efficiency in project work. Making processes, responsibilities and handoffs visible is something I need to do with clients. I wanted a tool that supported that work in the way I actually do it.

Explore Swimlaner ↗

03 / List Walker · A problem inside an engagement

Then came a master data workstream.

Shortly afterwards, I built List Walker to help coordinate a workstream cleaning up master data in a production company with a decentralised structure.

That was a specific coordination problem in a real engagement. It gave the development a clear purpose and a place to test whether the tool was useful.

Today, List Walker supports working through structured questions and open points. Its origins are in the day-to-day effort of getting a workstream moving.

Explore List Walker ↗

04 / The learning cycle

The person building it
also has to use it.

I use these tools myself. When something is awkward, missing or simply not how I want to work, I can change it. Short development cycles let me take that experience back into the product and try the improvement in practice.

The tools become more thoroughly tested as I use them in projects. A first version is the beginning of that learning.

1. 01Use it in the work

   Find the friction that actually matters.

2. 02Make a focused change

   Improve the part that gets in the way.

3. 03Put it back to work

   See whether the change helps.

Why this belongs in the community

Your experience can shape what gets built.

Experienced practitioners recognise problems that are easy to miss from outside the work. A repeated handoff, a cumbersome preparation task, a decision that keeps getting lost: these are useful starting points for a conversation.

That is another reason to bring this community together. We can share what we have learned, challenge an idea and explore whether a useful tool could come out of it.

Community membership is free. Commercial tools remain a separate, optional offer.