gm-libs, the packages every Webanion frontend and backend starts from
A family of versioned, framework-neutral packages that every Webanion frontend and backend starts from, with a NestJS layer on the server and React, Vue and Expo bindings in the client: authentication with passkeys and single sign-on, feature flags, an audit trail, multi-tenant data, encryption, files, documents, messaging, real-time and offline, webhooks, workers and a UI kit. Each lives in its own private repository with its own releases and is installed from the studio's private npm registry, and the studio's console shows which consumer is behind on which release.
Md Moniruzzaman
The Full Story
Why a studio's clients are better off when authentication, audit and feature flags are solved once, versioned and reused everywhere.
Every backend was starting from zero
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 once
The 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 safely
The 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 down
The 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 job
Alongside 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.
- Foundation and data: core (errors, request context, a logger that redacts credentials, typed configuration that fails fast on a missing secret, money, pagination, rate limiting, idempotency, health) and db (multi-tenant Postgres, one database per tenant, with migrations and models).
- Identity and access: auth, flags, audit, and crypto for envelope encryption of fields and secrets with keys that rotate.
- Files, documents and messages: media for storage and signed uploads, pdf, tabular for streamed CSV and XLSX export and validated import, notifications for email, SMS, push and team chat, and chat for real-time conversations.
- Real time and offline: realtime for authenticated per-channel events, with a reconnecting client for React, Vue and Expo, and offline for a per-user cache and a write queue that sends exactly once, in the browser and in Expo apps.
- Integration and runtime: webhooks signed to the Standard Webhooks spec, worker for Temporal, web for a hardened headless browser and an outbound fetch that refuses internal addresses, datavault for streamed, encrypted database backups, and mcp for building MCP servers.
- Interface: ui, from design tokens to React, Vue, Next.js and Expo components.
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 system
Because 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 watched
Every 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 registry
A 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.
You May Also Like
Fully Booked - Promotional and Tutorial Video Production
A promotional video that walks a UK minibus operator through Fully Booked's benefits in the order they matter, made from the real app rather than stock footage. It opens on the operator's own problem, gives each benefit one beat on a real screen, and was cut to several lengths, from a few-second hook for social feeds to a full version for landing pages and the store listings.
Md Moniruzzaman
Jun 24, 2025
Fully Booked - Visual Asset Design with Photoshop
Store screenshots, a feature graphic, an app icon and email art, made in Photoshop from real screens so a young platform looks established to operators. The screenshots tell the pitch in five swipes at every size Apple and Google require, every email opens with its own illustration in the brand colours, and the icon and splash screens carry the logo of two hands meeting.
Md Moniruzzaman
Jun 24, 2025
Fully Booked - UI/UX Design for Mobile App and Admin Panel
Every Fully Booked screen began as a sketch the founder approved before any code was paid for, and each answers an operator's or a customer's problem. The operator home screen became a menu of income, Get Covered kept the order of its hand-drawn flow, quotes and cancellation letters came from the founder's own wording, and the admin grew from five wireframed tabs into the network's control room. The MVP's screens were designed by another designer at Webanion; I redesigned phases 2, 3 and 4 myself in Figma, working from these flows.
Md Moniruzzaman
Jun 24, 2025
The blog is field notes from production: architecture decisions, AI systems that survived contact with real users, and infrastructure that pays for itself. Written from the work, not about it.