A product people log in to. Built as one thing.
Customer-facing web applications from first login to subscription billing: accounts, roles, payments, dashboards and the edge cases that come with real users — built as one product, not a stack of parts.
Most web applications are built to a spec that was wrong.
01 — The problemThe spec listed forty features. Six of them mattered. The agency built all forty, competently, and the product launched with the six buried under the thirty-four — nine months and a budget later than it needed to.
We take a view on the product before we build it. Which features come first, which wait, and which never happen. The first release is deliberately smaller than the idea that arrived, because its job is to get real users onto it — and then the next release is built from what they do.
What we build.
02 — What we build- ✦Accounts, roles and organisationsSign-up, invitations, teams, permissions. The unglamorous half of every product, done properly once.
- ✦The core workflowThe thing people log in to do. Designed and built first, with everything else sequenced behind it.
- ✦Subscription billingPlans, trials, upgrades, invoices and the awkward cases — through Stripe, with the webhooks handled.
- ✦Dashboards and reportingWhat a user needs to see to know it is working, and what you need to see to know the business is.
- ✦Admin and support toolingThe back office you will need on day two: impersonate a user, refund a charge, see what happened.
- ✦Infrastructure that scales without a rewriteNext.js, TypeScript and Postgres on serverless infrastructure — costs nothing while nobody is using it, and grows without a re-platform when they are.
How it runs.
Every project runs the same five steps, and you see working software every week from the first sprint.
- 01CallHalf an hour. You describe the business problem; we tell you what we think it takes.
- 02Scoping sprintOne to two weeks. We work out what the system is, who uses it, and which features come first.
- 03PlanScope, architecture, sequence and cost in writing before any production build starts.
- 04Build in the openOne team designs, builds and tests. Working software on a staging site every week.
- 05Launch and keep goingLive, monitored, documented, in your accounts. We stay on for what comes next.
Questions about web applications.
05 — QuestionsI have an idea but not a spec. Is that a problem?
+
No — it is the normal starting point, and it is what the scoping sprint is for. In one to two weeks we work out what the product is, who uses it and which features come first, and you receive scope, architecture, sequence and cost in writing before any production build.
How small is the first release?
+
Smaller than feels comfortable, on purpose. It has the core workflow, accounts and billing, and enough polish that real users can use it. What it does not have is the features nobody has asked for yet. The second release is built from what the first one shows you.
What stack do you use?
+
Current versions of Next.js, React and TypeScript; Postgres for data; serverless on AWS through SST, or Vercel. Deliberately conventional, so another team could maintain it — including replacing us.
Can you take over an existing application?
+
Often, yes. The scoping sprint applies just as well to something half-built: we work out what is there, what is worth keeping, and what it would take to make it a product. The plan is honest about all three.
How do you handle security and data?
+
Authentication with fine-grained roles, access enforced at the data layer, signed links for files, separate staging and production environments, and infrastructure defined as code. Nothing exotic — the conventional practices, applied every time.
Tell us what you’re trying to build.
Half an hour on a call with our team. Bring a spec, a rough idea or a system that has stopped keeping up, and you leave with our view on what it takes and what comes first.
Zeki Mirza — Founder & product lead
Your first call is with the team that scopes and builds it