The problem
I wanted to build real products instead of treating every project like a classroom exercise. Qyverix is where that happens, and the thing nobody tells you is how little of it is writing code.
Shipping client work on a deadline is an operations problem long before it is an engineering one. Domains, mail, authentication, roles, environments, backups and logs all have to exist, and then they have to keep existing, and somebody has to be the reason they do.
The system
- Client brief
- Buildsite · CMS · commerce
- Deploycloud, environmentsDomains & mailDNS, webmail
- Accessauth · RBAC · secrets
- Operationslogging · backups · support
The build is the short part. Everything below the line is what makes it somebody's job forever, and that somebody is me.
What ownership actually meant
The part I am most pleased with is Qyverix Cloud, mostly because it is the kind of infrastructure layer I wanted to use myself, which turns out to be a reasonable specification to build against.
Delivery
That last one is a standard the studio publishes, which means the site you are reading has to meet it too. It seemed fair.
What I learned
Real systems do not care that you are still a student. Nothing about a broken DNS record is different because the person who owns it has an exam that week.
That sounds like a complaint. It is the opposite: it is the single most useful thing college could not have taught me, and the reason I stopped treating deployment as the end of a project rather than the beginning of one.
What I would change
We said yes to too much variety early on. Every new kind of project meant a new set of operational edges to maintain, and maintenance compounds in a way that building does not. Narrower would have been faster.