Every project we ship leaves something reusable behind. These are the packages we maintain across client work — the reason a second system costs less than the first one did.

What is in here

Three kinds of shared code.

Each one exists because we got tired of writing it again. All of it is versioned, tested and running in production somewhere.

Developer tools

Developer tools

The CLIs, generators and local tooling our engineers reach for on day one, so a new project starts building instead of configuring.

  • Project scaffolding
  • Migration and seed runners
  • Local environment setup
Extensions

Extensions

Plugins that bolt onto the systems you already run — accounting packages, POS terminals, ERPs — instead of asking you to replace them.

  • Accounting and ERP connectors
  • POS and terminal integrations
  • Webhook and event bridges
Progressive APIs

Progressive APIs

Versioned HTTP and event interfaces that keep working when the client on the other end has not upgraded in two years.

  • Versioned, documented endpoints
  • Backwards-compatible changes
  • Offline and retry semantics
What we maintain

The packages themselves.

Where a package is open source, you can build on it too. Where it is internal, it still ships inside the work we do for you.

Example UI kit

Internal

The component library behind our client dashboards — forms, tables and data display, themed per project.

React · TypeScript

Example payments adapter

Internal

One interface over the mobile-money and card providers we integrate with most, so a switch is a config change.

TypeScript

Example offline sync

Open source

Queue-and-reconcile storage for apps that have to keep working when the connection does not.

TypeScript

Example reporting core

Internal

Aggregation and export primitives shared by the dashboards we build — scheduled reports, CSV and PDF out.

Python

Need something built on top of this?

Tell us what you are trying to ship. If we already have the pieces, we will say so and it will cost you less.