Bytes Brothers Technology – Blog

Tag: saas mvp

  • In-House vs Agency vs Freelancer: Who Should Build Your SaaS MVP? (2026)

    Once you decide to build a SaaS product, the next question is who actually builds it. You have three real options: hire a freelancer, work with an agency or product studio, or build an in-house team. Each one costs a different amount, takes a different amount of time, and carries a different kind of risk. This guide compares in-house vs agency vs freelancer in plain terms. It gives real cost and time ranges, so you can pick the right one for your stage.

    In-house vs agency vs freelancer: the short answer

    For most first-time founders building a SaaS MVP, an agency or product studio is the safest choice. You get a full team, a fixed scope, and someone who is accountable, without the cost and delay of hiring. A freelancer is a good fit when your budget is small and the build is simple. An in-house team makes sense later, once you are funded and the product is your core business. The rest of this guide shows the numbers and the trade-offs behind that.

    Option 1: Hire a freelancer

    A freelancer is one person, usually a developer who sometimes also handles design. This is the cheapest way to build.

    Rates vary a lot by location. In India they run roughly ₹800 to ₹2,500 an hour. Globally, expect about $20 to $60 an hour. A small MVP might land between ₹1.5 lakh and ₹6 lakh, or about $2,000 to $8,000. The build often takes 3 to 5 months. That is partly because one person does everything, and partly because most freelancers juggle several clients at once.

    What you gain:

    • Low cost.
    • Direct contact with the person doing the work.
    • Flexibility to start small.

    What you risk:

    • One person is a single point of failure. If they fall ill or take another client, your build stops.
    • Usually no designer, no tester, and no clear process.
    • Quality rests entirely on that one hire.

    So a freelancer is best for a very small first version, a technical founder who can manage the work, or a quick experiment.

    Option 2: Work with an agency or product studio

    An agency or product studio gives you a team instead of a person. That usually means a project manager, one or two developers, a designer, and someone doing testing.

    This costs more than a freelancer and less than a full in-house team. A launch-ready MVP runs about ₹2.5 lakh to ₹15 lakh with an India-based studio. At global agency rates, it is roughly $12,000 to $40,000. Plan for another 15 to 30% on top for design and infrastructure. Because the work runs in parallel across the team, a first version usually ships in 6 to 12 weeks.

    What you gain:

    • Design, development, and testing under one roof.
    • A scope and price that are usually fixed up front.
    • Someone accountable if things slip, and no full stop if one person is out.

    What you risk:

    • It costs more than a freelancer.
    • Quality still varies between studios, so you have to check track record and references.

    Overall, a studio is the right fit for most first-time SaaS founders who want to launch quickly without hiring.

    Option 3: Build an in-house team

    An in-house team means you hire your own developers and designer as employees. This gives you the most control. It is also the most expensive and the slowest to start.

    In India, a mid-level full-stack developer costs roughly ₹12 lakh to ₹25 lakh a year. You usually need at least two of them, plus a designer. Global salaries are much higher. On top of the cost, hiring good engineers takes 1 to 3 months before a single line of code gets written.

    What you gain:

    • Full control over the product and the roadmap.
    • A team that knows your product deeply and stays for the long run.

    What you risk:

    • High cost and a slow start.
    • Hiring the wrong people early is expensive to fix.

    So building in-house makes sense once you are funded and the product is the core of your business for years. It is rarely the right call for a first, unfunded MVP.

    The numbers side by side

    Here is a rough comparison for a typical first SaaS MVP, say login, billing, and a basic dashboard.

    OptionCost (India)Cost (global)Time to first versionTeamBest for
    Freelancer₹1.5L to ₹6L$2k to $8k3 to 5 months1 persontiny budget, small build
    Agency / studio₹2.5L to ₹15L$12k to $40k6 to 12 weeksfull teammost first MVPs
    In-house₹25L+ per yearmuch higher1 to 3 months to hire, then buildemployeesfunded, long-term product

    Treat these as starting ranges. Your real number depends on how complex the product is and where the team is based.

    How to choose

    The right answer depends on your budget, your timeline, and how technical you are. In general:

    • Tiny budget and a simple build: a freelancer, if you can manage the work yourself.
    • You want to launch in weeks with less risk: an agency or product studio.
    • You are funded and building for the long term: start hiring in-house.

    If you are not sure, most first-time founders are best served by a studio for the MVP. Then you hire in-house once the product has real traction.

    A common path: studio first, then in-house

    Many founders do not pick just one. They use a studio to build and launch the MVP quickly. They keep the same team for the first few months of fixes and iteration. Then they hire in-house once the product has paying users and a clear direction. This keeps early costs low and gets you to market fast. It also means you hire employees around a working product, instead of a plan on paper. If you go this route, make sure you own all the code from day one, so moving to an in-house team later is smooth.

    Common mistakes to avoid

    A few mistakes come up again and again:

    • Choosing on price alone. The cheapest quote often costs more later in rebuilds.
    • Hiring in-house too early. Salaries and hiring time can burn your runway before you even launch.
    • No fixed scope. Without a clear scope and price, freelance and hourly builds tend to grow past the estimate.
    • Skipping references. Always ask to see shipped work and talk to a past client.

    For the full list of questions to ask and warning signs to watch, see our guide on how to choose a SaaS development company.

    Working with a studio for your first MVP

    At Bytes Brothers, we build SaaS MVPs as a product studio. That means a full team, fixed-price scoping, and full code ownership handed to you. If you are weighing your options, our SaaS MVP development service explains how we work. The MVP development for startups page shows what a first build includes. For the money side, the SaaS MVP cost breakdown has the full numbers. When you are ready, talk to our team for an honest look at which option fits your stage.

    Is it cheaper to hire a freelancer or an agency for an MVP?

    A freelancer is almost always cheaper up front. One person charges less than a full team, so a small build can cost a few lakh instead of ten or more. The catch is risk. There is no designer, no tester, and no backup if the freelancer drops out, so a cheap build can cost more in fixes later.

    How much does it cost to build a SaaS MVP with an agency?

    With an India-based studio, a launch-ready MVP usually runs about ₹2.5 lakh to ₹15 lakh. At global agency rates it is roughly $12,000 to $40,000. On top of that, plan for another 15 to 30% for design and infrastructure. Ask for a fixed price after a scoping call so the number does not drift.

    Should a startup build an MVP in-house?

    Usually not for the first version. Hiring good engineers takes one to three months, and two developers can cost ₹25 lakh a year or more. That is a lot to spend before you have launched. In-house makes more sense once you are funded and the product is your core business for the long term.

    How long does it take to build a SaaS MVP?

    It depends on who builds it. A studio usually ships a first version in 6 to 12 weeks, because the team works in parallel. A single freelancer often takes 3 to 5 months. An in-house team is the slowest to start, since you have to hire before any code gets written.

    Can one freelancer build a full SaaS MVP?

    Yes, a strong freelancer can build a small MVP alone. It works best when the product is simple and you can manage the work yourself. For anything with billing, several user roles, or a tight launch date, a team is safer, because no single person becomes a bottleneck.

  • How to Choose a SaaS MVP Development Company (2026)

    Choosing who builds your SaaS MVP is one of the highest-stakes decisions a founder makes early. It is also one of the easiest to get wrong. Pick the wrong partner, and you don’t just lose money. You also lose months of runway, and you often end up rebuilding from scratch. This guide, then, covers what to look for, the questions to ask, and the red flags to avoid.

    The short answer

    To choose a SaaS MVP development company, prioritise five things:

    • a proven track record of shipped SaaS products — not just websites
    • a fixed scope and price
    • full code and IP ownership
    • direct access to the engineers building your product
    • real post-launch support

    Above all, ask to see live products and talk to a past client. Then walk away from anyone who can’t, or who answers the money and ownership questions vaguely.

    Why choosing well matters

    An MVP is a race against runway. A capable partner turns your idea into a launch-ready product in weeks, and then sets you up to grow. The wrong one, however, burns your budget on something half-finished, undocumented, or built on a stack you can’t hire for. As a result, the cost is not just the invoice. It is the rebuild, and the lost months while a competitor ships. The selection, therefore, is worth doing carefully.

    What to look for

    A real SaaS track record. In fact, web design and SaaS product engineering are different disciplines. Ask specifically for the SaaS products they have built — with authentication, billing, dashboards, multi-tenancy. Ideally, get links to live ones. Anyone can show a portfolio of pretty sites; you want proof they have shipped what you need.

    Fixed scope and fixed price. For an MVP, the scope is knowable. So a good partner will agree it and quote a fixed price after a proper scoping call. Be wary of open-ended, time-and-materials estimates for a first build. In fact, they are the classic route to a number that quietly doubles after you sign.

    Full code and IP ownership. You should walk away owning everything: source code, database schema, deployment config, and all credentials. Therefore, avoid anyone who builds on a proprietary platform you can’t take elsewhere. Above all, get ownership in the contract.

    The right stack for your product — not their only trick. A strong company picks the technology that fits your product. For example, that might be Next.js and React for a fast, SEO-friendly frontend, with Laravel or Node for the backend. It will not force your project through the one framework they happen to know. So ask why they’d choose a given stack for you.

    How they’ll work with you

    Direct access to the engineers. The best sign of an accountable partner is simple: you talk to the people building your product. You do not deal with a chain of account managers relaying messages across a timezone gap. As a result, fewer layers mean faster decisions and fewer things lost in translation.

    Visible progress every week. Insist on a live staging environment and a weekly cadence. So you can see and steer the build as it happens. “Trust us, it’s going well” for eight weeks is how projects quietly go off the rails.

    SaaS-specific expertise. Building a SaaS means getting auth, subscription billing, roles and permissions, and data modelling right. These are the things that are painful and expensive to fix later. A company that treats your product like a brochure site will therefore hurt you here. Probe how they handle these.

    Post-launch support. An MVP is the start, not the end. Ask whether they offer ongoing support and can scale with you as you find product-market fit. Or do they disappear the day they invoice?

    Real references. Ask to speak to a founder they have built for. A genuine partner will happily connect you, but reluctance is telling.

    Questions to ask before you hire

    • Can you show me SaaS products you have shipped, ideally live?
    • Who exactly will build my product, and can I talk to them?
    • Is the scope and price fixed after a scoping call?
    • Do I own all the code, schema and credentials — in writing?
    • How will I see progress each week?
    • How do you handle authentication, billing and multi-tenancy?
    • What does post-launch support cost and cover?
    • Can I speak to a past client?

    Ultimately, the quality of the answers tells you almost everything.

    Red flags to walk away from

    Be cautious if a company shows any of these signs:

    • it can’t show live SaaS products
    • it only gives vague or open-ended pricing
    • it is evasive about code ownership
    • it insists on a proprietary platform
    • it won’t tell you who is actually doing the work
    • it has no QA or testing to speak of
    • it pressures you to sign quickly

    Any one of these is a reason to slow down. Several together, however, are a reason to leave.

    Agency, freelancer, or in-house?

    Each has trade-offs. Freelancers are cheapest, but they come with single-person risk and usually no process. In-house gives the most control, but it is slow and expensive to assemble for a first build. An agency or product studio sits in the middle. It is an accountable team covering design, engineering and QA. Meanwhile, it is faster to start than hiring, and there is someone to answer to. For most founders building a first SaaS, that accountable middle option is the pragmatic choice. Above all, pick one that behaves like a partner, not a body shop.

    What it should cost

    Price should never be the only filter, but it helps to know the range. A launch-ready SaaS MVP typically runs $12,000-$40,000 at global agency rates. With an India-based team, it can start from around ₹2,50,000 (~$3,000), depending on complexity. Then add 15-30% for design, infrastructure and other extras. We break the numbers down in detail in our SaaS MVP cost guide. The cheapest quote is rarely the best value. In fact, an accountable fixed-price build usually beats a low hourly rate that drifts.

    How to run the selection

    Shortlist two or three companies that pass the track-record test. Give each the same short brief, and compare how they respond. In particular, do they ask sharp questions about your users and scope, or just quote a number? Ask each the questions above, check a reference, and confirm ownership and process in writing before you commit. It is worth the extra week. Ultimately, you are choosing a partner for the most important build your company will do.

    Working with a partner who has shipped it before

    At Bytes Brothers, we build SaaS MVPs for a living. That means real products behind us, fixed-price scoping, full code ownership, and direct access to the engineers doing the work. So, if you’re weighing who should build your product, our SaaS MVP development service explains how we work. The MVP development for startups page walks through what’s included. And if you’d like to build with a team you can actually meet, see our Chennai SaaS development page. When you’re ready, talk to our team — no obligation, just an honest conversation about your product. It is also worth reading the SaaS MVP mistakes to avoid before you start.

  • Stripe vs Razorpay vs Paddle vs DodoPayments: SaaS Billing in 2026

    Billing is the part of a SaaS MVP founders most often get wrong — not because the code is hard, but because the choice is. Pick the wrong provider and you either bolt on tax compliance you did not plan for, or discover your customers cannot pay you the way they want to. This guide compares the four options that come up most in 2026 — Stripe, Razorpay, Paddle and DodoPayments — and, more importantly, the one distinction that decides between them.

    The short answer

    The real question is not “which brand” but “gateway or merchant of record.” If you bill Indian customers in INR, Razorpay is the natural fit. If you sell globally and want to never think about sales tax again, a merchant of record — Paddle, DodoPayments or Lemon Squeezy — is worth the higher fee. If you want maximum flexibility and control and you are prepared to handle tax (with something like Stripe Tax), Stripe is the developer-first default where it is available. Most Indian SaaS teams end up using Razorpay for domestic collection and a merchant of record or Stripe for international customers.

    At a glance

    Provider Type Best for Tax / compliance Main watch-out
    Stripe Payment gateway Global, developer-first products You handle tax (Stripe Tax helps) More limited in India; RBI rules on recurring
    Razorpay Payment gateway (India) India-based businesses billing INR GST invoices; RBI e-mandates handled India-centric; lighter global reach
    Paddle Merchant of record Global SaaS that wants tax off its plate Acts as reseller; handles VAT/sales tax Higher fees; less checkout control
    DodoPayments Merchant of record Global SaaS wanting MoR simplicity Handles global tax as reseller Newer, smaller ecosystem

    The one concept that decides it: gateway vs merchant of record

    A payment gateway — Stripe or Razorpay — moves money from your customer to you. You are the seller, which means you are legally on the hook for charging and remitting the right sales tax or VAT in every jurisdiction where you have customers. That is manageable domestically and increasingly automated by tools like Stripe Tax, but it is real, ongoing responsibility.

    A merchant of record (MoR) — Paddle, DodoPayments, Lemon Squeezy — becomes the legal seller of your product. Your customer buys from them; they pay you out. In return they handle VAT, sales tax and the compliance paperwork across countries. You pay a higher effective fee, but for a small team selling worldwide, that can be cheaper than the accountant and the risk. Getting this distinction right on day one is more valuable than any feature comparison.

    What good SaaS billing actually has to do

    Before comparing brands, know what you are buying. Billing for a SaaS is more than “take a card.” A real setup handles recurring subscriptions and plan changes, proration when someone upgrades mid-cycle, dunning (retrying failed payments and nudging customers before they churn), tax-compliant invoicing, multi-currency if you sell across borders, and clean webhooks so your app always knows the truth about every payment. Weigh each provider against that list, not against its landing page — the gaps are what cost you later.

    Stripe — the developer-first global default

    Stripe is the most flexible, best-documented option, with deep support for subscriptions, usage-based and metered billing, invoicing, and a huge ecosystem. If your customers are primarily in the US, Europe or other well-served markets and your team wants full control over the billing logic and checkout, Stripe is usually the right call. Stripe Tax can automate a lot of the compliance a gateway leaves to you.

    The caveats for an India-based team: Stripe operates in India but with more restrictions than elsewhere, and India’s RBI rules on recurring payments change how subscriptions behave. If your revenue is mostly domestic INR, Stripe alone is often not the smoothest path.

    Razorpay — the right default for billing in India

    For an Indian company collecting payments from Indian customers, Razorpay is hard to beat. It supports the payment methods Indians actually use — UPI, cards, netbanking, wallets — issues GST-compliant invoices, and handles the RBI e-mandate framework that governs recurring payments in India. If your MVP’s first customers are in India, start here; it removes a whole category of local-compliance friction that global-first providers do not handle natively.

    Razorpay’s global reach is lighter than Stripe’s, so if you later expand to a mostly-international customer base, you will likely pair it with Stripe or a merchant of record rather than replace it.

    Paddle — merchant of record for global SaaS

    Paddle is a mature merchant of record built specifically for software. It handles global sales tax and VAT, subscriptions, and dunning, and it is a strong fit for a small team selling to customers in many countries who does not want to become a part-time tax department. The trade-off is a higher effective fee and less control over the checkout experience than a raw gateway gives you.

    DodoPayments — a newer merchant-of-record option

    DodoPayments is a newer merchant of record aimed at exactly the same problem: let a small SaaS sell globally while someone else owns the tax compliance. It is webhook-driven and straightforward to integrate for subscriptions and one-time purchases. As a younger platform its ecosystem is smaller than Paddle’s or Stripe’s, so weigh the simplicity against maturity — but for founders who want MoR simplicity without heavy setup, it is a credible choice.

    Lemon Squeezy and the rest

    Lemon Squeezy is another merchant of record, popular with indie hackers and smaller digital-product businesses, and now part of Stripe. At small scale it is a fine choice for the same reason as Paddle — it owns the tax problem. Beyond these, you will also see Chargebee and Recurly, which are subscription-management layers you run on top of a gateway rather than replacements for one. For most MVPs, though, the decision collapses back to the gateway-versus-merchant-of-record question above.

    A quick decision guide

    • Your first customers are in India, paying in INR → Razorpay.
    • You sell globally and never want to touch sales tax → Paddle or DodoPayments (merchant of record).
    • You want maximum control, your markets are well-served, and you will manage tax → Stripe (+ Stripe Tax).
    • You are an Indian company selling worldwide → Razorpay for domestic, plus Stripe or an MoR for international.

    India specifics worth knowing

    Two things catch Indian SaaS founders out. First, RBI e-mandate rules: recurring card payments in India need a registered mandate and, above certain limits, extra authentication — which is why a local gateway that implements this natively saves you real pain. (The exact limits change, so confirm the current RBI thresholds before you design your subscription flow.) Second, GST: you need compliant tax invoices for Indian customers, which Razorpay handles and a foreign-first gateway may not. If India is your primary market, choose for these realities, not just for developer experience.

    Common billing mistakes in a SaaS MVP

    A few errors show up again and again. Trusting the client to tell your backend a payment succeeded — always confirm through a signed webhook instead. Ignoring tax until launch — decide gateway-versus-MoR before you build, because switching later is a migration. Hard-coding one provider throughout your code instead of modelling plans and entitlements in your own database. Skipping dunning — a surprising share of “churn” is just failed cards nobody retried. And getting proration wrong, so upgrades and downgrades quietly over- or under-charge. None of these are hard to do right early; all are painful to fix once real money is flowing.

    How we build billing into an MVP

    Whatever provider you pick, the architecture matters more than the brand. We create subscription state on the backend only when the provider confirms payment through a signed, idempotent webhook — never trusting the client — and we model plans and entitlements in your own database so you are not locked to one vendor. Proration, failed-payment retries and upgrade/downgrade flows get built correctly the first time, because they are genuinely painful to retrofit once you have paying customers.

    If billing is part of a larger build, our SaaS MVP development service scopes the right payment stack in discovery, and the MVP development for startups page shows how it fits the whole first release. Building in India and want to talk it through in person? See our Chennai SaaS development page, or just talk to our team.

  • Clerk vs Auth0 vs Supabase vs self-built — SaaS auth in 2026

    Choosing authentication is one of the first real engineering decisions of a SaaS MVP — and one of the easiest to overthink. This guide compares the five options founders actually weigh in 2026: Clerk, Auth0, Supabase Auth, WorkOS, and building your own. It is written from the perspective of a team that ships SaaS MVPs for a living, so the focus is on what matters when you are trying to launch in weeks, not months.

    The short answer

    For most SaaS MVPs in 2026: Clerk is the fastest way to ship polished auth, especially on Next.js. Supabase Auth is the best value if you are already on Supabase or Postgres. Auth0 fits when you need enterprise-grade identity and fine-grained authorization. WorkOS is purpose-built for B2B SSO and SCIM. Self-built auth only makes sense when you have specific control or compliance needs and the engineering time to own it securely. The rest of this article is how to tell which one is you.

    At a glance

    Option Best for Time to ship Pricing model Main watch-out
    Clerk Fast, modern B2C/B2B MVPs on Next.js/React Hours Free tier, then per monthly active user Cost scales with users; React-first
    Auth0 Enterprise identity, complex authorization Days Free tier, then per active user / feature tiers Can get expensive; more to configure
    Supabase Auth Teams already on Supabase / Postgres Hours Bundled with Supabase plan Lighter enterprise provisioning; you own more UI
    WorkOS B2B products that need SSO/SCIM early Days Free core, priced per enterprise connection Overkill for pure B2C MVPs
    Self-built Strict control, data-residency, unusual flows Weeks Your engineering time Security + maintenance is on you, forever

    What to actually evaluate

    Only a handful of factors decide this well:

    • Time to first login. For an MVP, shipping in hours instead of days is a real advantage.
    • Who owns the user table. A hosted provider stores identities for you; a self-built or database-native approach keeps them in your own schema. This drives how easy migration and custom logic are later.
    • B2B vs B2C. Selling to businesses means organizations, roles, SSO and SCIM. Selling to consumers means social logins and smooth onboarding.
    • Pricing shape, not just price. Per-monthly-active-user pricing is cheap early and can bite at scale; bundled pricing is predictable. Model your 12-month user curve before deciding.
    • Compliance and data residency. If you must keep user data in a specific region or meet strict standards, that narrows the field fast.

    Clerk — when it is the right call

    Clerk is the default recommendation for a lot of modern MVPs because it removes the most annoying weeks of auth work. You get drop-in sign-in and sign-up components, a hosted user profile, organizations and roles, multi-factor auth, and social logins — with first-class Next.js support. If your product is on the React/Next.js stack and you want production-grade auth and user management without building UI, Clerk gets you there fastest.

    The trade-offs: it is priced per monthly active user, so a consumer product with a huge free-user base should model costs carefully, and it is very React-centric. For a funded startup or a founder who values speed, those are usually acceptable.

    Auth0 — the enterprise-grade option

    Auth0 (now part of Okta) is the most mature, most configurable option here. It shines when identity is genuinely complex: many applications sharing one identity provider, fine-grained authorization rules, extensive compliance needs, or advanced enterprise SSO. It has the deepest feature set and the most extension points.

    That power is also its cost. There is more to configure, the learning curve is steeper, and pricing can climb quickly as you add active users and enterprise features. For a lean MVP that just needs solid login, Auth0 can be more platform than you need on day one — but it is a safe long-term home if enterprise identity is central to your roadmap.

    Supabase Auth — best value if you are already on Postgres

    If your backend is Supabase, or you are running Postgres and want auth close to your data, Supabase Auth is hard to beat on value. It bundles authentication with your database, supports email/password, magic links, OAuth providers and SAML, and stores users in your own Postgres — so row-level security and custom queries against the user table are natural.

    You will build more of the UI yourself than with Clerk, and its enterprise provisioning is lighter. But for a Postgres-native MVP that wants to own its data and keep the stack small, it is an excellent, cost-predictable choice.

    WorkOS — built for B2B from day one

    WorkOS is not a general-purpose auth box; it is the fastest path to enterprise readiness. If your near-term plan is to sell to businesses that will demand SAML/OIDC single sign-on and SCIM user provisioning, WorkOS handles exactly that, with a free core and pricing per enterprise connection. Many teams pair a lightweight auth layer for everyday login with WorkOS for the enterprise SSO connections their biggest customers require.

    For a pure consumer MVP with no enterprise buyers on the horizon, it is more than you need right now.

    Self-built auth — when it is worth it, and when it is a trap

    Rolling your own authentication — JWT sessions, password hashing, email verification, magic links, password reset, MFA — is entirely doable, and there are good reasons to do it: total control over the user schema, strict data-residency or compliance requirements, or login flows no provider supports cleanly. When we build hybrid stacks (for example a Next.js frontend with a PHP or Node backend), self-built JWT auth is sometimes the right fit precisely because it keeps identity inside the system of record.

    The trap is treating it as a weekend job. Auth is security-critical and never “done” — you own token rotation, breach response, MFA, session management, and every edge case, forever. For most founders shipping an MVP, that engineering time is better spent on the product. Build your own only when a specific requirement makes it necessary, not by default.

    A quick decision guide

    • You want to ship this week on Next.js → Clerk.
    • You are already on Supabase/Postgres and want value + data ownership → Supabase Auth.
    • Enterprise identity is core; you have complex authorization → Auth0.
    • You will sell to enterprises that require SSO/SCIM soon → WorkOS (often alongside another provider).
    • You have a hard control/compliance requirement and the engineering time → self-built.

    What about open-source options like Supertokens, Keycloak or Better Auth?

    Beyond the hosted providers there is a healthy open-source tier: Supertokens and Better Auth for developer-friendly, self-hostable auth, and Keycloak for enterprise-grade, self-managed identity. These are worth a look when you want to avoid per-user pricing and are comfortable running the service yourself. The trade-off is the same as any self-hosting decision — you save on licensing but take on deployment, upgrades and uptime. For an MVP racing to launch a hosted provider is usually still faster; open source gets attractive once you have scale, cost pressure, or a strong reason to keep identity in-house.

    How auth pricing bites at scale

    Per-monthly-active-user pricing is the quiet cost of convenience. It is close to free for a pre-revenue MVP and stays reasonable through early growth — but a consumer product with a large free tier can find auth becoming a meaningful line item well before it monetises those users. Before you commit, model your active-user curve 12 to 24 months out and price each option against it. Predictable bundled pricing (as with Supabase) or self-hosting can win at scale, even when a per-user provider is the obvious pick on day one. The goal is to avoid a forced, painful migration exactly when you are busiest.

    Switching providers later without losing users

    “Just pick one and move on” is good advice only if you pick with an exit in mind. The two things that make a future move survivable are the ability to export your users’ password hashes (so people are not forced to reset passwords) and control over your own user identifiers. Providers differ here — some allow hash export, some do not. If you own the user table, as you do with Supabase Auth or a self-built approach, most of that risk disappears. Decide early, because migrating tens of thousands of users is far harder than choosing well the first time.

    What we recommend for a SaaS MVP

    For the majority of founders we work with, the winning move is to pick a managed provider that matches your stack, ship, and revisit only if you outgrow it. That keeps auth off the critical path so you can spend your weeks on the feature that actually proves your product. If you are weighing this as part of a broader build, our SaaS MVP development service scopes the right auth approach in discovery, and our MVP development for startups page walks through how the whole first release comes together. Building in India or want an in-person conversation? See our Chennai SaaS development page.

    Whichever you choose, decide it deliberately: model your user growth, check current pricing, and confirm you can export your users if you ever need to move. Talk to our team if you want a second opinion on the right auth for your product.