Planning
Website vs web application: what does your business need?
Use customer journeys, stored data, permissions and integrations to decide between a business website, an existing tool and a custom web application.
Start with what users do. Reading and enquiring usually points toward a website; private records, permissions and repeat workflows introduce application requirements.
Describe the job instead of naming the technology
A website and a web application are not perfectly separate categories. A public service website may contain a booking form, while an application also needs public marketing pages. The practical question is which journeys need stored state, business rules and restricted access.
Write the journey in plain language. “A visitor reads about a service and sends an enquiry” is different from “a customer signs in, sees only their records, changes an appointment and receives confirmation.” The second sentence introduces identity, permissions, validation and notification rules.
Use the complexity signals
A contact form by itself does not justify a custom platform. Conversely, describing an internal dashboard as “just five screens” hides the rules behind those screens. Review the following questions before committing to a budget.
| Question | If yes, investigate |
|---|---|
| Do users have private records? | Identity, access rules and data lifecycle |
| Can different roles do different things? | Permission checks for each operation |
| Does a workflow change status? | Allowed transitions, errors and audit history |
| Do systems exchange records? | API access, retries, mapping and duplicates |
| Does a transaction affect money or inventory? | Consistency, reconciliation and recovery |
Check existing software before commissioning an app
For common bookings, newsletters or simple customer records, an existing product may cover the workflow. Test it with representative examples, including the awkward ones. Check export options, access controls, integration limits and the full operating cost.
A custom build is worth discussing when meaningful requirements remain unmet: unusual approval steps, a distinctive customer experience or multiple systems that must share reliable data. Document those gaps. “We want our own software” is not yet a reason to recreate every feature of a mature tool.
An illustrative appointment business
Suppose a small service business needs customers to find opening hours and request an appointment. A public website linked to an existing scheduling tool may be enough. The business can learn from actual enquiries before funding custom development.
Now suppose staff assign equipment, customers can reschedule under specific rules and managers need an audit trail. That is a different scope. Map who can read or change each record, what happens when two users act at once and how mistakes are corrected. This example illustrates scope growth; it is not a claim about a SliceCode client.
Plan operations alongside the first release
An application needs an owner for data, deployments and support. Agree how failures are reported, what is backed up, how recovery is checked and who can grant access. These responsibilities should not appear for the first time when a user cannot sign in.
At SliceCode, a website and a web app have separate planning ranges because their responsibilities differ. Send the user journeys and existing tools with your enquiry. We can use those to define a bounded first release and identify which decisions need discovery before quoting.