inparlor.

Part ofThe complete guide to building and scaling a B2B SaaS in 2026

Read the full guide
engineering#b2b-saas#engineering#mvp

From MVP to $1M ARR: the engineering decisions that matter

The engineering decisions that compound from MVP to $1M ARR, auth, billing, observability, the boring stuff that determines whether you can scale or not.

5 min read·April 15, 2026

Inparlor

Digital agency

The journey from MVP to $1M ARR is mostly about not breaking things, not building things. Most B2B SaaS founders we talk to are over-investing in features and under-investing in the operational layer that decides whether they can scale through their first growth window.

Below are the engineering decisions that actually matter for this stage. None of them are about feature work.

1. Get auth right on day one

Auth is the most regretted shortcut in early-stage SaaS. We have seen at least four companies that built "simple" auth in the MVP phase and rebuilt it within 18 months, usually under pressure (SOC 2 audit, security review by enterprise prospect, breach scare).

The 2026 default: Clerk for SMB/mid-market; WorkOS for enterprise-first. Both are configurable enough to grow with you and cheap enough to start with.

What you get out of the box:

  • Email + social auth
  • Password reset flows
  • 2FA
  • SSO / SAML when you need it (WorkOS only at lower tiers)
  • SOC 2-compliant audit logging

The opportunity cost of building this yourself is roughly 4-8 engineering weeks pre-PMF. That's an MVP feature you could have shipped instead.

2. Billing is Stripe

Stripe Subscriptions is the right answer for B2B SaaS billing in 2026. Stripe Billing has matured enough that there's no good reason to use Chargebee, Recurly, or Maxio at this stage.

What to wire up in MVP:

  • Subscription plans (3 tiers max, anchored on value)
  • Trial → paid conversion flow
  • Self-serve plan upgrades and downgrades
  • Failed-payment retry logic (Stripe's built-in dunning is fine for now)
  • Customer portal for self-service billing changes

What to defer until $1M ARR:

  • Usage-based metering (unless your product is metered by design)
  • Multi-currency
  • Quote-to-cash sales workflows
  • Custom invoicing

3. Observability before you need it

The MVPs that compound past $1M ARR are the ones with observability installed from week 4. The MVPs that stall at $300K ARR are usually the ones flying blind on production behavior.

Minimum observability stack:

  • Sentry for error tracking, install on day one
  • Axiom or Datadog for logs + structured tracing
  • PostHog or Mixpanel for product analytics, install on the second screen you ship
  • Uptime monitoring via Better Uptime or Pingdom

Total cost at MVP scale: $50-$150/month. Total cost of debugging without it: hundreds of engineering hours.

4. Database choice you won't regret

Postgres. We covered this in Picking your B2B SaaS stack in 2026.

For early stage: Supabase or Neon. Both give you Postgres with auto-scaling, point-in-time recovery, and a connection pooler, features you'd otherwise hand-roll.

What to do at MVP:

  • Use migrations from day one (Drizzle or Prisma both work)
  • Index aggressively on lookup paths you'll use 100+ times per day
  • Set up automated daily backups (most managed providers do this; verify it)
  • Don't shard. You don't need it yet.

5. Background jobs you can ignore

Most B2B SaaS work that doesn't fit a request-response cycle (sending email, processing webhooks, generating reports) should run in background jobs. Spend three days getting this right and it disappears for the next two years.

Default: Inngest or Trigger.dev. Both are fine.

What you'll use them for:

  • Sending transactional emails (don't block on this in your API)
  • Processing webhooks from Stripe, Slack, etc.
  • Async report generation
  • Periodic cleanups, cohort emails, retention triggers

6. The deploy pipeline

Vercel is the default for Next.js apps. Preview deploys on every PR. Automatic production deploys on merge to main.

What to set up in week 2:

  • Preview deploys on every PR
  • A staging environment that mirrors prod
  • Automated tests (don't skip, even just E2E for the 3-5 critical flows)
  • Sentry source maps uploaded on every deploy

What to defer: blue-green deployments, canary releases, custom CI logic. None of it matters at MVP scale.

7. The data model decisions you'll regret

Three modeling decisions we see junior teams get wrong:

  1. Single-tenant vs multi-tenant. B2B SaaS should be multi-tenant. Adding multi-tenancy after the fact is a real rebuild. Building it from the start is 1-2 days of extra work.
  2. User vs account vs org. Model the relationship correctly: a user belongs to accounts; an account belongs to one organization (for enterprise). Single user table without these relations bites at month six.
  3. Hard-deletes vs soft-deletes. Soft-delete most things. You will want to restore deleted records at least once a quarter.

8. Email deliverability you'll thank yourself for

Set up SPF, DKIM, and DMARC for your domain on day one. Use a transactional ESP (Resend, Postmark) for transactional email, separate from your marketing ESP.

Reasons to take this seriously: bad email deliverability tanks trial-to-paid conversion. We have seen MVPs with 35% inbox-placement rates on their welcome email. That's not a marketing problem, it's an engineering problem they didn't know they had.

9. The thing you'll wish you had: a feature-flag layer

PostHog or LaunchDarkly. Install in week 2. Use it for:

  • Gating new features behind a flag during rollout
  • A/B testing UX changes
  • Killing features quickly if they break
  • Per-customer feature gating (enterprise wants X; the default plan doesn't have it)

Without this, every feature release is a bet-the-product event.

10. The customer-success layer

Not technically engineering, but the engineering decision: instrument the product so a non-technical CSM can see what customers are doing.

Minimum: PostHog or Mixpanel dashboards that show:

  • Time-to-first-value per customer
  • Active vs dormant accounts
  • Feature adoption per account
  • Plan-upgrade triggers (e.g., usage approaching limit)

CSMs that have to ask engineers for data are CSMs that don't proactively prevent churn.

What you can defer

Things you absolutely don't need before $1M ARR:

  • SOC 2 audit (start prep at $1M ARR, certify at $2M)
  • Multi-region deployment
  • GraphQL
  • Microservices (you're not Netflix)
  • Custom load balancing
  • Kubernetes (you're definitely not Netflix)
  • A custom design system at code level (use Tailwind + shadcn)

What to track to know if you're ready to scale

Three operational health signals:

  1. Error rate under 0.5% of requests
  2. P99 API latency under 600ms
  3. MTTR (mean time to recovery) for incidents under 30 minutes

If you're hitting all three at $1M ARR, the next phase is mostly about adding people, not rebuilding the stack. If you're missing two or three, the rebuild will be forced on you within 18 months. Better to invest now.


Read next:

Get the next one

One operating note a month. No drip sequences.

Subscribe for one substantive piece a month plus the occasional working playbook we don't publish elsewhere.

Monthly notes on digital growth. No fluff, unsubscribe any time.

Want to talk?

Get a proposal

Send a 1-page brief; we respond in 48 hours with scope, pricing, and the team that would actually run the engagement.