Every backend a client pays for needs the same foundations before it does anything the client cares about: sign in, sessions, permissions, configuration, file storage, emails, PDFs, background jobs, an audit trail. Written fresh for each project, those parts cost weeks, differ from project to project, and carry their own bugs.
gm-libs is the answer: the plumbing extracted from work that had already proven it, hardened into packages with versions, documentation and changelogs, and reused across the frontends and backends the studio builds.
### Sign in and permissions, solved onceThe auth package brings Argon2id password hashing, short-lived access tokens with rotating refresh sessions, and relationship-based permissions on OpenFGA, so a rule like "branch staff see only their branch" is a declared model rather than checks scattered through the code. It also carries social and OIDC sign-in with account linking, passwordless sign-in, multi-factor authentication, passkeys and single sign-on. A new backend gets all of it by importing one module.
For the client that means security that has already been hardened and tested on a finance platform, not reinvented under a deadline.
### Features switched on safelyThe flags package decides what is shown and run for each tenant, branch, role or person, and it never blocks a request: flags are read from memory, and if the flag server cannot be reached every flag falls back to a safe default, off unless the team chose otherwise. It pairs with authorisation rather than replacing it, so nothing appears unless the flag and the permission both say yes.
Clients can release a feature to one branch or one person first, watch it, and widen it without a deploy, which is how the Al-Insaf team runs its own features.
### An audit trail that never slows anyone downThe audit package records who did what, where and when on every write, classified by category and severity, and hands each entry off the request path to be written in batches. A slow or failing audit store is logged and never blocks the person using the system, which is what makes it safe to audit everything that matters.
### Every package, one jobAlongside auth, flags and audit, the family covers the rest of what a frontend and a backend need, each package doing one job and wired the same way: framework-neutral code underneath, a NestJS layer for the server, and React, Vue and Expo bindings where a package reaches the client.
Beside them, devkit is the check every library runs before a release. Every package lives in its own private repository with its own releases, so a client's system changes only when its team takes the new version.
### One fix, every systemBecause the studio's frontends and backends share the same foundations, a security fix or an improvement made once reaches every one of them through a version bump, with a changelog saying what changed and why. Semantic versions are honoured across releases, so no client's system breaks because another client needed something new, and the console shows the same day which consumer has not taken a release yet.
For clients the result is faster delivery, fewer surprises and a product built on parts that have already been through production elsewhere, including the ledger-grade finance platform in the Al-Insaf story.
### Every package, published and watchedEvery package is installed from the studio's private npm registry, and the studio's console reads that registry the way a consumer would. It pings the registry, reads every version of every package with its publish time, packed size and integrity, and reads the consumers' own manifests on their default branch to judge whether each dependency resolves to the latest release. A library family is only as useful as the proof that every system using it is current, and this is where that proof lives.
On the capture day, 30 September 2026, the view showed the registry up, every package published, a recent backup of the registry itself, and every consumer on the latest releases apart from the studio's own tools, still on older releases of core and pdf.
### From a GitHub Release to npm install, through the studio's registryA tag on a library runs its release on GitHub and attaches one packed file to the release. A sync inside the cluster publishes that exact file every five minutes, so the release and the registry hold the same bytes, checked again every night. Reads need a login and the public name refuses writes. GitHub Packages was ruled out because the libraries and their consumers live in different organisations.