A website helps someone understand your business and decide whether to contact you. A web app lets them do something: compare data, upload a document, manage a booking or work through a job. A business can need both, but they do not have to be built at the same time.
The useful starting point is the action someone needs to complete. “We need a better website” can mean the services are hard to understand, or it can mean staff spend every afternoon copying enquiries into another system. Those are different jobs.
Which kind of build fits the job?
| What someone needs to do | Start by considering | What to check before building |
|---|---|---|
| Understand your services, see your work and contact you | A business website | Can a new visitor explain what you do and find the next step on a phone? |
| Choose an appointment and receive a confirmation | A website connected to an existing booking tool | Does the tool already handle availability, calendar updates and cancellations? |
| Sign in, share documents and see outstanding requests | A client portal | Who can see each record, and what happens when access changes? |
| Compare live information or use a business-specific tool | A web app | Where does the data come from, how fresh must it be, and how are errors shown? |
| Move information between systems your team already uses | An integration | Which system owns each record, and how do you handle duplicates or failed updates? |
These can overlap. A website can include a booking tool without needing a custom booking system. A web app can sit behind a public website that explains the service. Choosing the smallest useful first release leaves room to learn from people using it.
An example from our work: Sports Projections & Forecasting Platform
The Sports Projections & Forecasting Platform needs more than pages describing a service. Its users compare sports projections and provider prices. The product brings several data sources into a common format, then presents them in a desktop comparison table and mobile cards.
That makes it a useful example of a web app: the interface is one part of the build; collecting and organising the information is another. The project page shows both views with historical product data. A business dashboard has a similar planning question: what does the user need to compare, and what information must be available to make that comparison useful?
For a business that simply needs to explain its services and accept enquiries, that kind of data pipeline would add work without solving the problem.
A brief you can use before asking for a quote
Copy these questions into a document. Short, concrete answers are more useful than a long list of features.
- Who is using it? Separate prospective customers, existing clients and your staff. They may need different pages and permissions.
- What is the one job they should finish? For example: book an available appointment, send the requested document, or find the current status of a job.
- What happens today? Write down the steps, including anything retyped, emailed or checked manually.
- Which tools must stay? Name the calendar, accounting software, CRM and other systems already holding the information. Check whether they support the connection you need.
- What would a useful first release leave out? Separate what is required to complete the job from later improvements.
- How will you know it works? Agree an observable test: a booking reaches the right calendar, a client sees only their own documents, or a report matches the source records. If you want to measure time saved, record the current process before replacing it.
- Who looks after it? Agree content updates, support, hosting, access, backups and ownership or licence terms before committing to the build.
Use fictional examples when sharing an early brief. You can describe the information a system needs without sending customer records in an enquiry.
What changes the cost?
For a website, the scope includes page layouts, content, imagery, forms and any existing URLs that need to be preserved. For a web app, it also includes accounts, permissions, data migration, integrations, exception handling and ongoing operation.
Ask for the build and ongoing costs separately, with assumptions written down. A fixed quote is only useful when it is clear what it includes. Our pricing page explains how we scope projects, charge for support and handle software licensing.
Do you need AI in either one?
Often you do not. Clear information, a useful interface and reliable connections may solve the whole problem. Consider AI when there is a specific task such as drafting or extracting information, with a way for someone to check the result. It is not a requirement for a modern website or a useful web app.
If you already have a site, bring it to the first conversation. We can look at what works, what gets in the way and whether the next step is a refresh, an integration or a separate tool. See our website design and web app service.