Delivery platformIn production2025 — ongoing

Sill

The layer every engagement starts on.

Accounts, permissions, billing, notifications, admin, audit logging, multi-tenancy and background jobs, written once and hardened in production across every build. It is the reason a four-week delivery window is a commitment rather than an ambition.

~60%
of a typical build, already done
In production
across every build
One codebase
not a copy per client

The problem

Most of a quote is plumbing nobody should be paying for twice

Logins, roles, billing, notifications, an admin screen, audit logs. Every project needs them, none of them is specific to a business, and firms that rebuild them each time are charging clients to solve a problem they already solved last quarter.

How it was built

In order, and why.

  1. 01

    Build it properly once

    Not extracted from a client project after the fact, but built as infrastructure with its own tests, its own release process and its own operational burden.

  2. 02

    Depend on it

    Charten, Larder and InvtoryX all sit on it. Every live project depending on the same foundation is what stops it rotting, because a defect surfaces on our side first.

  3. 03

    One codebase, not copies

    A fix to the permissions layer reaches every project on the platform, including work that shipped a year ago. Forked copies would each rot separately.

  4. 04

    Harden continuously

    Security advisories, dependency updates and the fixes production incidents teach us, applied centrally rather than per project.

The part that was actually hard

A platform is only real if its authors depend on it

Shared foundations decay when the people maintaining them do not use them. The discipline that keeps Sill honest is that every live project depends on it, so a permissions bug or a billing edge case surfaces on our side before it surfaces on a client's. The maintenance is work we would be doing regardless, and every client on the platform inherits it: the fix lands once and reaches all of them.

What it does

The features that carry it.

01

Accounts & authentication

Sessions, MFA, passkeys and SSO, with recovery flows designed rather than improvised.

02

Roles & permissions

Role and attribute-based access enforced server side, with tests asserting what each role cannot do.

03

Billing & subscriptions

Plans, proration, trials, dunning and failed-payment recovery, charging real customers every month.

04

Multi-tenancy

Row-level security at the database, so a forgotten filter in application code still cannot return another tenant's data.

05

Audit logging

Append-only records of who did what and when, retained and queryable before anybody asks.

06

Background jobs

Durable queues and scheduled work that survives a restart without losing anything.

Outcome

What actually changed.

01

Around sixty per cent already built

Accounts, permissions, billing, notifications, admin, audit logging, multi-tenancy and jobs exist before a project starts, which is what makes a four-week quote possible.

02

One fix reaches every project

A security patch or a permissions bug is fixed once and lands everywhere on the platform, including work that shipped a year earlier.

03

Hardened by real usage

Billing takes real payments monthly and tenant isolation is enforced at the database, so the hard parts have been exercised rather than assumed.

In hindsight

What we would do differently.

We let the admin backoffice grow feature by feature instead of designing it once. It never got the scrutiny the layers underneath it did, and it is now the part of the platform most likely to need a rewrite. Shared infrastructure decays wherever nobody is looking, and the tooling that only staff use is always where nobody is looking.

Built with

The stack underneath.

API
NestJS, Prisma, PostgreSQL, BullMQ
Web
Next.js, React, TypeScript
Mobile
Expo, React Native
Shared
OpenAPI codegen, typed clients, shared config

Where it stands today

In production and continuously maintained. It is not a product we sell — it is the foundation client work is built on, and the honest explanation for how a small team ships this much.

Practice areas this evidences

Tell us what you’re trying to build.

If something here looks like the problem you have, say so and we’ll tell you how close it actually is.

Reply time

One business day, from an engineer

Based in

Orlando, Florida · serving the United States

What happens next

  • A reply within one business day, from an engineer
  • A thirty-minute call, with no qualifying call before it
  • A written scope and a fixed number, if it fits