Chapter 01 / 05
Separate the marketing website from the product
A startup can run its marketing site on WordPress and its application on a different stack. The two do not need one framework merely because they share a logo. Define authentication, navigation and ownership boundaries rather than forcing every feature into the CMS.
WordPress provides publishing capabilities and an extension ecosystem. A custom site can use a headless CMS or a small structured-content build. The important question is how editors create, preview, translate and publish content safely—not whether developers enjoy the technology.
| Decision | WordPress | Custom build |
|---|---|---|
| Regular nontechnical publishing | Established editor and roles | Needs a chosen CMS or editorial tool |
| Unusual product workflow | May need substantial plugin or custom work | Can model the workflow directly |
| Operating responsibility | Hosting, core, themes and plugins | Runtime, dependencies, services and deployment |
| Design flexibility | High with appropriate theme development | High with adequate engineering budget |
| Exit and portability | Content export plus theme/plugin dependencies | Source, documentation and service dependencies |
Chapter 02 / 05
The real WordPress trade-off is the extension chain
Use plugins to solve explicit needs and check their update record, compatibility, support and data behavior. Ten plugins that overlap can create more uncertainty than one well-maintained implementation. A visual builder is useful only if the team can edit without damaging the layout or loading unnecessary code.
Provide a staging workflow, updates, backups and restore tests. Give editors the minimum permissions they need. These are operating requirements, not arguments against WordPress. A well-maintained implementation can be reliable and fast.
Chapter 03 / 05
Custom does not mean maintenance-free
A custom build can make interactions, localization and performance more deliberate. It can also create a dependency on the only developer who understands it. Require a reproducible build, documented deployment, an accessible editor workflow and ownership of accounts and source.
An application with user data also needs server authorization, validation, backups, monitoring and incident handling. Moving these responsibilities outside WordPress does not make them disappear. Ask what changes when a service is discontinued or a developer leaves.
- Editing
- Can the team publish, preview and translate without a developer?
- Operations
- Who applies updates and proves a backup can be restored?
- Ownership
- Can another provider build and deploy from the delivered source?
Chapter 04 / 05
Compare total effort using the same brief
A theme-based project and an individually designed custom project are different deliverables. Compare the same content, languages, integrations and acceptance criteria. Estimate setup, content entry, QA, subscriptions, training and maintenance over a meaningful operating period.
Existing editorial skills may reduce training costs. Existing technical skills may favor the current application stack. Do not add a migration solely to claim a newer framework; account for redirects, content cleanup and the team’s ability to operate the replacement.
Chapter 05 / 05
Use a small proof before committing
Test the hardest page type in the proposed approach: a translated product page, a large comparison table or an integration that writes to the CRM. Let an editor change the content and a user complete the important action on a phone.
Compare actual output and workflow rather than slogans about speed or scalability. If WordPress fits the editorial work and the product is separate, it may be the pragmatic choice. If the website itself is a custom product, a purpose-built system may be easier to reason about.
For implementation: Explore the relevant service.
