Choose a website when visitors mainly need to discover, compare and contact you; choose e-commerce when product selection, pricing, payment and order operations are central; choose a web application when recurring users manage data, roles and workflows. Hybrid architectures are often the strongest answer: public website plus portal, e-commerce plus configurator, or a web app supported by SEO landing pages.
Content, proof and organic visibility are central.
Catalogue, transaction and fulfilment define the product.
Roles, data and workflows become the core.
Website
Best for service companies and organisations that need visibility, proof and enquiries.
What this changes in practice
In practice, this step should connect to Primary user action and Data. Describe what users mainly need to accomplish. Define what information users create, edit or consult. This turns a preference into a testable project decision.
Bring Login into the same review. Ask whether an account creates recurring value. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
E-commerce
Adds catalogue, stock, payments, VAT, delivery and transactional communication.
What this changes in practice
In practice, this step should connect to Data and Login. Define what information users create, edit or consult. Ask whether an account creates recurring value. This turns a preference into a testable project decision.
Bring Transaction into the same review. Describe payment, quotation or ordering requirements. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
| Dimension | Question to ask | Good signal |
|---|---|---|
| Primary user action | Describe what users mainly need to accomplish. | The product type follows user behaviour. |
| Data | Define what information users create, edit or consult. | The data model stays purposeful. |
| Login | Ask whether an account creates recurring value. | Authentication has a clear reason to exist. |
| Transaction | Describe payment, quotation or ordering requirements. | Commercial rules can be standardised. |
| Workflow | Map statuses, approvals, permissions and exceptions. | Business rules are known before build. |
| Operations | Plan content, catalogue, support and roadmap ownership. | Someone owns the product after launch. |
Web application
Relevant for roles, data, statuses, approvals, dashboards and integrations.
What this changes in practice
In practice, this step should connect to Login and Transaction. Ask whether an account creates recurring value. Describe payment, quotation or ordering requirements. This turns a preference into a testable project decision.
Bring Workflow into the same review. Map statuses, approvals, permissions and exceptions. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Hybrid systems
A public site can coexist with a client portal and internal back office.
What this changes in practice
In practice, this step should connect to Transaction and Workflow. Describe payment, quotation or ordering requirements. Map statuses, approvals, permissions and exceptions. This turns a preference into a testable project decision.
Bring Operations into the same review. Plan content, catalogue, support and roadmap ownership. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Decision matrix
Does the user pay, sign in, see personal data or complete a workflow? More yes answers mean more application logic.
What this changes in practice
In practice, this step should connect to Workflow and Operations. Map statuses, approvals, permissions and exceptions. Plan content, catalogue, support and roadmap ownership. This turns a preference into a testable project decision.
Bring Primary user action into the same review. Describe what users mainly need to accomplish. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Business portal, HR application and Licence Hub.
Recurring users, permissions, structured data and business processes make these products application-led rather than simple websites.
See web application cases ↗Questions to settle before you start
Make the main unknowns visible before committing budget. An unanswered question is not a problem when it is explicit; it becomes a risk when it is hidden inside a supplier assumption and discovered during development.
Answer these questions with the people who will use, sell or operate the solution. Discovery then becomes an internal decision tool, not just a document sent to a supplier.
- How is primary user action handled today, and what should measurably improve after the change?
- How is data handled today, and what should measurably improve after the change?
- How is login handled today, and what should measurably improve after the change?
- How is transaction handled today, and what should measurably improve after the change?
- How is workflow handled today, and what should measurably improve after the change?
- How is operations handled today, and what should measurably improve after the change?
Common failure patterns and warning signs
The failure patterns below all push important decisions towards the end of the project, where change is more expensive. A strong process makes these risks visible early.
Use the warning signs as review criteria. If several appear at once, reduce scope, add discovery or validate a prototype before investing further.
- Leaving primary user action until the solution has already been built
- Leaving data until the solution has already been built
- Leaving login until the solution has already been built
- Leaving transaction until the solution has already been built
- Leaving workflow until the solution has already been built
- Leaving operations until the solution has already been built
Recommended action plan
A good decision should be measurable after launch. Establish a baseline, an owner and a review cadence, then compare the same indicators after launch.
A useful roadmap separates launch from evolution. Prioritise later work from usage data, leads, support tickets and operational gains instead of an old pre-project wish list.
- 1. Discovery — Goals, users and the current process.
- 2. Scope — Must-haves, assumptions and risks.
- 3. Prototype — Critical journey and key decisions.
- 4. Build — Content, data, technology and integrations.
- 5. Launch — Testing, analytics and ownership.
- 6. Improve — Usage, feedback and KPIs drive the roadmap.
Build the business case before comparing proposals
A project involving Website, e-commerce or web application: which one should you build? is easier to govern when it is framed as an investment rather than a feature list. Start with one measurable outcome: more qualified enquiries, less manual re-entry, a shorter sales cycle, greater user self-service or lower operational risk. Use that outcome to judge every scope decision that follows.
The first layer of the business case connects Primary user action with Data. Describe what users mainly need to accomplish. Define what information users create, edit or consult. Quantify the current state where possible: enquiries per month, minutes per task, drop-off, licence cost, error volume or average cycle time. A reasonable baseline is more useful than a vague objective such as ‘modernisation’.
The second layer includes costs that appear after launch. Workflow and Operations therefore belong in the same decision as design and development. Map statuses, approvals, permissions and exceptions. Plan content, catalogue, support and roadmap ownership. A cheaper initial proposal can become more expensive if it leaves heavy manual work, unexpected licences or an architecture that is difficult to evolve.
Finally, assign value to risk reduction. Login and Transaction often affect total cost more than expected. Ask whether an account creates recurring value. Describe payment, quotation or ordering requirements. The right question is not only ‘how much does it cost?’, but ‘what level of investment is proportionate to the outcome, the risk and the expected useful life?’.
Three scope scenarios to make the decision concrete
These scenarios are not price packages. They separate the essential need from medium-term ambition. A good proposal makes the layers visible so functions can be postponed without breaking the logic of the product.
Compare proposals without comparing apples and oranges
Two proposals with the same headline deliverable can cover very different realities. Ask suppliers to respond to the same scope, assumptions and definition of ‘done’. Price then becomes a consequence of visible choices instead of a number that is impossible to interpret.
Make responsibilities explicit as well: who provides content, who approves, who configures access, who migrates data, who tests, who hosts and who responds after launch? Grey areas are often the first source of budget and timeline overruns.
| Criterion | What to review | Evidence to expect |
|---|---|---|
| Primary user action | Describe what users mainly need to accomplish. | The product type follows user behaviour. |
| Data | Define what information users create, edit or consult. | The data model stays purposeful. |
| Login | Ask whether an account creates recurring value. | Authentication has a clear reason to exist. |
| Transaction | Describe payment, quotation or ordering requirements. | Commercial rules can be standardised. |
| Workflow | Map statuses, approvals, permissions and exceptions. | Business rules are known before build. |
| Operations | Plan content, catalogue, support and roadmap ownership. | Someone owns the product after launch. |
Measure value after launch
Measurement starts before launch. Choose two to four KPIs that come directly from the business case, record the current baseline and assign someone to review them after 30, 60 and 90 days. For Primary user action and Data, favour indicators that show changed behaviour or business outcomes rather than traffic alone.
Add quality indicators around Login and Transaction. A product can convert more while creating more errors or support demand; an automation can save time without improving the experience. Use several dimensions of value rather than a single vanity metric.
Finally, connect Workflow and Operations to operating cost: licences, administration time, tickets, maintenance and required enhancements. After a few months you will have enough evidence to decide whether to invest further, simplify or expand the solution.
- Conversion or adoption
- Time saved
- Quality / error rate
- Cycle time
- Operating cost
- User satisfaction
Before final approval, schedule a short decision review with the business owner, a representative user and the technical owner. Ask everyone the same question: which assumption would have the greatest impact on budget, adoption or continuity if it proved wrong? Give that assumption a concrete validation step before or during the first release. This makes risk management part of delivery instead of something discussed only after a problem appears.
Which format fits best?
What does the user mainly need to do?
Are payment or orders central?
Will users return regularly to work in the tool?
WebsiteFocus on content, SEO, proof and conversion.E-commerceCatalogue, transaction and operations become central.Web applicationRoles, data, workflows and support justify an application architecture.Are you ready to move forward?
Frequently asked questions
Can I start small?+
Yes, with an extensible architecture.
Can e-commerce only request quotes?+
Yes, without immediate payment.
Does an app replace the CRM?+
Not necessarily; systems can integrate.
How large should the first release be?+
Large enough to support one valuable journey end to end, small enough to test and improve quickly.
What needs to happen after launch?+
Monitoring, support, ownership and a roadmap are part of the solution, not just the delivery project.