Service
MVP and Product Development
A first version narrow enough to ship and real enough to sell, built on a foundation that will carry the second version rather than needing to be thrown away.
The problem
What usually goes wrong
A first version fails in one of two directions. It is a prototype with no auth, no payments and no data integrity, so the first real customer breaks it. Or it is a full platform built before anyone has paid for anything.
The judgement is about which parts must be real on day one. Billing is real. Permissions are real. The admin screen can be a database client for a while.
We build the parts that carry risk properly and keep everything else deliberately thin.
Scope
What we deliver
Scope definition
The one workflow the product must do well, written down, with everything else explicitly out.
Data model built for version two
The schema is the expensive thing to change later, so it is designed for where the product is going even when the interface is not.
Accounts, roles and tenancy
Multi tenant boundaries enforced at the data layer from the first line, because retrofitting isolation is a rewrite.
Billing
Subscription or usage billing through a processor, with the webhook handling and state machine that keeps entitlement correct.
The core workflow
Built properly end to end, including the empty, error and edge states, because this is what people judge.
Instrumentation
Events on the actions that indicate whether the product works, so the next decision is informed.
Method
Technical approach
Scope is cut by workflow rather than by feature completeness. One journey done fully beats five journeys half done, because a half journey cannot be sold or measured.
Tenancy and permissions go in first. Every table that holds customer data carries a tenant key, every query is scoped, and the isolation is tested. This is the one shortcut that is never worth taking.
Billing is wired to entitlement through a state machine driven by processor webhooks, with idempotent handling, so a failed payment, an upgrade mid cycle or a duplicate event leaves the account in the correct state.
Operational tooling stays deliberately cheap early. An internal list and a few actions beat an admin product nobody outside the company will use.
Instrumentation is designed with the questions in mind. Activation, the step where people stop, and repeat use. Without those three, the next round of work is guesswork.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Written scope with the exclusions stated
- 02Schema designed for the intended second version
- 03Accounts, roles and enforced tenant isolation
- 04Subscription or usage billing with webhook driven entitlement
- 05The core workflow built end to end
- 06Minimal internal operations tooling
- 07Product analytics on the decision relevant events
- 08Source code, IP assignment, deployment guide and documentation
Related
Systems this service builds
- Multi Tenant and White Label SaaSSoftware one codebase serves to many customers, each with isolated data, its own branding and domain, and billing that matches what it uses.
- Membership and Recurring BillingPlans, entitlements, renewals, dunning and cancellation handled by a state machine driven from processor events, so access always matches what has been paid.
- Marketplace PlatformsTwo sided platforms with supplier onboarding, listings, search, split payments and payouts, built so the money path and the trust model are right from the start.
FAQ
Questions people actually ask
What should be in a first version?
The one workflow that makes someone pay, plus the things that are expensive to retrofit: tenant isolation, permissions, billing and a schema that matches where the product is going.
Can we start without billing?
You can, but it is usually a false saving. Entitlement logic touches most of the application, and adding it later means revisiting every screen that has a limit.
Will the first version need rewriting?
Parts of the interface will change, which is normal and cheap. The schema, the tenancy model and the billing state machine are built so they do not have to be replaced.
How do you handle the features we cut?
They are written down as out of scope with the reason. That list becomes the input to the next round rather than being forgotten or reargued.
Do you help with the launch itself?
We deliver the product, the deployment and the instrumentation. Marketing pages and the content around a launch can be part of the same engagement.
Who owns the product?
You do, completely: the source code, the intellectual property, the documentation and the accounts.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.