The quickest way to settle this argument is to ask one question: does each user need their own data, saved and shown back to them later? If yes, you need software. If no, you need a website, and buying software instead will cost roughly ten times more for a problem you did not have. This piece defines both properly, gives you a decision table, sets out honest US cost and timeline ranges, and covers the option most businesses overlook.
Build a website if every visitor sees the same content and your goal is a lead or a sale. Build a web app if individual users log in, keep private data between visits, and use it to complete work. Websites cost $1,500 to $50,000. Web application development starts around $35,000 and needs yearly maintenance.
Two definitions, one sentence each
A website presents information that the same visitor sees in more or less the same state, and its job is to inform or persuade. A web app is software running in the browser where each user has their own state, saved between visits, and its job is to let someone do work.
The dividing line is state, not technology or visual polish. A beautifully animated site with a booking calendar embedded from a third party is still a website. A plain, grey interface where a customer logs in, uploads a file, and sees a result that belongs only to them is a web app. Once you accept that, most of the confusing edge cases sort themselves out.
The confusion usually starts because the same team can build both, and both arrive through a browser. But web application development brings a set of costs a website never incurs: accounts, permissions, a database whose shape you have to maintain, background jobs, error handling for people who are mid-task, and a support process for when someone's data looks wrong.
Should you build a web app or is a website enough?
Work down this table and count which column you land in more often. If the left column wins by a wide margin, do not talk yourself into software.
| Question | A website is enough if | Build a web app if |
|---|---|---|
| Who sees what? | Everyone sees the same pages | Each user sees their own records, and must not see anyone else's |
| Do people log in? | No, or only your team via a CMS | Customers or staff sign in regularly to do a task |
| What happens to data? | Form submissions go to email or a CRM and the story ends | Data is stored, edited, queried, and shown back over time |
| How often do people return? | Once or twice before buying | Weekly or daily as part of their job |
| What is the main verb? | Read, compare, contact, buy | Create, track, approve, calculate, manage |
| Can an off the shelf tool do it? | Yes, and you can live with its limits | You have tried two tools and both broke on your actual process |
| What breaks if it goes down at 2am? | You lose some traffic | Customers cannot work, and someone has to be on call |
That last row is the one people skip. A website going down for three hours is embarrassing. A web app going down for three hours generates support tickets, refunds and, if you handle other people's data, an obligation to explain yourself. Uptime expectations are part of the decision, not a detail to sort out after launch.
Before commissioning any custom software, spend two weeks trying to run the process on existing tools: a form builder, a spreadsheet, an automation between them, and a scheduled report. If that gets you 70 percent of the way, keep it and spend the budget on demand generation instead. If it collapses at 30 percent because your logic is genuinely specific, you now have a written spec of exactly what broke, which is the most useful brief a development team can receive.
What each one costs and how long it takes
Ranges reflect US market pricing for competent teams, including ours. They assume design and development, not ongoing marketing.
| Build | Typical cost | Timeline | Yearly running cost |
|---|---|---|---|
| Small business website, 5 to 8 pages | $1,500 to $12,000 | 3 to 6 weeks | $300 to $1,500 (hosting, domain, small edits) |
| Larger marketing site, 20 or more pages, blog, integrations | $15,000 to $50,000 | 8 to 14 weeks | $2,000 to $8,000 |
| Ecommerce store on Shopify | $8,000 to $60,000 | 6 to 16 weeks | Platform fees plus $3,000 to $15,000 in upkeep |
| Web app, first usable version | $35,000 to $120,000 | 3 to 6 months | 15 to 25 percent of build cost, every year |
| Web app, multi role with billing and integrations | $120,000 to $400,000 | 6 to 14 months | 15 to 25 percent of build cost, every year |
Two things in that table deserve emphasis. First, the gap between a website and a web app is not incremental, it is roughly an order of magnitude at the low end. Second, the yearly figure for software is not optional. Dependencies get security patches, browsers change, payment providers deprecate APIs, and someone has to answer the email that starts "the export button stopped working". Budget 15 to 25 percent of the build cost annually or plan to rebuild in three years.
Why does maintenance differ so much?
A brochure site can sit untouched for a year and still work. The risk surface is small: a plugin update, an SSL renewal, a form that quietly stops delivering to an inbox nobody checks. Annoying, cheap to fix.
Software accumulates obligations. You are running a database whose schema changes as features arrive, which means migrations. You are storing personal data, which means retention rules, deletion requests and access control that has to survive every new feature. You have background jobs that fail silently unless someone is watching. You have users mid-task when you deploy, so releases need care. And you have a support load that grows with your user count, whether or not you planned for it.
None of this is a reason to avoid building. It is a reason to be honest in the business case. If the app saves 20 hours of admin a week at a loaded cost of $45 an hour, that is roughly $47,000 a year, which comfortably supports a $60,000 build and a $12,000 annual maintenance line. If it saves four hours a week, the numbers do not work and a well configured off the shelf tool will serve you better.
The middle ground most businesses actually need
There is a third option that gets overlooked: a marketing site with one genuinely interactive tool attached. A roofing company with an instant estimate calculator. A logistics firm with a transit time lookup. An insurance broker with a quote comparison that stores nothing but returns a number. A clinic with a real time availability check that hands off to a booking system.
These sit at $4,000 to $20,000 on top of a normal site build. They give you the lead generation benefit that people imagine they will get from an app, without accounts, without stored customer data, and usually without a compliance conversation. They also tend to be the best content on the site from a search perspective, because a calculator earns links and repeat visits in a way that a services page never will.
We build a lot of these alongside website design and development projects, and they are frequently the version of the idea a client should have started with. If the tool proves itself, the logic inside it becomes the first feature of the real app, and by then you have usage data to justify the spend.
How would we decide in a week?
- Day 1. Write the job to be done in one sentence, in the user's words, with a verb. "Track which of my 40 sites have had their inspection this quarter" is a spec. "Digital transformation" is not.
- Day 2. Count the roles. One role usually means a website or a small tool. Three or more roles with different permissions means software, and the cost jumps.
- Day 3. Ask whether data must persist between sessions and belong to individuals. If yes, you are building an app.
- Day 4. Try to break the problem on existing tools for real, not hypothetically. Note precisely where it fails.
- Day 5. Put a dollar value on the pain: hours saved, deals lost, errors corrected. Multiply by 52.
- Day 6. Compare that annual number against build cost plus three years of maintenance at 20 percent.
- Day 7. Decide, and write down the one metric that will tell you in six months whether you were right.
If we had to guess, most small and mid-sized US businesses that come to us asking for web app development should build a strong site plus one tool, and revisit the app question in a year with real numbers. The businesses that genuinely need the app usually know it already, because they are drowning in spreadsheets and can describe the workflow in painful detail.
If you decide on the app, still ship the marketing site first and separately. Launching them together means the app schedule delays your ability to generate demand, and you arrive at launch day with software and no audience. Site first, then app, then the two connected. It costs slightly more in integration work and saves months of dead time.
Where teams get this wrong
The most common mistake is buying software to solve a distribution problem. If nobody knows you exist, a customer portal will not fix that, and the budget would have done more in performance marketing or in content. The second mistake runs the other way: a business with 200 recurring clients running everything through email attachments, insisting a nicer website is the priority. Their bottleneck is operational, and no amount of hero copy will change it.
The third mistake is scope by imagination. Someone lists every feature a competitor has, and the first version arrives eleven months later with no users. Pick the single workflow that hurts most, ship that, and let real usage tell you what comes next. A first version that does one job well and reaches people in four months beats a complete platform that is still in staging.
If you are selling products rather than managing work, note that most of what people describe as needing an app is already solved by a properly built store. Subscriptions, accounts, order history and customer portals all exist in Shopify without custom software, and the cases where they genuinely do not are narrower than most vendors will admit.
Frequently asked questions
What is the difference between a website and a web app?
A website presents the same information to every visitor and exists to inform or persuade. A web app is software in a browser where each user has their own saved state and returns to do work. The test is not how modern it looks or what framework built it. It is whether individual users have private data that persists between visits.
How much does web application development cost in the US?
A first usable version generally runs $35,000 to $120,000 and takes three to six months. Multi-role apps with billing, permissions and integrations run $120,000 to $400,000 over six to fourteen months. Add 15 to 25 percent of the build cost annually for maintenance. That yearly line is not optional, since dependencies, browsers and payment APIs all change underneath you.
Can a website include interactive features without becoming a web app?
Yes, and this is the option most businesses should consider first. A calculator, a transit time lookup, a configurator or an instant estimate can sit on a normal marketing site and usually adds $4,000 to $20,000 to the build. Since nothing is stored per user, you skip accounts, permissions and most compliance work, while getting the lead generation benefit people expect from an app.
How long does it take to build a web app compared to a website?
A small business site takes three to six weeks. A larger marketing site with integrations takes eight to fourteen weeks. A web app takes three to six months for a first usable version, and six to fourteen months once you add multiple roles, billing and integrations. The extra time goes into accounts, database design, permissions and testing, not into producing more screens.
Should I build the website and the web app at the same time?
Usually not. Launch the marketing site first so demand generation starts while development runs, then ship the app, then connect them. Building both at once ties your marketing timeline to your engineering timeline, and you arrive at launch with software nobody has heard of. The extra integration work later is small compared with the months of dead time you avoid.
When is an off the shelf tool better than custom software?
When it handles about 70 percent of the process for a fraction of the price, keep the tool and spend the difference on growth. Run a real two week trial with a form builder, a spreadsheet and an automation between them. If it collapses at 30 percent because your logic is genuinely unusual, you now have a written record of exactly what failed, which is the best brief a development team can get.
The takeaway
Decide on state, not on ambition. Per-user data that persists means a web app and a multi-year commitment to maintaining it. Everything else is a website, possibly with one sharp interactive tool bolted on, which is where we would put the money for most US businesses under 50 staff. Write down the metric that proves you chose correctly, then check it in six months.