A SaaS consultant who builds and runs SaaS
A SaaS consultant helps a software-as-a-service company with the technical problems that only show up in SaaS: one codebase serving many tenants, billing that has to match what customers actually use, and a system that has to keep getting bigger without going down.
I build and run SaaS products myself – Craaft today, and I led the architecture of Indiemaker – and I bring that operator’s view into your team, starting with a two-week sprint.
The four SaaS-specific problems that matter most
General software consulting covers code quality and delivery. SaaS consulting adds a set of problems that are cheap to get right early and very expensive to fix later.
1. Multi-tenancy
Every B2B SaaS has to decide how tenants are isolated. The three common models each have a cost:
- Shared tables with a tenant_id column. Cheapest to run and easiest to migrate. The risk is a missing WHERE clause leaking one customer’s data to another. Postgres row-level security, or a scoping layer every query goes through, closes most of that risk.
- Schema per tenant. Stronger isolation, but migrations now run hundreds of times and connection pooling gets harder.
- Database per tenant. Strongest isolation and easy per-customer data residency, but your operational overhead grows with every sale.
For most products, shared tables with enforced scoping is the right default, with the option to move your largest or most regulated customers to dedicated databases later. I’ve written this up in more depth in multi-tenant SaaS architecture.
2. Billing and entitlements
Billing bugs are revenue bugs. The common failure is coupling the product directly to the billing provider: code that checks the Stripe subscription status on every request, or plan names hard-coded in feature checks. Separate the two. Keep an entitlements table in your own database that says what each account can do, update it from verified webhooks, and make feature checks read from that.
Then the questions get specific: how proration works on mid-cycle upgrades, what happens to access when a card fails, how seats are counted, whether you need metered usage. If usage-based pricing is on the roadmap, see usage-based billing – it changes the data model, not just the invoice.
3. Scaling without a rewrite
Most SaaS products hit the same walls in the same order: a few slow queries on the busiest tenant, then background jobs competing with web requests, then one large customer whose data volume is ten times everyone else’s. None of these requires microservices. They need indexes and query plans, separate worker pools, per-tenant rate limits and, eventually, moving the noisiest tenants onto their own resources.
If you’re past product-market fit and growth is what’s breaking things, the scaling SaaS page goes into that stage specifically.
4. AI features with a per-tenant cost
AI features change SaaS unit economics. A customer on a flat monthly plan who runs thousands of model calls can cost more than they pay. Before shipping, I want three things in place: usage metered per tenant, a cap or fair-use limit enforced in code, and evaluation that tells you whether a prompt change made the feature better or worse. Tenant data in retrieval also needs the same isolation rules as the rest of the product – a vector index shared across tenants without filtering is a data leak waiting to happen.
SaaS consultant or SaaS development company?
If you have a clear spec and need a team to build it, a SaaS development company is the right buy. They sell capacity and project management. If you need someone to make the architecture decisions, lead your own engineers, or tell you whether the agency’s proposal is sound, that’s consulting.
The two work well together: an agency or in-house team doing the build, and me owning the technical decisions and reviewing the work. If you were planning to hire a SaaS developer and are unsure what level, I can help you work out whether the gap is senior judgement or more hands.
How it runs
A two-week sprint first: I read the code, talk to the team, ship something, and write down where the tenancy, billing and scaling risks sit. After that, a fixed number of days per week if it’s useful, or a clear plan your team runs without me. No notice period.
Questions
What does a SaaS consultant do?
A SaaS consultant advises on and often builds the technical parts specific to SaaS: tenant isolation, subscription billing, onboarding, scaling under uneven customer load, and pricing-linked features. Hands-on consultants also review code and lead the engineers doing the work.
Can you build my B2B SaaS from scratch?
I can lead the build, make the architecture calls and write a meaningful share of the code, especially early on. For a full product you’ll usually need a small team or agency alongside me. For a first version, see MVP development, where scope matters more than headcount.
Which stack do you recommend for SaaS development?
Something boring your team already knows. Rails, Django or Laravel on PostgreSQL, with Redis for queues and caching, covers most B2B SaaS comfortably. The tenancy model and billing design matter far more than the framework.
When should a SaaS company split into microservices?
Later than most think. A well-structured monolith with clear module boundaries handles most B2B SaaS well past Series B. Split a service out when it has a genuinely different scaling or deployment need, not because the codebase feels large.
Building or scaling a SaaS product?
Tell me which part is hurting – tenancy, billing, scale or AI costs. In two weeks you’ll have a fix shipped and a written view of the rest.
GMT+2 · Full EU overlap · US East mornings