Built to last past launch.
We build software for other businesses, and we are still the ones running it a year later. New products, or systems already in production.
Two ways in. The same engineers either way, and the same engineering underneath.
What we take on
Build a new product
You have a product to build and no engineering team to build it. We do the architecture, the build, the launch, and the running of it afterwards. You get working software in increments rather than one reveal at the end.
For a founder with a product and no team
Run what you already have
You have something in production that has outgrown whoever maintains it. We take it over and keep it shipping, monitored and scaling, so the people holding it together can go back to their own work.
For a business whose system nobody is maintaining well
Written once, run in production, reused. Not a product, and nothing here has an endpoint you call.
What you are not paying us to rebuild
Every product needs the same plumbing underneath it. We have written and run these already, so your money and your calendar go into the part of the product that is yours rather than into the part every product has. It is also why the people who built your system are the ones who can still fix it at eleven o’clock at night.
- Authentication and sessions
- Sign-in, sessions, password reset and role checks, wired into the user model rather than bolted on beside it.
- Payments and payouts
- Taking money in and sending it out, with the ledger, the retries and the reconciliation that stop the two disagreeing.
- Multi-tenant data access
- One database serving many customers, with the boundary between them enforced in the data layer instead of remembered by each query.
- Background jobs
- Work that runs outside the request: queues, schedules, retries, and a record of what ran and what failed.
- Notifications
- Email, SMS and in-app messages from one place, with templates, delivery state and per-person preferences.
- CI and deploys
- Environments, pipelines, releases and rollbacks, so shipping is a routine action rather than an event.
- Observability
- Logs, traces, metrics and alerts wired up on the first day, so a problem in production has an answer instead of a guess.
The honest version, in three sentences. The full terms go in the contract.
Ownership and exit
Your code
Your product code is yours. It lives in your repositories, under your accounts, and it stays yours whether we are working together or not.
Our components
The engineering above is ours. Where your build uses it, you hold a licence to use it inside your product for as long as we are working together.
Leaving
If we stop working together, you get a documented path off it. Ask for the current version of that document before you sign anything and we will send it to you.
No form, on purpose. A form would put a queue between you and the person who does the work.
Tell us what you are building
Describe the product you want built, or the system you want taken over, in your own words. We will tell you honestly whether it is work we should take, and what it would cost, before anything starts.