Case study · 02 of 27

NomadSuite: the internal platform every company in the group runs on

A group of small companies shares people, inventory and a sales pipeline, and none of the off-the-shelf tools fit all three without paying for three separate products and reconciling them by hand. NomadSuite is the internal…

Role: Sole architect and developerStack: Next.js (App Router) frontend, NestJS-style backend modules on Prisma and PostgreSQL, role-based access control, multi-company data model, Claude for the design-generation featuresStatus: In use across the operating companies of the Nomad Universe group
NomadSuite: the internal platform every company in the group runs on, live site
Sign-in screen of the live internal platform, suite.nomad-universe.comOpen full-page capture ↗

Context

A group of small companies shares people, inventory and a sales pipeline, and none of the off-the-shelf tools fit all three without paying for three separate products and reconciling them by hand. NomadSuite is the internal platform I built to replace that: one login, one company switcher, and modules for HR and leave, inventory, and bid-and-proposal work, with role-based permissions per company.

What I built

Multi-company foundation

A Company and UserCompany model with its own RBAC layer (roles and members), so one person can belong to several companies with different permissions in each and switch between them without logging out. Dashboard preferences are stored per user. New-account requests go through an approval flow rather than open sign-up.

HR and leave

Employees, departments, leave types, public holidays and per-company leave settings as first-class data. The interface is built around the way people actually ask about leave: a Wall Chart showing who is out when across a team, an approvals queue, an activity log, and a per-employee "My Year" view that shows an individual their entitlement, what they have used and what is booked. Entitlements are computed, not typed into a spreadsheet.

Inventory and warehouse

A live folder tree of inventory (folders, items, tags, assets), item-level activity history, search, tagging, workflows for moving stock through states, and reports including low-stock views. It replaced a third-party inventory subscription with something the group owns.

BPS: bid and proposal, with AI doing the creative first draft

This is the module that surprised people. The events business responds to RFPs that need a staging and décor concept, quickly. BPS takes the RFP (event name, client, theme, constraints) and uses Claude to generate a spatial stage-design concept together with a complete image-generation render prompt, and separately generates décor concepts for table setups and centrepieces, extracting a colour palette from each. Everything a proposal produces (the RFP analysis, saved concepts, stage designs, graphics prompts) lands in one activity feed, and any item can be exported as Markdown to drop straight into the proposal document. It turns the slowest part of a bid into a starting point that a designer refines rather than a blank page.

What is designed but not yet shipped

The platform's subscription and billing layer, and scheduled report subscriptions (low-stock reports on a cadence, delivered by email as CSV or PDF), exist as designs: a subscription-management interface including the cancellation state, and reference mockups for the report-subscription flow. The backend for Stripe billing and the report cron are the next build phase. I say so plainly here because an earlier version of my resume described them as delivered, and when I checked the code they were not.

Decisions worth noting

Evidence

The repository lives under the Gentoo-Tickets organisation with mirrors under my own accounts. Module structure and data model as described above are the current main branch.

Next step

Have a system like this to build, rescue or scale?

I run technology for several companies at the same time and take on a small number of fractional engagements. The first step is always a scoped audit.