In 2026, a custom web app can cost anywhere from a few hundred dollars for a simple landing page to thousands for dashboards, MVPs, marketplaces, or business systems. The real cost drivers are user roles, custom workflows, data model complexity, integrations, and long-term maintenance — not only the number of pages you can see.
What actually drives the cost
When someone asks me for a price, the page count is almost never the thing that moves the number. What moves it is the logic behind the pages. A five-page brochure site and a five-screen admin dashboard look similar in a wireframe, but one is mostly content and the other is roles, permissions, validation, and state that has to be correct every time.
The honest cost drivers I weigh on every quote:
- User roles and permissions. One public user is cheap. Add vendors, admins, and staff with different access, and you have built three apps wearing one coat.
- Custom workflows. Anything with steps — approval, onboarding, checkout, dispatch — needs rules, edge cases, and a way to recover when a step fails.
- Data model complexity. A flat list of items is simple. Relationships between vehicles, vendors, orders, and reviews are where the real engineering time goes.
- Integrations. Stripe, email, maps, third-party APIs, and import pipelines each carry their own failure modes and their own testing.
- Maintenance. The build is a one-off. Hosting, updates, security patches, and the occasional fix are forever.
If you only remember one thing, remember that complexity lives in the verbs — what the app does — not the nouns you can count on a sitemap.
Price bands with real examples
I quote ranges, not fixed numbers, and every figure below is an indicative starting point. The final quote always follows a proper scope review, because the same brief can hide very different amounts of work.
- Landing or simple site: from $500. A few pages, a contact form, clean and fast. Mostly content, little logic.
- Business web app: from $1,500. Login, a dashboard, some real workflow — the kind of internal tool a small team actually runs on.
- AI integration: from $500. Adding an assistant, a document pipeline, or a content workflow to something new or existing.
- Single automation or scraper: from $300. One job done well — a data import, a scheduled task, a scraper that feeds another system.
- POS and inventory: from $4,000. Stock, sales, roles, and reporting that has to reconcile.
- Marketplace MVP: from around $15,000. Multiple user types, listings, search, payments, and an admin layer behind all of it.
These are starting points, not menu prices. A "simple" app with one awkward integration can cost more than a tidy app with three predictable ones.
Why marketplaces cost more
Marketplaces are the clearest example of cost living in the verbs. On the surface a marketplace is a list of things you can buy. Underneath, it is several systems that all have to agree with each other.
I can ground this in CarVendors, a live UK used-car marketplace I built solo across frontend, backend, data workflows, and deployment. The work was not "make a list of cars." It was vendor onboarding and dashboards, listing management, multi-field search and filtering, reviews, GDPR and cookie consent, a data import and scraper pipeline to bring vehicle listings in, and deployment automation so releases were not a manual chore.
Every one of those is a small product. Vendor onboarding alone touches roles, permissions, validation, and email. The scraper pipeline has to handle messy data that changes without warning. Search has to stay fast as listings grow. That is why a marketplace MVP starts where it does — you are not paying for more pages, you are paying for more systems that must stay in sync.
Hidden and long-term costs
The build price is the part everyone focuses on, and it is usually the part that matters least over a few years. The costs that quietly add up:
- Hosting and infrastructure. A small app on a VPS or Vercel is cheap; a busy app with a real database and background jobs is not free.
- Maintenance and security. Dependencies age, and unpatched apps become liabilities. Budget for steady upkeep, not a one-time spend.
- Change. Your business will not stand still, so the app should not either. New features and adjustments are normal, not a sign something went wrong.
- People. Someone has to operate the thing — answer support, run reports, manage content. That cost is real even when it never appears on an invoice.
I would rather a client knows about these on day one than discovers them in month six.
How to reduce cost without wrecking quality
You can spend less without ending up with something fragile. The trick is to cut scope, not corners.
- Start with an MVP. Ship the smallest version that solves the actual problem, then grow it with evidence instead of guesses.
- Reuse instead of reinventing. Stripe for payments, a proven auth flow, shadcn/ui components — battle-tested pieces are cheaper and safer than bespoke ones.
- Cut features, not foundations. Drop the nice-to-haves, never the testing, security, or a sensible data model. Those are the things that are expensive to retrofit.
- Be decisive. Indecision is one of the most expensive things in any build. Clear answers keep the work moving and the bill down.
How I quote
I do not pull a number out of the air. I work through scope, draw the data model, list the roles and workflows, and name the integrations before I price anything. That comes from 6+ years across IT operations, web development, automation, hosting, and infrastructure, where I have seen what the "small" requests actually cost to support later.
The starting figures above are honest anchors so we both begin in the same ballpark. The real quote comes after a scope review, in writing, with the assumptions spelled out. I would rather give you a number you can trust than a low one I would have to walk back.
FAQ
What makes one quote higher than another for a similar-looking app?
Usually roles, workflows, and integrations. Two apps can share a layout while one has three user types and a payment pipeline and the other is a single-user tool. The visible part rarely reflects the work underneath.
Can I start small and add features later?
Yes, and I usually recommend it. An MVP built on a sound data model is the cheapest way to learn what your users actually need before you spend on features they might not use.
Why give a range instead of a fixed price upfront?
Because the same brief can hide very different amounts of work, and a fixed price before a scope review is either padded to be safe or low enough to cause problems. A range followed by a written quote is the honest version.
Next step
If you have a build in mind and want a straight answer on scope and cost, take a look at how I approach custom web app development and tell me what you are trying to ship. I will come back with a clear scope and an indicative figure, and a written quote once we have reviewed the detail together.