Open source
Most of what I build for clients is private. What is not is on this page — one complete application, a project template, a handful of forks, and the self-hosted tooling I run my own work on.
Bakeup — a whole application
Bakeup is multi-tenant SaaS for micro-bakeries: an online shop plus the production planning behind it, on Django, django-tenants and Wagtail, with each bakery's data separated at the database level rather than by a query filter.
It is open source in full — not a demo extracted from a private repository, and not a library. If you want to know how I structure a real application, its models, its tests and its deployment are all readable, and it has been in production since 2022. The Bakeup case study says what it does; the repository says how.
Contributing upstream
The way I contribute is unglamorous, and it is how most of it actually happens: when something in a project I am using is broken or missing, I report it, and where I can I send a patch. That includes Wagtail itself — my pull requests against the framework most of my work sits on — as well as the packages around it.
That matters more to a client than it sounds. A bug in a dependency is either a dead end or a two-day detour, and which one depends entirely on whether your developer is willing to open the package, understand it and push a fix back. I would rather fix the cause upstream than carry a workaround in your codebase for the next five years — a workaround is a decision somebody has to rediscover every time they touch that file.
Where a patch has not landed, or where a project has stopped being maintained, the fork stays public rather than rotting in a private branch:
- wagtail-metadata — SEO and Open Graph fields for Wagtail pages.
- wagtail-lazyimages — low-quality image placeholders, for pages that are mostly photographs.
- wagtail-newsletter — newsletter sending from inside the Wagtail admin.
- wagtailcolumnblocks — column layouts in a StreamField without handing editors a page builder.
- wagtailtrans — translated page trees.
- django-oscar-mollie — Mollie payments for Django Oscar, the stack behind Lifelessons.
Open source I run, not just write
The tooling behind my own work is self-hosted, on the same kind of server I put client projects on: GitLab for code and CI, Sentry for error tracking, Ansible for provisioning, Caddy in front, PostgreSQL behind, restic for backups, and Grafana with uptime checks watching the lot.
Partly taste, and partly the same argument the hosting page makes: if I am going to tell a museum or a university that their data stays in Germany, it would be odd to keep my own on somebody else's SaaS.
pretix deserves naming separately. The ticket shop on Museum Wilhelm Busch runs on it — entry, special exhibitions and vouchers. Open source turned that from a six-month build into an integration, which is the argument for it that actually reaches a budget holder.
Why a client should care
Not because open source is virtuous. Because it is the only public evidence of how somebody works at the level below the framework — and that is the level at which projects get stuck.
A worked example from this site. I have patched wagtail-metadata, and I chose not to use it here: Wagtail already provides the title, description and URL fields, so the gap was about two hundred lines, while the package would have forced a migration on every page model and added a dependency to keep current. Knowing a package well enough to patch it is also knowing when not to install it, and that judgement is worth more to you than the patch was.