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 orchestration and checkout for businesses that settle in crypto. Customers pay by card through a licensed provider that verifies their identity; settlement arrives in the merchant's own wallet, non-custodial and without chargebacks.
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.
- Multi-tenant merchant accounts with isolation enforced by default, not by remembering
- Team invitations, roles and owner-only controls over anything sensitive
- Live and test API keys, stored hashed and shown to the merchant exactly once
- A provider integration layer, so a second payment provider is an addition rather than a rewrite
- Incoming webhooks cryptographically verified and processed idempotently, so a replay changes nothing
- Merchant onboarding with a defined lifecycle and sanctions screening that fails closed
- Step-up authentication before a settlement wallet can be changed
- Administrative actions audited, because "who changed this?" is not an optional question
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.