The wrong question comes first
"Should we build a website or an app?" is the question we get in almost every first call. It's the wrong question. It skips a step.
The right question is: what does this product need to do, and for whom? A marketing site, a custom web app, and a Progressive Web App (PWA) solve different problems. Picking the wrong one doesn't just waste budget — it locks you into an architecture that's expensive to unwind six months in, usually right after your first round of real user feedback.
Here's the framework we use with clients before a single line of code gets written, plus honest ranges on what each option costs and how long it takes in 2026.
Three different jobs, not three tiers of the same job
Teams treat these as a ladder — marketing site at the bottom, PWA at the top, app in the middle. That's not accurate. They're not more or less sophisticated versions of each other. They answer different questions.
Marketing site. Job: convert a visitor into a lead or a sale. Content-driven, mostly public, no user accounts (or a thin one bolted on for gated content). Success is measured in conversion rate, load speed, and search ranking. Built on a CMS or a static-site framework, rarely custom backend logic beyond forms and analytics.
Custom web app. Job: let an authenticated user do real work — manage inventory, review claims, book appointments, run reports. This is where business logic lives: permissions, workflows, data validation, integrations with your CRM or ERP. Success is measured in task completion time and error rate, not page views.
PWA. Job: give a web app the feel of a native app — installable icon, offline access to key screens, push notifications — without the App Store review cycle or two separate codebases. It's not a fourth category so much as a delivery mode layered on top of a web app. You don't build "a PWA" instead of a web app; you build a web app and decide how much of the PWA layer (service workers, offline caching, install prompts) it's worth adding.
How to actually choose
Ask these four questions, in order:
- Does a user log in and do repeatable work, or does a visitor read and leave? Repeatable work → web app. Read and leave → marketing site.
- Does the product need to work with a spotty connection, on a phone, away from a desk? Field techs, warehouse staff, delivery drivers — yes. Office-based knowledge workers on a stable connection — usually no, and the PWA layer is overhead you don't need yet.
- Is search visibility part of how people find you? If yes, that content needs to live on a fast, crawlable marketing site — not buried behind your app's login wall, and it needs the technical basics (SEO fundamentals: server-rendered content, clean URLs, working schema) built in from the first commit, not bolted on after launch.
- Do you need both? Most B2B companies do: a marketing site to generate the lead, and a web app behind login where the paying customer actually lives. That's two builds, not one — and treating them as one project is a common reason web projects blow past their original budget.
If you're building the second kind — the app your customers actually use — that's where our web development team spends most of its time, because that's where the cost and risk actually concentrate.
What actually drives cost
Cost is not primarily about page count or "how many features." It's about four things:
Data model complexity. A CRUD app with a handful of simple entity types is a different build than one with role-based permissions across many entity types with audit trails. Every added relationship multiplies the testing surface, not just the schema.
Integrations. Each third-party system you connect to — Stripe, Salesforce, a shipping carrier's API, an internal legacy database — adds real time depending on how well-documented and how stable that system's API is. Undocumented internal systems are one of the biggest sources of timeline slippage we see, because you don't find the edge cases until you're already integrating.
Real-time and offline requirements. A dashboard that refreshes on page load is cheap. A dashboard with live updates via websockets, or a mobile view that needs to function with no connection and sync later, adds real engineering time on top of the base build for the affected screens.
Design maturity. If you're starting from a Figma file with every state (empty, loading, error, edge case) already designed, the build moves fast. If design happens in parallel with development, expect rework — screens get built against a spec that changes underneath them.
Team seniority and location affect the hourly rate, but they rarely explain the biggest swings in total project cost. The four factors above do.
Realistic timelines for 2026
These are rough ranges for a single, well-scoped build — not a portfolio of everything a large enterprise might need — based on projects we've scoped recently:
- Marketing site (a handful of pages, CMS-backed, no custom backend): a few weeks.
- Custom web app, standard complexity (auth, a few core entity types, one or two integrations): roughly a quarter.
- Custom web app, high complexity (multi-role permissions, several integrations, real-time features): a couple of quarters or more.
- Adding the PWA layer to an existing web app (offline caching for key screens, install prompt, push): a few weeks, depending on how much of the app needs to work offline versus just be installable.
Anyone quoting a fixed number without asking about your data model, your integrations, and your design status is guessing.
The pattern we see most
The most common mistake isn't picking the wrong format — it's picking one format and asking it to do both jobs. A company builds a slick marketing site, then tries to bolt a customer dashboard onto the same codebase because "it's already built." Months later the dashboard is fighting the CMS for control of routing, and every content update risks breaking a logged-in feature.
The fix is almost always to split them at the start: a lightweight marketing site optimized for speed and search, and a separate web app optimized for the logged-in experience, sharing a design system but not a codebase. It costs slightly more upfront. It saves a rebuild later.
Bottom line
Don't start with "website or app." Start with what the user is doing and how much of that needs to survive a bad connection. Scope the marketing site and the logged-in product as two separate decisions, even if one team builds both. And when you're pricing a custom build, ask about the data model and integrations before you ask about the page count — that's where the real number comes from.
If you're at the point of scoping one of these builds and want a straight answer on cost and timeline for your specific case, talk to us before you write the RFP.
