Platform
What we buildHelp centreSecurityComplianceReliabilityScalabilityEfficiency Platform overviewSolutions
Startup foundersEstablished businessesOperations teamsIntegrations
Payments, billing & taxAccounting & ERPIdentity, access & auditEmail deliverySMS & voiceElectronic signature All integrationsHow it works
Three stages. You are genuinely only needed for the first one, and the third one never ends.
Most software processes are designed to protect the people building it: a specification so requirements can be argued about later, a change-control process so scope can be billed, a handover so responsibility can end. This one is designed around a different assumption — that you will be wrong about something early, and that the cheapest possible way to find out is to look at a working version.
In plain English. No technical brief, no specification to write.
The intake is a conversation of about an hour. You explain what the thing does, who uses it, and what has to be true for it to be worth having. You can speak it, write it, send a voice note, or forward the email thread where the problem was first described. There is no template and no vocabulary to learn — if you can explain your business to a smart person outside your industry, you have already done the hard part.
Who is allowed to see this record? What happens when two people edit it at once? What should happen when the payment fails, or the file is 400MB, or the customer changes their mind after approval? These decide whether software works in practice, and they are cheaper to answer now than to discover later.
Before anything is built you receive what we heard — the screens, the rules, the users, the edge cases — in your language rather than ours. Correcting a paragraph costs minutes. Correcting a codebase costs weeks.
Most first descriptions contain two or three things that are genuinely essential and several that feel essential. We will say which is which, and you decide. Getting to a customer sooner is almost always worth more than the fourth feature.
If something is beyond what we can run responsibly, you hear it in this conversation rather than halfway through the project.
You end up with A written description you recognise, a scope you agreed to, and an honest estimate.
A working application — or an AI agent — on the internet, with real logins and real data.
Building starts immediately, and you get a link to the real thing while it is still incomplete. This is deliberate: feedback against something you can click is the only kind worth having, and a wrong assumption caught in week one costs a conversation rather than a rebuild. The application goes up on your own domain with real accounts, real permissions and a real database from the beginning — there is no later phase where the prototype gets replaced by the production version, because there is no prototype.
Encryption, access control, audit logging, backups, monitoring. They are not a hardening phase near the end, because a hardening phase near the end is how they get cut when the deadline moves.
A short session against the live thing. What is right, what is wrong, what you had not thought of until you saw it. Changes go on the list without a change-order attached.
A second identical environment with throwaway data. It is where the risky change gets tried, and it is the reason releases are boring.
Payments, email, calendars, e-signature, your accounting system. Tested against the real service in a sandbox, not mocked and hoped for.
You end up with A live application on your domain, with accounts, data, integrations and the guarantees inherited.
Watched, updated, backed up, and ready for the day it gets busy.
This is the part that is actually being sold. Launch is a Tuesday; the years afterwards are the product. Your application is monitored from outside, errors reach a person, dependencies are patched as advisories are published, backups run daily and are restored on a schedule to prove they work. When you want it changed — and you will, because you will learn things — you say so and it changes.
External uptime checks, error tracking with enough context to reproduce, performance traces, and cost alarms. You should hear about an outage from us, not from a customer.
Every dependency is watched against published vulnerabilities. Security patches go out on a schedule, critical ones out of band.
Daily backups with point-in-time recovery, stored separately, and periodically restored into a scratch environment. An untested backup is a hypothesis.
The application is not finished at launch. New screens, new rules, new integrations — the same conversation as the first one, without a re-scoping meeting.
Not a ticket queue. Someone who remembers why the third screen works the way it does.
You end up with An application that is still working, still current, and still yours to change — in year three.
Timing
An honest sketch rather than a contract. What a project actually takes depends on what it is, and you will get a specific estimate after the first conversation.
About an hour. You describe it; we ask the questions you had not thought of.
What we heard, in your words. You correct it. This is the cheapest moment to change your mind.
A live link with the core flow working. Incomplete on purpose — the point is to be wrong early.
Accounts, permissions, data, integrations. Weekly review against working software.
Production, with monitoring, backups and the status page. Real customers can use it.
Watched, patched, backed up. Changed whenever you learn something new.
An hour for the first conversation, and roughly half an hour a week to look at what has been built. Beyond that, only decisions — and only the ones that are genuinely yours to make.
You say so. There is no change-request process and no invoice attached to changing your mind — the whole design assumes you will learn things once you can see it working.
No. If you already have a document, send it and we will use it. If you do not, describing the problem out loud is enough.
Send it. We will tell you honestly whether it is worth continuing or worth replacing, and that answer will not always be the one that makes us more money.
Today the application runs on our infrastructure and you own your data, exportable at any time. Code ownership and deployment into your own cloud are on the roadmap — see Roadmap.
Start here
A 30-minute call is enough for us to tell you whether we can build it, what it will cost to run, and when it goes live.
