Short answer: choose the platform after defining the customer action, content workload, integrations, ownership model and ongoing support. In four real KWD scopes, those requirements led to four different answers: WordPress for a service-led quote journey, a dedicated booking system for appointments, Shopify for retail checkout and shipping, and a lean Astro landing page for one paid-search campaign.
Generic platform comparisons often end with one product being declared “best”. Real projects are less tidy. A platform is useful only when it fits the work the business and its customers need to complete.
This decision log records the requirements behind four Kiwi Web Design recommendations. The public client examples describe delivered scope, not unmeasured revenue or ranking outcomes. The retail example is anonymised because it came from a private proposal.
Decision summary
| Project need | Platform decision | Deciding requirement | Main trade-off |
|---|---|---|---|
| Scaffolding service site and structured quote journey | WordPress | Editable service pages plus custom enquiry logic | Updates, plugins and hosting need maintenance |
| Treatment pages and appointment availability | Website plus Trafft booking | Time slots, service selection, confirmations and reminders | Booking software adds configuration and dependency |
| Product catalogue, checkout and regional shipping | Shopify | Product operations and hosted commerce workflow | Platform and app costs continue after launch |
| One paid-search offer with tightly controlled tracking | Astro landing page | Speed, focused message and code-level measurement | Routine content edits usually need a developer |
Decision 1: WordPress for a service business with custom quoting
The requirement
Barrett Access Scaffolding needed to explain three different service contexts: residential, commercial and industrial. The website also needed a structured quote pathway that collected useful job details instead of sending every visitor through a generic contact box.
Why WordPress fit
The content model was more important than ecommerce. WordPress supported separate service pathways, project information, mobile content and a quote form while leaving the business with a familiar system for future page and image updates.
The current live site identifies itself as WordPress. That makes the operational requirements equally important: the business needs a responsible owner for hosting, backups, security updates, plugin compatibility and form delivery.
Why a hosted store was not the answer
There was no retail catalogue, stock workflow or standard checkout. Using Shopify would have introduced commerce administration without solving the central job, which was qualifying a project enquiry.
Decision rule: use WordPress when structured service content and flexible lead capture matter more than native product operations.
Decision 2: add a booking system when availability is the product
The requirement
For Beauty Touch Auckland, the customer needed to choose a treatment, understand its duration and price, select a time, and receive confirmation. Six treatment pages had to connect to that appointment journey.
Why Trafft was part of the scope
A normal form records a request; it does not manage live availability. Trafft was integrated so the booking layer could handle treatment selection, time slots, automated confirmations and reminders.
The website still carries the explanatory and trust content. The booking system carries appointment logic. Keeping those roles distinct makes it easier to test each part.
What discovery must settle first
“We need booking” is not enough information. Before choosing software, confirm:
- whether appointments are instant or require approval;
- staff, rooms or equipment that constrain availability;
- deposits, full payment or pay-on-arrival;
- cancellation and rescheduling rules;
- email or SMS reminders;
- calendar, accounting or CRM integrations;
- ownership of customer data and export options.
Decision rule: use dedicated booking software when availability, resources and reminders are core operating data, not merely a contact preference.
Decision 3: Shopify for a retail operation with shipping rules
The requirement
In June 2026, KWD scoped a New Zealand pet-product store. The buyer specified a product catalogue, cart and checkout, search metadata, and fixed shipping rates across agreed regions. The shipping rules applied across the catalogue and had to be maintainable after handover.
Why Shopify was recommended
The project was fundamentally a store. Shopify provided the product administration, hosted checkout and shipping framework in one operating system. That was a better fit than assembling basic commerce functions around a brochure-site platform.
This was a proposal decision, not a published performance case study. We are not claiming sales, conversion-rate or launch outcomes from it.
What the recommendation did not remove
Shopify reduces infrastructure work but does not eliminate scope. Product data, variants, tax, shipping regions, returns, payment methods, app licences, analytics and customer-service processes still need explicit owners.
Custom shipping logic is especially important to define. “Advanced shipping” may mean fixed zones, carrier-calculated rates, weight bands, postcode exclusions, click-and-collect or multiple dispatch locations. Those are different builds.
Decision rule: use Shopify when the daily job is managing products, orders, payments and fulfilment, and accept the continuing platform and app costs as operating expenses.
Decision 4: a lean landing page for one paid-search campaign
The requirement
KWD’s own /web-design-auckland-lp/ page was built for a focused Google Ads campaign. It needed one message, a short conversion path, fast delivery on Cloudflare and deterministic attribution fields for leads.
Why Astro fit
The page is part of KWD’s Astro site. That allowed precise control over markup, scripts, event names and hidden attribution data without installing a general page builder for one campaign.
The trade-off is deliberate. A code-managed landing page is efficient when a developer owns the campaign site, but it is less convenient for an owner who expects to rearrange page sections every week.
The build also showed why platform choice does not replace QA. KWD later corrected a Google Analytics loading race, Web3Forms spam-filtering behaviour, and form-attribution naming. The page technology made those fixes possible; it did not make testing optional.
Decision rule: use a lean coded landing page when the scope is narrow, performance and tracking need close control, and a developer will maintain it.
The five questions we now answer before naming a platform
1. What must the customer complete?
Read, enquire, request a quote, select an appointment, buy a product, reserve a table and submit an application are different jobs.
2. What data changes every week?
Service copy, products, stock, prices, availability and member records create different editing and integration needs.
3. Which accounts must the business own?
The proposal should name the owner of the domain, hosting, CMS, store, booking tool, payment gateway, analytics, Search Console, advertising and premium licences.
4. What continues to cost money?
Compare hosting, maintenance, subscriptions, transaction fees, premium apps, support and developer work. Total cost of ownership is more useful than the build price alone.
5. What happens if the provider relationship ends?
Ask what can be exported, which licences stop, how administrator access transfers and whether the site can move to another host or developer.
A practical platform recommendation
- Choose WordPress for content-rich service websites that need flexible pages and integrations, provided maintenance has an owner.
- Choose Shopify when product, checkout and fulfilment operations are central.
- Add a proven booking system when real availability and reminders must be managed.
- Choose a lean landing page when one campaign needs tight message and tracking control.
- Use a hosted builder for a genuinely simple site only after checking export, SEO, integration and ownership limits.
The best platform is the one whose constraints match the business. To compare a real scope, contact Kiwi Web Design with the customer action, integrations, editing needs and ownership model. Those four details usually narrow the decision faster than a feature list.