A WordPress website is usually the better starting point when the job is publishing, campaign pages, editorial content and a conventional catalogue or checkout. A custom web application earns its cost when the website must run a business process: people sign in, see different data, submit work for approval, trigger integrations or rely on records that have to be correct.
For a Cape Town business, the useful question is not whether a custom build feels more sophisticated. It is whether the work contains rules, permissions and operational consequences that a collection of pages and plugins would make hard to understand or change. The same project can include both: WordPress for public content and a purpose-built application for the part that staff or customers use to do work.
Use the work, not the page count, to choose
A 20-page site can need careful design and engineering without being an application. Conversely, a small customer portal can carry serious risk if it shows invoices, changes bookings or lets one organisation act on another’s data. Start by listing the actions a user must complete after they have logged in. If the list is mostly reading, publishing or buying known products, a website may be enough. If it includes assigning, approving, reconciling, calculating or controlling access, scope the application behaviour before choosing a platform.
| Signal in the brief | Usually points to | What must be specified |
|---|---|---|
| Marketing pages, articles, reusable landing pages and contact capture | WordPress site | Content model, editor permissions, forms, analytics and the handover process. |
| Customers need an account to view their own orders, documents or service history | Custom application or a carefully bounded portal | Who may see each record, how accounts are created, and what happens when access changes. |
| Staff move work through states such as submitted, approved, rejected and completed | Custom application | Valid state changes, the person allowed to make each change, notifications and an audit trail. |
| The business needs content publishing plus a member area or operations tool | Hybrid build | The boundary between WordPress, the application, shared identity and the system of record. |
| A supplier system is the source of truth for stock, pricing, bookings or customer data | Integration-led build | Which system owns each field, sync direction, failure handling and a way to reconcile differences. |
This is a scope test, not a rule that WordPress cannot support custom work. WordPress has a REST API that exchanges JSON with other applications, and its documentation describes it as a foundation for the Block Editor as well as themes, plugins and custom applications. That makes a hybrid design possible. It does not remove the need to decide where business rules and sensitive data belong.
The five questions that expose application scope
- What is the system of record? Name the place that owns each important fact. If a booking exists in both an accounting package and a portal, decide which one wins when they disagree. A nightly import is not a decision about ownership.
- Who can do what to which record? Write permissions as sentences: “A branch manager may approve only requests for their branch.” Avoid a requirement such as “managers have access.” WordPress roles and capabilities provide a permission model, but a portal with organisation-specific access normally needs its own explicit rules and tests.
- What must happen if an integration fails? Specify retries, duplicate prevention, a visible failure state and the person who can resolve it. A webhook that succeeds in testing can still arrive late, arrive twice or fail while another system is unavailable.
- Which actions need a history? For approvals, price changes, exports and account changes, decide whether you need the actor, time, old value, new value and reason. This affects the data model early.
- What is the safe failure mode? A public article may tolerate a temporary publishing delay. An application that exposes account data should fail closed when it cannot establish permission. MDN notes that browsers may send a valid session cookie with a cross-site request, which is why session design and request protections need deliberate attention.
A short architecture worksheet for the procurement brief
Give prospective development partners the answers below before asking for a fixed quote. Unknowns are acceptable, but mark them as decisions to be made rather than burying them in a vague request for “a portal.”
- Users and organisations: List user types, whether users belong to an organisation or branch, and how invitations, departures and password recovery work.
- Core records: Name the objects that matter: customer, order, booking, claim, document or asset. Include the identifier that connects each object to another system.
- Rules: Describe the approval states, calculation rules, cut-off times and exceptions in plain language. Put examples beside rules that have financial or compliance consequences.
- Integrations: For every external system, state the owner, available interface, data direction, frequency, error contact and fallback when the interface is down.
- Operations: State who publishes content, manages users, handles support, receives error alerts and approves releases after launch.
- Non-functional requirements: Record the expected number of concurrent users, response expectations for important actions, retention needs, backup recovery expectation and accessibility standard where relevant.
The worksheet is useful because it turns “build an app” into testable scope. It also separates a design preference from a constraint that changes architecture, security review or ongoing support.
Security and maintenance change the comparison
Once a system holds customer data or controls a business action, the build needs an access-control design, secure session handling, input validation, logging and a plan for patches and incident response. The OWASP Application Security Verification Standard is a practical requirements catalogue for reviewing those controls. It is not a certificate and it does not make a system secure by itself. It gives a project team a shared list of things to verify.
That work can be appropriate for a WordPress implementation too. The distinction is where complexity lives. A content-led site can use established WordPress editing and roles, then be maintained through disciplined updates and review. A custom application needs named ownership for the codebase, dependencies, deployment path, monitoring and data changes. Treating either option as a once-off handover usually creates trouble later.
When a hybrid build is the sensible answer
Hybrid builds fit organisations that need a strong public site and a separate operational tool. WordPress can manage the public pages, articles and campaign content. A custom application can handle authenticated workflows and integrate with the systems that hold operational data. The boundary should be written down: which application authenticates users, which database owns each record, and which interface is allowed to write it.
That boundary also keeps future work clearer. A content editor should not need access to operational records to publish a page. A portal release should not have to wait on a marketing copy change. The trade-off is that the integration and identity boundary has to be designed and maintained, rather than assumed away.
Choose the next discovery step
If the work is primarily a public website, start with the content, design, technical integrations and ownership model. Galactic Digital’s Cape Town web development service covers marketing websites, customer portals, booking systems and integrated web applications. If a public site also needs brand and interface work, see the web design service.
If users, organisations, approvals or supplier data are central, bring the completed worksheet into discovery. It gives a development team enough material to identify the risky assumptions before a build plan hardens. For delivery governance across several suppliers or systems, Galactic Digital also offers technical project management. Contact Galactic Digital to discuss the scope.
Sources used
- REST API Handbook, WordPress Developer Resources. Supports the description of the WordPress REST API and its use by custom applications.
- User roles and capabilities, WordPress Developer Resources. Supports the description of WordPress permissions.
- Session management, MDN Web Docs, updated 24 February 2026. Supports the session-cookie security point.
- Application Security Verification Standard, OWASP. Supports the recommendation to use verification requirements during security review.
Featured image: Programming code by Martin Vorel licensed under CC BY-SA 4.0.
