Websites & applications / 13 September 2026
Website or web application? Choosing the right starting point
A practical guide for Zambian organisations deciding whether they need an informational website, a web application, or a staged combination of both.
01
Start with what people need to do
A website and a web application can look similar in a browser, but they solve different kinds of problems. A website mainly helps people understand an organisation, discover services, view work or information, and make contact. A web application supports an ongoing task such as submitting and tracking requests, managing records, approving work, producing reports, or serving a signed-in customer account.
The useful first question is not which technology sounds more advanced. Ask who will use the service, what they need to complete, what information moves through the process, and what happens after they press submit. If the main need is clear public information and enquiries, begin with a strong website. If users must return, manage data, or move work through defined states, a web application may be justified.
02
When a website is enough
Choose a website when the organisation needs a credible public presence, service explanations, searchable resources, news, locations, contact details, or a manageable content library. Good content structure often creates more value than custom software. Staff should be able to keep key information current without asking a developer for every small change, and each page should have a clear audience and next step.
A website still needs careful engineering. It should load well on mobile networks, use secure hosting, make forms dependable, and be understandable to search engines. Google advises people-first, well-organised, original, current content rather than writing for imagined ranking tricks. Search visibility also takes time and is never guaranteed. A useful site earns attention by answering real questions clearly and maintaining those answers.
03
When the work needs an application
A web application becomes appropriate when a spreadsheet, inbox, or paper trail no longer gives the organisation enough control. Signs include repeated data entry, unclear ownership, requests that disappear between teams, multiple versions of the same record, or reports assembled manually from several sources. The application should improve a defined workflow, not simply put the existing confusion behind a login screen.
Map the current process before specifying features. Identify roles, permissions, decisions, exceptions, notifications, records, and reporting needs. Then define a smallest useful release that completes one end-to-end journey. Integrations, dashboards, automation, and additional departments can follow after the core process works. This staged approach reduces assumptions and creates evidence for the next investment decision.
04
Requirements shared by both
Whether the result is a website or application, accessibility belongs in the requirements. The World Wide Web Consortium's WCAG 2.2 provides a testable standard for making web content more accessible across disabilities and devices. In practical terms, plan for keyboard use, readable contrast, useful headings, text alternatives, understandable forms, visible focus, and error messages that explain how to recover.
Performance should also be measured from the user's side. Google's Core Web Vitals focus on loading, responsiveness, and visual stability. The exact metrics can evolve, but the underlying lesson is steady: test on real pages, real devices, and realistic connections. Security, privacy, backups, analytics, content ownership, and maintenance responsibilities need named owners before launch, rather than being treated as optional finishing work.
05
Sometimes the answer is a sequence
Many organisations need both, but not on the same day. A public website can first clarify services, improve discovery, and collect structured enquiries. The organisation can learn which requests are common and where follow-up slows down. That evidence can shape a later portal or internal application. Starting with the public journey also prevents a complex system from being built around unclear content and an untested process.
Write a one-page brief before requesting a proposal: audience, primary task, current difficulty, required content or records, responsible staff, integrations, constraints, and what success will look like after launch. A good development partner should be able to explain why the proposed form fits that need. The right starting point is the smallest dependable product that completes the important job and can grow without discarding its foundations.
Sources
Official references
This ONBRD editorial article draws on the following primary sources. The practical recommendations are ONBRD's interpretation for organisational planning.