Software products, built by people who ship them
Multi-tenant applications, subscriptions, dashboards and APIs — from first version to something real customers pay for.
A product is not a bigger website
Websites present information. Products hold state, enforce rules, take money and have to keep being true at three in the morning. The failure modes are entirely different, and so is the work: accounts and permissions, tenant isolation, billing that reconciles, background jobs, audit trails, and a support story for when something goes wrong.
Most of the cost in a product is not the screens. It is the decisions underneath them — how tenants are separated, what happens when a payment fails, who is allowed to see what, and how you will change it later without breaking existing customers. Getting those wrong is expensive to undo and invisible in a demo.
We build these deliberately: a first version narrow enough to actually launch, on foundations that will not have to be torn out when it works.
This is probably you if…
- You have a product idea and need a first version real customers can use
- You are running a manual process that should be software
- Your MVP worked and now needs proper foundations under it
- You need multi-tenancy, subscriptions or an API doing serious work
- You want one senior team building it, not a rotating cast
The work, specifically
SaaS applications
Multi-tenant products with accounts, roles, plans and the isolation that keeps one customer out of another customer's data.
Subscriptions and billing
Plans, trials, upgrades, failed payments and the reconciliation that stops revenue quietly leaking.
APIs and webhooks
Documented, versioned interfaces for your customers and their integrations — treated as a product in themselves.
Dashboards and admin
The internal tooling founders always underestimate and then live inside every single day.
Auth and permissions
Sign-in, roles, invitations and audit trails, designed before they become a retrofit.
Launch surface
The marketing site, docs and onboarding that decide whether anyone gets as far as your product.
How a product build runs
Shape it
What the first version must do, and just as importantly what it must not. Scope discipline is the whole game.
Build the spine
Tenancy, auth, billing and data model first, because everything else is cheap to change and these are not.
Ship narrow
A real, working product in front of real users early — rather than a broad one that is never quite ready.
Iterate
Usage tells you what to build next far more reliably than a roadmap written before launch did.
What this usually involves
Products we built ourselves
Anyone can describe how they would build a product. These are two we actually did — which means we can show you the parts that are normally hidden.
CrexiPay
Payment requests and invoicing for service businesses. The merchant connects their own Stripe account, sends a request by email, and the customer pays by card. The money settles into the merchant’s own account — we never hold it.
A payments product is about as unforgiving as software gets. Money moves, regulators care, and a mistake is not a bug report — it is somebody’s funds. Nearly all of the engineering is in the parts a demo never shows.
- Merchants connect their existing Stripe account themselves; we never ask for, see or store card numbers or keys
- Funds settle directly to the merchant, so their payouts and their bank record agree without reconciliation
- A flat platform fee per transaction, disclosed before signup and itemised on every export
- Requests tracked from sent through to paid, carrying the merchant’s own business name rather than ours
- Refunds and chargebacks recorded against the original request, so the history matches what the bank shows
- Payment events verified on arrival and processed idempotently, with a reconciliation backstop so a dropped notification still settles correctly
- Three levels of access — owner, team member and platform administrator — with destructive actions reserved to the owner
- Fee and transaction reporting the merchant can export for their bookkeeper
ToroDocs
Document signing without the enterprise pricing: upload a document, place the fields, and send it for legally binding, ESIGN-compliant signature.
E-signature looks simple from the outside and is not. The document has to stay provably unaltered, several people may sign in a defined order, and every one of them has to manage it on a phone without instructions.
- Reusable templates with fields mapped visually onto the document
- Sequential and parallel signing, so each signer is invited at the right moment
- Bulk sending, and reminders that chase people so nobody has to
- Tamper-evident sealed PDFs, so a signed document can be shown to be unchanged
- A documented public REST API with scoped tokens and idempotency keys
- Signed webhooks that retry on failure and disable an endpoint that has stopped answering
- Usage-metered subscription billing, reconciled against the payment provider
Both are our own products rather than client work, which is why we can show you the inside of them. If you would like a walkthrough of how either is put together, ask — it is usually a more useful conversation than a sales call.
Asked and answered
Ready for a website that pulls its weight?
Tell us about your business and we will come back with a straight answer on what it needs, what it costs, and how long it takes.