SaaS and startup product development
From an MVP that answers one question to a platform with tenants, billing and an API. We build marketplaces, tracking systems, aggregators, ticketing and learning platforms — and we ship the first increment early enough to learn from it.
Who this is for
Products where the software is the business, and the first release is a question rather than a launch.
Tracking and telematics
Location, sensor and status data arriving continuously, stored so it can be queried later, and surfaced as a map, an alert and a report.
Aggregators and comparison
Many upstream sources, one normalised catalogue. The work is in the sources that are slow, wrong or offline, and in never showing a price you cannot honour.
Ticketing and events
Inventory that must not oversell, a checkout that survives an on-sale, and entry scanning that works on a field with poor signal.
Marketplaces
Two sides, one liquidity problem. Onboarding, listings, search, payments with split payouts, and the trust mechanics that make a first transaction happen.
Online education and LMS
Courses, cohorts, assessment and certification, with video delivery that holds up and progress a learner and an administrator both trust.
Language schools
Timetables, tutors, levels and attendance, with billing per course or per hour and a student app that shows the next lesson and the homework.
What we can do for a first product
Four decisions that are cheap now and expensive in a year.
An MVP that answers a question
The smallest release that tells you whether the idea holds — chosen with you at discovery, not assembled from a feature list. Anything that does not change the answer waits for the next increment.
Multi-tenancy and billing from the start
Tenant isolation, roles, plans, trials, usage metering and invoicing. Retrofitting tenancy into a single-customer product is the most common expensive rewrite in this sector, and it is entirely avoidable.
An API and integrations
A documented API, webhooks and the integrations your customers ask for in the first sales calls. In B2B software the integration list is part of the product, not part of the support burden.
Analytics you can act on
Events instrumented deliberately, funnels and cohorts you defined, and dashboards that answer the questions you are going to ask. Adding analytics after launch means the first three months have no data.
Built to be handed over
Most first products are built by someone who will not maintain them. So the deliverable is not only the running system: it is the repository, the decision records, the deployment pipeline and a build anyone competent can pick up.
- Delivery
- Weekly written update, a demo at the close of each increment
- Handover
- Repositories, CI/CD, infrastructure as code, decision records
- Scale
- Multi-tenant from the first release; usage metering and plan limits
- Typical first release
- A working MVP in 6–12 weeks
Solutions we build
The systems this sector asks for most. Each one ships as its own increment, so the first release is in use while the next is being built.
- MVPs and proof-of-concept products
- Multi-tenant SaaS platforms with plans and billing
- Marketplaces with split payments and payouts
- Aggregators, comparison engines and normalised catalogues
- Tracking and telematics platforms with time-series data
- Ticketing, inventory and entry scanning
- Learning platforms, LMS and cohort management
- Public APIs, webhooks and partner integrations
What we build here
All servicesAdvertising
Paid acquisition, campaign build, tracking
Artificial Intelligence
LLM assistants, document AI, scoring and forecasting
Custom Development
Portals, internal tools, workflow systems, integrations
Mobile Development
Mobile development service page
SEO
Technical audit, architecture, content plan, reporting
Video Production
Explainers, product films, campaign cuts, subtitles
Questions this sector asks
Small enough to reach real users within a quarter and specific enough to answer one question. We choose that question with you at discovery, and everything that does not change the answer goes into the next increment.
Yes, entirely, in your repositories from the first commit — along with the infrastructure definitions and the deployment pipeline. There is no runtime or licence of ours in the middle.
Yes, and it is common. We agree who owns which part, work in your repositories and your review process, and hand over incrementally rather than in one event at the end.
Lifetime warranty and support on what we built. Beyond that, most teams continue with a smaller increment cadence, which keeps the people who know the system available without keeping a full team on it.
Often. We start with an audit — what it does, what it costs to run, what is safe to change — and give you the findings as a document with a recommendation. Sometimes that recommendation is to keep it and build alongside; we say so when it is.
The estimator on this page gives a budget and timeline range from four questions. It is a range because the width is the honest measure of what is still unknown; after discovery it is replaced with a fixed-scope quote per increment.
What would this cost?
Four questions and you have a budget and timeline range. It is a range because the width is the honest measure of what is still unknown.
Which practice fits the work?
Pick the closest one — the estimate adjusts as you add scope.
Choose one
Which practice fits the work?
Order a free consultation
What happens next: