I published capsize-commons, then used it in sites that already existed. A shared package does not help much if every live site keeps its own copy of the same settings and health checks. Shipping it was only the start.
The Python package now carries shared settings construction, logging, health/readiness routes and small HTTP helpers. The TypeScript side is published as @capsizellc/commons. The first adopters included Capsize Online, joecurlee.com, the WXRQ admin surface and other Django sites. Each site kept its own application. They stopped maintaining separate versions of the same foundation.
The stack is deliberately boring: Python packaging, Django, a small TypeScript package, CI and trusted publishing. The technical angle is the adoption seam. A shared helper has to preserve the old site's behavior while making the next site easier to start. That means compatibility checks, a versioned health contract and a migration that can be reviewed one site at a time.
I can now fix a shared retry or settings bug once, publish a version, and update each site when I am ready.
The source is capsize-commons on GitHub. The public sites that use the pattern include capsize.online and joecurlee.com. The release context is in the Capsize four-week overview.
A practical adoption order
Start with one shared behavior that is easy to observe. Health and readiness routes are a good candidate because a smoke check can compare the old and new responses. Publish a small version. Adopt it in one site. Run the same check. Only then move the next site.
That sequence keeps a shared library from becoming a second monolith. The library owns the common contract. The application owns the reason it exists.
The first adopters are deliberately different. A project portal, a personal site and a radio admin do not have the same job, but they do need the same answer for health, settings and a few boring operational details. A shared package earns its place when that common answer gets easier to maintain without flattening the applications around it.
The package is small on purpose. It should remove repeated setup, not become the place where every application-specific choice goes to hide.
That restraint is what makes the next adoption reviewable.
Top comments (0)