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
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.
Each one exists because we got tired of writing it again. All of it is versioned, tested and running in production somewhere.
The CLIs, generators and local tooling our engineers reach for on day one, so a new project starts building instead of configuring.
Plugins that bolt onto the systems you already run — accounting packages, POS terminals, ERPs — instead of asking you to replace them.
Versioned HTTP and event interfaces that keep working when the client on the other end has not upgraded in two years.
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.
The component library behind our client dashboards — forms, tables and data display, themed per project.
React · TypeScript
One interface over the mobile-money and card providers we integrate with most, so a switch is a config change.
TypeScript
Queue-and-reconcile storage for apps that have to keep working when the connection does not.
TypeScript
Aggregation and export primitives shared by the dashboards we build — scheduled reports, CSV and PDF out.
Python
Tell us what you are trying to ship. If we already have the pieces, we will say so and it will cost you less.