The useful website vs web application distinction is what visitors must accomplish. A website primarily publishes information; a web application lets people complete workflows against business data. Many projects combine both. For an Australian business buying development, the decision is which functions to configure and which genuinely need custom engineering.
Count user journeys before pages. A ten-page marketing site and a ten-screen customer portal can require very different permission models, integrations and support arrangements.
Brainstack sells web application development, so we have a commercial interest in this decision. Apply the same test to us as any supplier: demonstrate why an existing product cannot meet the essential workflow before recommending a custom build.
Website vs web application: choose the scope that fits
Use this matrix to select the first option to investigate. A feature such as login does not, by itself, justify custom development.
| Starting scope | Fits when | What the brief must establish | Evidence to request |
|---|---|---|---|
| Brochure website | Visitors read about services and make an enquiry | Content, page templates, forms and ownership of updates | An enquiry reaches the intended destination; navigation works on mobile |
| CMS website | Editors publish and maintain a changing content library | Content types, editorial roles, previews, migration and redirects | An editor publishes without developer assistance and without receiving unnecessary access |
| Configured online shop | A commerce platform fits the catalogue, checkout and order process | Product variants, payments, fulfilment, refunds and integrations | Representative orders, cancellations and refunds complete correctly |
| Configured SaaS product | An existing platform supports the booking, membership or operational workflow | Licence limits, configuration, permissions, exports and extension points | The supplier demonstrates the complete workflow in the proposed plan |
| Custom web application | Essential rules or integrations cannot be met adequately through configuration | Roles, records, state changes, exceptions and operating requirements | A working slice proves the difficult workflow and its failure handling |
These categories overlap. WordPress provides roles and capabilities for publishing and administration; having an editorial login does not automatically make a site a bespoke application. WordPress role documentation
Similarly, Shopify supports product sales, webpages and blogs in one platform. The buying question is how much configuration meets your needs and where custom extensions begin. Shopify online store documentation
- Publishing is the core taskEvaluate a CMS such as WordPressValidate editorial workflow
- Selling products is the core taskEvaluate a shop platform such as ShopifyValidate orders and exceptions
- An operational workflow is the core taskDemonstrate the workflow in candidate SaaS products
- Essential requirements are metScope configuration and integrationsValidate configured workflow
- A material gap remainsPrototype the custom application boundaryValidate the difficult requirement
Which requirements change the engineering effort?
Write the journey as a sequence: actor, input, decision, saved result and exception. “Customers can book” leaves too much unresolved. Specify who can change a booking, what happens after payment, and how staff resolve a failed confirmation.
For each external system, identify the source of truth and who owns its interface. Ask whether a test environment, API documentation and representative data are available. Record what happens when the connection is slow, unavailable or returns an unexpected response.
Payment integration shows why this matters. Stripe documents duplicate webhook deliveries and does not guarantee event delivery order. A successful checkout demonstration therefore does not prove reliable downstream fulfilment. Stripe webhook documentation
For a custom integration, require a repeated payment notification to produce one intended business result. Define how support staff find and recover a payment that succeeded while the internal order update failed. Where a platform manages this behaviour, verify the boundary between its responsibility and your extension.
That is a scope question before it is a technology choice. For the architecture alternatives, see our guide to APIs, event buses and integration platforms.
What must the permission model protect?
List each actor and what they may read, create, change, approve and export. Separate content editors from business users. Then specify record ownership: a customer should not access another customer’s order by changing an identifier.
OWASP recommends denying access by default and validating permissions on every request. Hiding a button is not a substitute for enforcing the rule at the trusted application boundary. OWASP authorisation guidance
Request negative tests alongside successful ones: an unauthorised user cannot retrieve the record; a revoked user cannot continue a protected action. Apply these checks to exports and attachments as well as screens.
Document where production data, backups and logs reside, who can access them, and how test data is prepared. Assign an owner to confirm the requirements before a supplier receives production access.
What should count as a finished website or application?
Acceptance should describe observable behaviour. “Responsive”, “secure” and “fast” need agreed scope and evidence.
| Area | Put this in the acceptance plan |
|---|---|
| User journeys | Named tasks, expected outcomes and failure states on agreed devices and browsers |
| Content migration | An inventory, approved page mappings and checks that existing important URLs still reach the right content |
| Accessibility | A stated target, such as WCAG 2.2 AA, with keyboard, screen-reader and automated checks appropriate to the scope |
| Performance | Named pages or transactions, representative data, device and network conditions, and agreed response thresholds |
| Operations | A demonstrated restore procedure, monitoring ownership, release instructions and a support escalation path |
WCAG provides testable accessibility success criteria at different conformance levels. Agreeing a target gives both parties a clearer deliverable than promising an “accessible design”. It does not replace checking the obligations applicable to your organisation. W3C WCAG overview
For a portal, include a failed integration and a denied permission in the demonstration. For a content site, have the actual editor complete an update. Test the work people will perform after the supplier leaves.
Compare the cost of ownership, not just the build
Ask for separate launch and operating budgets. Configuration can still require migration, testing and training. Custom software requires an explicit plan for maintaining the code and its dependencies.
For each option, identify subscriptions, hosting, paid extensions, usage-based APIs, monitoring and support. Include your own team’s time for content, decisions and acceptance testing. Ask what changes when usage or transaction volume grows.
For Australian procurement, request a stated currency, clear GST treatment and any exchange-rate assumptions. Agree support hours in the relevant time zones, including daylight-saving changes where applicable. These are commercial inputs to confirm, not figures to infer from a vendor’s location.
Check the exit before entering: who controls the domain, platform accounts and repository, what data can be exported, and what another supplier needs to operate the system. Record custom IP and third-party licence arrangements in the contract review.
Use our Australian custom software cost guide for detailed budgeting. This scoping exercise supplies the requirements that make that calculation meaningful.
Copy this project brief before requesting quotes
Use these fields in a shared document. Replace an unknown with a named person and a decision date.
- Business outcome
- What should improve, and how will we measure it?
- First release
- Which user journeys must work at launch? What is explicitly deferred?
- Users and permissions
- Who may view, change, approve and export each type of record?
- Content and data
- What exists, what must migrate, and who approves its accuracy?
- Platform fit
- Which existing products have been tested? Which essential requirement remains unmet?
- Integrations
- Which systems exchange which records? Who supplies test access and owns recovery from failure?
- Acceptance
- Which devices, browsers, accessibility target, performance conditions and negative tests apply?
- Operations
- Who owns accounts, access, backups, monitoring, support and the exit procedure?
- Commercial comparison
- Separate discovery, configuration or build, migration, verification, launch and recurring costs. State currency, tax treatment, exclusions and change approval.
If the team cannot agree on the essential journey, pause the technology selection. Walk through one real transaction together and resolve who makes each decision.
With that brief ready, discuss your web project scope with Brainstack. Ask us to explain the platform fit, the custom boundary and the evidence needed to accept the result.
React
Node.js
Python
PostgreSQL
Odoo
Docker
Kubernetes
TypeScript
MongoDB