The packages are the product.
Projects adapt to the platform rather than the reverse, which keeps one well-reviewed implementation instead of several diverging ones.
Shared engineering
Built once. Relied on everywhere.
The internal library monorepo every Starduxe project installs — identity, payments, commerce, storage and more.
01 / THE CONTEXT
Every project needs the same unglamorous foundations: sign-in, permissions, payments, file storage, notifications, webhooks. Rebuilding them per project is how small differences in security and correctness creep in.
02 / THE FOCUS
The platform is a set of packages each project installs rather than copies, so a fix to authentication or payment handling reaches every product that depends on it instead of only the one where the bug was noticed.
The priorities that shape the product and the experience.
Projects adapt to the platform rather than the reverse, which keeps one well-reviewed implementation instead of several diverging ones.
An architecture document is updated in the same commit as the code it describes, so it never quietly drifts out of date between releases.
The same libraries are designed to move from installed-per-project to a hosted backend as the products using them grow.
The decisions that shaped how this was actually put together.
Every product needs authentication, permissions, payments, storage, and notifications. Rebuilding those per project isn't just repeated effort — it's how small, quiet differences in security and correctness appear between products. A fix applied to one codebase never reaches the other four. Installing shared packages means a correction to session handling or payment reconciliation propagates to everything that depends on it.
The platform's rule is that a change to how a package works updates its architecture document in the same commit, not afterwards. A document corrected later was wrong in the interval — and that interval is precisely when someone reads it and trusts it. It's a small discipline that determines whether documentation is an asset or a trap.
The packages are structured so they can migrate from installed-per-project to a hosted backend the projects talk to. That's a commercially different product, and building toward it deliberately — rather than discovering later that the architecture won't allow it — is the reason the boundaries between packages are drawn where they are.
Tell us about the challenge you’re working on. We’ll help find a useful place to start.
GOOD THINGS START WITH A CONVERSATION.
YOUR NEXT CHAPTER STARTS HEREAn ambitious idea. A fresh challenge.
Something you can’t stop thinking about. We’re listening.