# Custom web application

A custom web application is software built for one business that people sign in to and use in a browser, such as a dashboard, a customer portal, an internal tool, or a SaaS product. Its job is to let users do work with their own data.

Also called: Web app, Custom web app, Custom software, Browser-based application.

## In short

- A website is mostly read. A web application is used: people sign in, enter data, and get work done.
- Most apps share the same parts, including accounts, a database, roles, the core workflows, and integrations.
- Buy when an existing product does the job. Build when the workflow is how you win, or when the software is what you sell.
- Cost follows **user roles, workflows, and integrations**, not the number of screens.

## What a web application is

Think of a booking system for a chain of clinics, a portal where an accountant's clients upload documents, a dashboard that shows a logistics team where every shipment is, or a product sold by monthly subscription. Each one has accounts, stores data, and changes what it shows based on who is signed in. That is a web application.

It runs in the browser, so there is nothing to install and every user gets the latest version as soon as it ships. One build works on laptops, tablets, and phones, which is why most new products start here before adding a [custom mobile app](https://www.choie.co/glossary/custom-mobile-app).

## How it differs from a website

**Diagram: Website and web application.**

**Website**
- Mostly read by visitors
- The same pages for everyone
- Content edited in a CMS
- Success is visits and inquiries

**Web application**
- Used by signed-in people
- Each user sees their own data
- Rules and records in a database
- Success is tasks completed

_The line blurs at the edges. The simplest test is whether people mainly read it or use it._

The difference matters because the work is different. A [custom website](https://www.choie.co/glossary/custom-website) is mostly design, content, and front-end code. An application adds a back end: a database, business rules, permissions, and the security work that comes with storing other people's data. Many companies run both, with the marketing site on the main domain and the app on a subdomain.

## The parts most web apps share

| Part | What it does | What to settle early |
| --- | --- | --- |
| Accounts and sign-in | Lets people create an account and come back | Which sign-in methods, and whether companies need single sign-on |
| Roles and permissions | Controls who can see and change what | How many user types there are and what each may do |
| Data model and database | Stores the records the app is about | What the core records are and how they relate |
| Core workflows | The jobs users come to do | Which one or two matter most at launch |
| Integrations | Connects to payments, email, CRMs, and other tools | Which system holds the true version of each record |
| Admin tools | Lets your team support users and fix data | Which support tasks happen every week |

Behind these sit the parts users never see, such as hosting, backups, error monitoring, and logs. They are cheap to set up at the start and expensive to add after something has gone wrong. In a Choie build, the first two weeks settle flows, what to build first, and what to cut, which is where the core workflows row gets its answer.

## When to build and when to buy

Start by assuming you should buy. Plenty of good software already exists, and every line of custom code is something you will maintain.

- **Buy** when an existing product covers the job and your process can bend to fit it. Accounting, email, scheduling, and CRMs are rarely worth building.
- **Build** when the workflow is how you compete, when your team is gluing five tools together with spreadsheets, or when the software is the product you sell.
- **Test with no-code first** when you are not yet sure anyone wants the workflow. [No-code vs custom code](https://www.choie.co/glossary/no-code-vs-custom-code) covers where that approach runs out.

A common middle path is to buy the commodity parts, such as payments, sign-in, and email delivery, as services and build only the workflow on top. That keeps the custom code small and focused on what is specific to your business.

## What drives the cost

Screens are a poor way to estimate an app. Two screens can hide a week of logic, and ten screens can be simple forms. These are the things that move the price.

- **User roles.** Each new type of user adds permissions, screens, and tests.
- **Workflows.** Every path from start to finish needs design, build, and the empty, loading, and error states that real use hits.
- **Integrations.** Each outside system brings its own API, its own failures, and its own edge cases.
- **Data and compliance.** Health, financial, or children's data adds security and legal requirements.
- **Platforms.** A web app plus native apps means several front ends on one back end.

The usual way to keep a first version affordable is to scope it as an [MVP](https://www.choie.co/glossary/mvp), with one primary user and one critical workflow, written down as a [scope of work](https://www.choie.co/glossary/scope-of-work) with a fixed total.

At Choie, a full build of a [web application](https://www.choie.co/services/web-app-development) starts at $19,000 and takes four to six weeks, with a live link to use every Friday. A one-week coded prototype of the riskiest workflow can come first, and its full fee is credited against a build that starts within 60 days. See [pricing](https://www.choie.co/pricing) and [how a project runs](https://www.choie.co/process).

## Common questions

### What is the difference between a web app and a website?

A website is mainly read, and a web app is mainly used. If people sign in to create, change, or manage their own data, it is a web application.

### Can a web application work on phones?

Yes. A well-built web app works in any modern mobile browser and can be added to the home screen. A native app becomes worth it when the job depends on deeper device features or when users expect to find you in the app stores.

### How long does it take to build a custom web application?

A focused first version with one primary user and one core workflow can be built in four to six weeks. Apps with several user roles, many integrations, or strict compliance needs take longer.

### Who owns the code of a custom web application?

That depends on the contract, so read it before you sign. A fair arrangement is that the code and designs become yours once the fees for them are paid, and that the hosting, domain, and database accounts are in your name. Choie handles ownership per deliverable: once its fee is paid, the designs and source code written for you are yours to use, modify, and distribute.

Related: [Software as a service (SaaS)](https://www.choie.co/glossary/saas), [Backend](https://www.choie.co/glossary/backend), [Tech stack](https://www.choie.co/glossary/tech-stack), [Custom mobile app](https://www.choie.co/glossary/custom-mobile-app), [Minimum viable product (MVP)](https://www.choie.co/glossary/mvp).

HTML: https://www.choie.co/glossary/custom-web-application