You have a product idea, a rough feature list and two quotes that are far apart. Before you compare them, write down the one thing a first paying customer must be able to do, and price that. Everything else is a later release.
This page is the budgeting hub for the cost articles on this site. It explains what moves the price of a web app or SaaS product, which pricing model fits which stage, and why quotes for "the same app" can differ so much. I deliberately don't print dollar ranges for whole projects. Any range I could quote would be my opinion presented as data, and I have no public dataset I can cite for it. What I can give you are verified fee schedules, documented timelines and a method for getting a number you can trust. When you want to plug your own feature list into a calculator, use the app cost estimator.
How much does it cost to build a SaaS product?
A SaaS product costs the sum of its scope, who builds it and what it costs to run, so the same feature list can be priced very differently by two teams. The fastest way to a real number is a written scope with a fixed price.
How much does it cost to build a web app compared with a SaaS?
A web app with accounts, a database and a handful of screens is mostly front-end and CRUD work. A SaaS product adds three subsystems that a one-off app never needs, and those subsystems are where the price steps up, not the screens.
| Cost driver | Web app | SaaS product |
|---|---|---|
| Payments | Often one-off checkout or none | Recurring subscriptions, trials, plan changes, failed-payment handling |
| Data separation | One audience | Every customer's data must stay invisible to the others |
| Operations | Basic admin | Admin tooling, audit trails, support workflows, background jobs |
Think of billing first. Charging once is simple. Charging every month means your database has to mirror the true subscription state through webhooks, including the awkward cases such as a card that fails on day 28. The SaaS billing and payments guide covers what that work involves.
Multi-tenancy is the second driver. On Callidus, a clinic SaaS I built on React and Firebase, everything lives under tenants/{tenantId}/… in Firestore, JWT claims carry the tenant and role, and mutations are gated in the Firestore rules. That structure was designed in from the start rather than retrofitted, My view: designing it in early is cheaper than retrofitting it. The multi-tenant SaaS architecture guide explains the patterns.
Operations is the third. A product that holds customer data needs support tooling and a credible answer to security questions, which the SaaS security and compliance guide and the backend infrastructure guide cover.
What do my own builds say about scope and timeline?
My case studies give documented timelines, not price tags. Callidus shipped as a solo build in roughly 10 weeks between February and late April 2026. BookBed, a property-management product on Flutter, Firebase and Stripe that targets iOS, Android, Web, macOS, Linux and Windows from one codebase, has been in solo development since October 2025. Pizzeria Bestek is a React and Supabase ordering site in four languages, agreed as a fixed-price custom build with full asset handover. Those are three different scopes, which is why they're three different conversations about budget.
For my own engagements, the public pricing notes list these timelines: a SaaS MVP takes 6 to 12 weeks, a custom web app or Webflow site 2 to 6 weeks, and a Flutter or FlutterFlow mobile app 4 to 10 weeks. Prices are quoted per project after a scoping conversation.
How do you write a scope that can actually be priced?
A scope is priceable when someone outside your head can read it and list the work. Use this sequence before you ask anyone for a quote:
- Write one sentence naming what a first paying customer must be able to do.
- List the user roles and what each can see or change.
- List the integrations: payments, email, calendars, maps, sign-in providers.
- State whether customers share the application and need their data kept apart.
- Name the platforms: web only, or iOS and Android as well.
- Mark every feature that isn't needed for step 1 as "later".
- Ask for a line-by-line estimate and compare it against this list.
The "later" column is where most of the savings come from. Every item you defer keeps money in your pocket and keeps a decision open until real usage informs it.
Which software pricing model fits your project?
Fixed scope fits a clear feature list, hourly fits exploration and a retainer fits a product that is already live. Choose by how certain you are about scope, because the model decides who carries the risk of change.
| Model | Best when | Who carries scope risk | Watch out for |
|---|---|---|---|
| Fixed scope | The feature list is defined | Developer, so the quote includes a buffer | Mid-build changes get renegotiated |
| Hourly (time and materials) | Scope is exploratory and will evolve | You | Needs visible progress and trust |
| Retainer | The product is live and keeps changing | Shared, through a monthly capacity | Only pays off with steady work |
My own engagements are project-based rather than hourly. A retainer is a monthly arrangement with a one-month minimum and rolling months after that. For most founders the sequence is a fixed-scope MVP, then a retainer once it ships. The SaaS MVP development guide shows how to cut scope tightly enough for a fixed price to be possible, and the line-by-line MVP cost breakdown lists the budget lines you should expect to see in a quote.
What do my listed engagements include?
My public pricing notes describe each engagement type by scope rather than by price, which is why I can share them here. They list the following:
| Engagement | Scope listed | Timeline listed |
|---|---|---|
| SaaS MVP build | Auth, multi-tenancy, Stripe payments, one core feature, basic admin; architecture decisions, code, deployment and handoff documentation | 6 to 12 weeks |
| Web app or custom website | Custom React or Next.js app or Webflow CMS site; design-to-code, SEO foundation, deployment | 2 to 6 weeks |
| Mobile app | Flutter or FlutterFlow app for iOS and Android; Firebase or Supabase backend, App Store submission | 4 to 10 weeks |
| Maintenance retainer | Post-launch support, feature additions and performance monitoring | Monthly, one-month minimum |
The same notes say I don't take on enterprise SOC 2 vendor paperwork requirements, lowest-bid projects, or pure design implementation without product input. Knowing what a provider declines is as useful as knowing what they offer, so ask every bidder for the same list.
Why do quotes for the same app differ so much?
Quotes differ because the cost structure behind them differs: local rates, how many people bill time to your project, and how much of the work is automated. Quality is the least reliable explanation for a gap.
Consider a hypothetical comparison, not a real client. An agency quote typically carries a project manager, a designer and two developers, plus the meetings that keep them in sync. A solo full-stack developer quotes one person's time with no handoffs. Both can use React and Stripe. The invoices still look different because the overhead is different, and neither number says anything on its own about how good the code will be.
Tooling is the third factor. The Stack Overflow 2025 Developer Survey reports that 84% of respondents are using or planning to use AI tools in their development process, up from 76% the year before. The same survey found more developers distrust the accuracy of AI output (45.7%) than trust it (32.7%). My reading of that pair of numbers: AI assistance can shorten the repetitive parts of a build, but it doesn't remove the need for someone to check the result. The AI-augmented development guide describes where I find it useful and where I don't.
Regional rates also matter. Developers in the Balkans work with the same stack as everyone else, so React, Flutter, Firebase, Supabase and Stripe don't cost more or less in Sarajevo than in London. The difference is the local cost base. I work in the CET/CEST time zone, which overlaps with the UK and Western Europe. If you're weighing a solo developer against an agency or an offshore team, the hiring SaaS developers guide covers vetting and trade-offs.
Which running costs come after the build?
Payment fees, hosting, third-party services and maintenance all continue after launch, so budget them as recurring lines rather than a surprise. Only some of them have published prices you can check today.
- Card payments. Stripe's pricing page lists 2.9% + 30 cents per successful domestic card transaction for US accounts, plus 1.5% for international cards and 1% when currency conversion is needed. Rates differ by country, so check your own region. Stripe Billing is priced separately, at 0.7% of Billing volume on the pay-as-you-go option as of 30 September 2026.
- Hosting and database. Firebase's pricing page describes a no-cost Spark plan with Firestore quotas of 1 GiB storage, 50K reads and 20K writes per day, then a pay-as-you-go Blaze plan. Supabase pricing lists a free plan with a 500 MB database and a $25 per month Pro plan. Free tiers fit a prototype. Model your expected usage before you assume they fit a live product.
- Third-party services. Transactional email, maps, SMS and error monitoring are small recurring costs that add up.
- Maintenance. Dependency updates, bug fixes and small improvements never stop. I have no sourced percentage for it, so don't accept a rule of thumb from anyone, me included, without asking what it covers. A retainer is how most products handle it.
- Design and growth work. Without designs you need a designer. Getting users to stay is its own project, described in the SaaS UX and growth guide.
My suggestion: ask every bidder for a line-by-line list that separates the build from the first-year running costs. Then compare the lists rather than the totals.
For a web site rather than an application, the pricing logic is different. The website development cost guide covers that tier.
Send me your one-sentence "first paying customer" scope and the stack you are leaning toward, and I'll tell you which of the lines above apply and which you can defer.