Made in
our own lab.
Some parts were needed so often that it was worth building them properly once. They came out of client projects, they are maintained like products, and they are available wherever the next project needs them.
Talk it through →Built for a project.
Kept as a product.
A project needs it first
Nothing here started as a product idea. Each piece exists because a deadline needed it — and turned out to be needed again three projects later.
Then it gets maintained
The difference between a tool and a leftover script is upkeep. These get versions, tests and attention when a platform changes underneath them.
And it stays ours
Because we own them, they can be bent to fit a project. No waiting for a vendor roadmap, no feature request into the void.
Four of them,
in daily use.
Not a catalogue — the pieces that earn their keep. Each one runs in production somewhere right now.
Appify — the app shell
Turns a working web application into a store-ready iOS and Android app from a single configuration file: launch screen, icons, languages, permissions and push.
Push backend
Notifications from our own infrastructure instead of a foreign service that also learns who the users are. One endpoint, both platforms, data where it belongs.
Wiki — a place for what a team knows
Pages, boards and comments, organised the way a small team actually works — and reachable by a language model, so knowledge can be asked for instead of searched.
MCP interfaces
The systems we build get an interface a language model can operate: a shop catalogue, a trade ERP, our publishing system. Same rules as for a person, and everything is logged.
MADLAB // Publishing.
Now open to everyone.
Our publishing tool gives a website an interface a language model can use — write a page, change a section, check the links, publish. It is how this site is built. Since October 2026 it is a product of its own: the first website is free, hosted in Switzerland or on your own web space.
A tool kept private
gets sloppy.
As soon as something is used outside the team that wrote it, the edges have to be finished: documentation, sensible defaults, error messages a stranger can act on. That discipline makes the tool better for our own projects too — which is the actual reason we do it.
Something here
that fits?
Whether a tool goes into a project as it is, or gets extended for it — both start with the same conversation.
What else
we work on.
