First commits in. Nothing does anything yet, but the scaffolding's there.
After years and years of planning, I've decided to put pen to paper, as it were, and get this started.
Gingerbread is an idea I've had on my mind for 16 years - since 2010. Back then, I was starting out freelancing and wanted SO badly to make my own lil' invoicing tool. Something to compete with Freshbooks and the like. Then I found Pancake, the self-hosted invoicing app, and I bought it, and ended up working on it for nearly 10 years. I learned a lot, but it was never my vision - I didn't own it, and I didn't control its destiny. I wanted to make something that was mine, that I could shape and grow in the direction I wanted, without having to ask anyone's permission. When something's yours, it's different. I can spend literally all of my time on Gingerbread, and it's OK, because it's mine. I'm not doing it for money, I'm doing it for the love of building something great. I want to make something that I'm proud of, that I can share with the world, and that can help people. I want to take everything I've learned over the years and put it into this project, and make it the best it can be.
And I'm going to go back to my roots with this one: It's going to be a self-hosted app. Nobody does those anymore, not really, not for shared hosting. First, all apps now are SaaS, and second, the ones that are self-hosted, are all Docker-based, which is great for VPSes and cloud hosting, but not so great for shared hosting. I want to make something that's as easy to install as WordPress, something that can run on a $5/month shared hosting plan. It's a lot of extra self-imposed limitations, but I think it's worth it.
I am betting that there are a lot of people out there who are fed up with subscription everything, who want to have control over their data and their software, but who don't have the technical know-how or the resources to set up a VPS and Docker. And of course, I'll provide Docker images and a hosted SaaS version for those who want it, but I want to make sure that the self-hosted version is accessible to as many people as possible. The hosted SaaS version will be there despite my general antipathy toward SaaS, because some people genuinely don't want to deal with hosting, and that's fine. "fine, I guess I'll take your money" haha. But the self-hosted version is the heart of the project, and that's where I'm going to put most of my focus.
Gingerbread is a monorepo with five apps:
website/: this marketing site (Next.js, static export to Cloudflare)frontend/: the Gingerbread app (Next.js, also static export to Cloudflare)backend/: self-hostable Gingerbread backend, that will ship to customersplatform/: cloud-only SaaS control plane (updates, licensing)installer/: single-file PHP installer for shared hosting
Each one deploys independently.
Nothing runs on the host. Everything's in Docker via OrbStack, and there are two mutually-exclusive dev environments:
- Path A simulates shared hosting: MySQL only, database for cache/queue/sessions, MySQL fulltext search.
- Path B simulates a VPS or hosted tier: Redis, Meilisearch, a worker daemon, all the good stuff.
Both exist so features can't silently drift toward the best-case setup. You find out immediately when something won't work on shared hosting, instead of months later when a customer spins up their first shared-hosting install.
The installer container is deliberately primitive: Apache 2.4 with mod_php, rewrite module disabled, PHP stripped to core extensions plus pdo_mysql. Shared hosts are unpredictable, so the installer has to cope with the absence of nearly everything. Obviously the app itself also has to cope with almost nothing being enabled, but the installer can at least gate against the most common showstoppers and tell the user what they need to do to get things working.
Right from the outset, I'm going to take advantage of Hardcore PHPStan and Hardcore TypeScript, to catch as many issues as possible early on, and I want to make sure that the code is as robust and maintainable as possible from the get-go. I know it's going to be a lot of work, but I think it's worth it in the long run for maintainability and stability. As a solo dev, I don't have the luxury of a team to catch my mistakes, so I need to be extra diligent about catching them myself.