Loading
MVP · Multi-tenant architecture · Billing and onboarding
An MVP is not a smaller version of the product. It is the smallest thing a stranger will pay for, plus the plumbing that lets you charge them and see what they did next.
The problem
Founders usually arrive with a feature list. The feature list is rarely the problem. The problem is that a first version has to do four things at once: solve one job convincingly for one type of user, let that user sign up without a phone call, take money, and tell you what happened. Miss the last three and you have built a demo, not a product.
The second trap is building for the customer you hope to have. Enterprise single sign-on, granular role permissions, audit exports and a white-label theme are all real requirements eventually, and all of them are expensive to build before a single prospect has asked. Meanwhile the invitation flow, the empty state on day one and the reason a trial user comes back on day three go unbuilt, and those are what decide whether anyone converts.
The third is architectural and it is the one that hurts later. Multi-tenancy decided casually, with a tenant column added when the second customer arrives, produces a data isolation model nobody can explain to a security reviewer. It is much cheaper to decide the isolation strategy at the start, even if the first release has one tenant in it.
None of this argues for a bigger first build. It argues for a first build with the right shape: narrow in features, complete in the loop from signup through payment to usage data.
What is included
7 areas of work. Most engagements start with one or two and widen once the first release is in use.
Shared schema with row-level security, schema per tenant, or database per tenant, chosen from your customers' compliance expectations and your operating cost, then enforced at the data layer so a missing filter in a query cannot leak another tenant's rows.
Stripe or Razorpay integrated properly: plans, trials, proration, failed payment recovery, tax handling, and usage metering where you charge by consumption. Webhooks made idempotent, because a duplicated subscription event is a billing dispute.
The first ten minutes, treated as a designed part of the product. Sensible defaults instead of an empty dashboard, sample data a user can safely delete, a first-value moment identified before build, and invitation flows for the colleague who is actually going to use it.
An authorisation model that survives your first enterprise prospect, plus the internal admin console your support team needs: impersonation with an audit trail, plan changes, usage inspection and the ability to fix a customer's data without a database client.
Query patterns that stay flat as tenant count rises, background work moved off the request path, caching where invalidation is understood, and unit economics tracked per tenant so you know which customers cost more to serve than they pay.
The controls your first serious buyer's security questionnaire asks about: encryption in transit and at rest, access logging, backup and restore that has actually been tested, secrets management and a documented offboarding process. Groundwork for SOC 2 or ISO 27001 without pretending the certificate exists.
Events defined around questions you will act on, activation and retention visible without a data team, and feature flags so a release can be tested with a subset of accounts and turned off without a deploy.
How we work
Most founders start with a fixed-scope MVP phase, typically ten to fourteen weeks, ending with a product in front of real users and an instrumented signup flow. The scope is agreed by cutting rather than adding: we will argue for removing features from a first release more often than we argue for including them.
After launch the shape usually changes to a dedicated pod at a monthly rate, because the roadmap is now driven by what users actually do and a fixed scope for the next quarter would be fiction. You get named engineers, a shared board and a two-week cycle with a demo on a real environment.
For funded teams with their own engineers, we work as an embedded group inside your process instead, taking a defined area such as billing, the data layer or the admin tooling. In every model the accounts, the repository and the infrastructure are yours, so a change of arrangement is an administrative event rather than a migration project.
In practice
Most founders start with a fixed-scope MVP phase, typically ten to fourteen weeks, ending with a product in front of real users and an instrumented signup flow. The scope is agreed by cutting rather than adding: we will argue for removing features from a first release more often than we argue for including them.
Where it comes up
04 situations
If none of these is quite your situation, describe it in your own words — that is a better starting point than picking a service off a list.
Stack
We pick from a stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
Small enough that one type of user gets one job done end to end, and complete enough that they can sign up, pay and be measured. That usually means one primary workflow, one user role, and a deliberately plain admin side. Features that serve a customer segment you have not yet spoken to are the first things we cut, and cutting them is normally what makes the timeline credible.
For most products, a shared schema with a tenant identifier and database-enforced row-level security gives the best balance of cost and safety, because the isolation is enforced below the application rather than by every developer remembering a filter. Schema or database per tenant is worth its operational overhead when customers contractually require physical separation or when a single tenant's data volume distorts everything else. It is a decision to make at design time; retrofitting it is a migration project.
Partly, and it is worth being precise about the limits. Plans, entitlements and usage records live in your own database, and the payment provider is integrated behind a narrow interface, so switching provider is a contained piece of work rather than a rewrite. What does not move easily is stored card credentials and existing subscription schedules, which is a provider migration process with its own steps regardless of how the code is structured.
Not always at the first deal, but you need the controls those standards describe, because the security questionnaire arrives whether or not the certificate is expected. We build the technical groundwork: access control, logging, encryption, tested restores, documented offboarding. We do not claim certifications on your behalf and we do not describe controls as in place before they are.
That depends on architecture more than on traffic in the early months, and the common surprise is a managed service chosen for convenience at ten customers that dominates the bill at three hundred. We size infrastructure for the first year, keep per-tenant cost visible in the reporting, and would rather run a modest, well-understood setup than a distributed architecture the team cannot debug.
Most engagements continue as a monthly dedicated team, because a product's second quarter is driven by usage data rather than the original plan. If you would prefer to hire in-house, we support that directly: documentation, architecture walkthroughs and an overlap period while your engineers take ownership. Both are normal endings and neither is treated as a failure.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether saas & product development is even the right place to spend the budget.
What happens next
