02.1
SaaS development
Data model, application, billing, onboarding and admin — a first version deliberately narrow enough to be genuinely operable.
Read moreProducts with the
unglamorous parts finished.
Schema design through subscription handling, roles, onboarding and the admin surfaces that keep a product operable a year after launch.
Most products are demonstrable long before they are operable. The first version comes together quickly; what takes the time is the failed payment, the tenant who needs a role that does not exist yet, the migration that has to run against live data without downtime, and the support question nobody can answer because there is no admin view.
That second half is the part we have shipped twice in our own products, which run in production with real payment processing and real GDPR obligations. Operating a product is a harder test than delivering one, because the problems arrive after the invoice.
Specification comes first. Scope, architecture and acceptance criteria are agreed in writing before anything is built, and it is considerably cheaper to argue about a document than about a build.
Included
- Database schema and migrations
- Authentication and role-based access
- Stripe billing and subscription lifecycle
- Admin and support surfaces
- Multi-tenant isolation
Not included
- Ongoing support retainer unless contracted separately
- Third-party licence fees
02.2
Multi-tenant platforms
Tenant separation enforced at the data layer rather than trusted to application code, with per-tenant configuration and an access model that holds when one customer becomes twelve.
Read more
02.3
Billing & subscriptions
Stripe wired for trials, upgrades, proration, cancellation, dunning and failed payments. The happy path is an afternoon; the rest is why this is its own line of work.
Read more
02.4
Internal tools & admin
Admin views, support tooling, impersonation with an audit trail, and the operational reporting that answers questions without a database console.
Read more
Proof
Kitchen Stocker
Multi-tenant inventory and cost control for restaurants, built and operated by us.
Read the case studyFrequently asked questions
Do we own the code?
Yes. You own the repository and the intellectual property outright on completion. We do not retain a licence, and nothing is built on a proprietary layer that would make leaving us difficult.
Can you take over a product someone else started?
Sometimes. It starts with reading the code and being honest about what we find. Inheriting a codebase is occasionally cheaper than restarting and occasionally far more expensive, and we would rather tell you which at the specification stage than discover it together at month three.
How do you handle maintenance after launch?
Either your team takes it, with documentation and handover built into the project, or we continue operating it under a separate agreement. Both are legitimate; what we avoid is the third option where nobody is clearly responsible.
How long does a first version take?
It depends entirely on scope, and any studio quoting a duration before seeing the requirements is guessing. You get a written specification with scope, architecture and acceptance criteria first — the timeline comes from that document, not from the first conversation.
Other services
01
Web design & development
Marketing sites, landing pages and web applications — built static or server-rendered depending on what the content actually needs.
03
AI automation & integration
Conversational agents on the channels your customers already use, document extraction, and automation between systems that were never designed to talk to each other.
04
Search & AI visibility
Ranking in a results page and being cited in an AI answer are now two different jobs with two different requirements. Most sites are built for neither.
05
UGC & creator content
Short-form video made by real creators, generated with AI where that is honest, and edited into the variants a paid social account actually needs.