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 four 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
Texttive
Business texting on a prepaid wallet. Reminders, order updates and two-way conversations from a number the business owns, with opt-outs, quiet hours and carrier registration handled rather than left to whoever is sending.
Getting a text delivered in the US is a consent and registration problem before it is a software one. Carriers reject unregistered traffic outright, and the rules about who you may message, and when, are not advisory. Most of the build is the part that stops a message going out.
- A prepaid wallet with a full ledger and card top-ups, no monthly commitment and no invoice at the end of a month nobody budgeted for
- 10DLC and toll-free numbers carried through carrier registration, rather than left as homework for the customer
- STOP and opt-out honoured before a message can be sent, not reconciled afterwards
- Quiet-hours windows enforced, so a reminder cannot go out in the middle of the night
- Carrier and line-type lookup before sending, so a landline is identified rather than billed as a failed text
- A two-way inbox, because a reply that nobody sees is worse than no reply
- A REST API with signed webhooks for delivery receipts and inbound messages
- Every account isolated from every other, with an approval step before a new account can send anything
Chattiv
Live chat for small business websites: a light chat widget and a team inbox on desktop and phone, with an optional AI assistant that answers from the business’s own content and always says it is AI.
Once software can answer a customer, every conversation needs a clear owner. Two answers confuse people, no answer loses them, and an AI that hides what it is loses their trust. Most of the build is deciding who speaks, and making sure nobody is left waiting.
- Human chat first, with the AI assistant switched off until the business chooses to use it
- One owner per conversation, enforced by the platform, so a visitor never gets two competing answers
- Handoffs from AI to a person that carry a summary, so the visitor does not have to repeat themselves
- A visible AI label on every AI message and a way to reach a person that cannot be turned off
- Honest offline handling: when nobody is available the visitor is told so and the reply follows by email
- Alerts on desktop and phone, with missed conversations turned into email follow-ups
- An open API so a business can connect its own AI, held to the same handoff rules
- AI usage metered and capped per plan, with any extra spending opt-in and limited
These 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 any of them 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.