The data model first
Most expensive rewrites trace back to a schema that could not express what the business actually does. We would rather spend the first days on that than discover it after launch.
02 · Service
Custom products & SaaS
The hard part of a software product is rarely the screens. It is what happens when a payment fails, a subscription lapses mid-cycle, two people edit the same record, or someone asks for their data back.
What this usually includes
- Web applications with accounts, roles and permissions
- Subscriptions and one-off payments, including the unglamorous states: failed charges, retries, refunds, cancellations, proration
- Admin dashboards and internal tools
- Background jobs — scheduled work, queues, reminders, expiry
- APIs for your own product, or integration with someone else’s
- Taking an existing prototype and making it something you can safely charge for
How we approach it
Edge cases are the product
The happy path is the quick part. What distinguishes software you can charge money for is that the unhappy paths are handled deliberately rather than discovered by a customer.
Built so it can be handed over
Conventional framework, conventional structure, no clever indirection that only makes sense to the person who wrote it. You should be able to hire for this stack.
What you end up with
- The running application and its infrastructure
- Source code in a repository you own
- Schema and migrations — the database is yours and portable
- Documentation of the parts that are not obvious from the code
What this isn’t
- A fixed price before anyone has defined the scope — scope a phase with us and we will happily quote a fixed price for it
- Native iOS or Android apps
Is this the thing you need building?
Describe the problem in a couple of sentences. You’ll get a straight answer about whether we’re the right people — including when we’re not.
[email protected]