Fetching latest headlines…

Dev

Editable catalogues and course finders are not checkout systems

Dev.toUnited States · NORTH AMERICA

A small business website can need frequent content updates without needing a payment system. The distinction sounds obvious, but it is easy to lose when a quotation starts with a list of technologies...

2 views0 likes0 comments

A small business website can need frequent content updates without needing a payment system. The distinction sounds obvious, but it is easy to lose when a quotation starts with a list of technologies instead of the client's daily work.

Two projects we describe publicly at Webify illustrate the boundary. Vescun Pyörä can maintain bicycle listings through Sanity: update images, mark a bicycle sold or hide a listing. Black Eagle Taekwon-Do has course selection by age and location, while registration continues in the club's existing MyClub service. Neither public example is evidence of increased sales, traffic or search rankings. The useful technical lesson is about defining responsibility.

Start with one update, not a CMS feature list

Ask the person who will maintain the site to describe an ordinary change. For a bicycle, that could be changing availability. For a course, it could be changing a start date. Write down the fields, permitted values, preview step and publication step before selecting the editing interface.

Then decide what the website does when an item is hidden or sold. Should its old URL stay available with an explanatory state, redirect to a relevant alternative, or disappear? That decision affects visitors and existing links. The content model alone does not answer it.

Catalogue and checkout have different acceptance tests

A catalogue test might say: an editor changes an item's status, previews the result and publishes it without a developer. A checkout test needs additional scope: the chosen payment method, order confirmation, failed payment behaviour and the party responsible for fulfilment and returns.

If payment is outside the project, say so explicitly. The buyer should not infer a cart from the word "products", and the developer should not add one merely because the stack can support it.

Treat an external handoff as part of the journey

For an existing registration service, test the whole path from course selection to the correct destination. Check it on a phone and with a keyboard. Make the destination understandable before the visitor leaves. Agree who maintains the external service and who updates a changed link.

Measurement needs the same boundary. Clicking a registration link shows intent; it does not prove that a registration completed. A contact-button click is not an enquiry. Consent and production-host restrictions should continue to apply to the events used for reporting.

Handover is a deliverable

Record who owns the domain, hosting and CMS accounts; who pays recurring charges; who can publish; who restores a backup; and where instructions live. Include an observable test for each critical task and name the person accepting it.

A short responsibility table often prevents more ambiguity than another page of technology names. It also makes competing offers easier to compare: the same editing tasks, the same handoff, and the same operational responsibility.

Public implementation descriptions: Vescun Pyörä and Black Eagle Taekwon-Do. No private code or client images are supplied with this article.

Prepared with AI assistance. Implementation details come from Webify’s public case descriptions; no measured traffic or sales outcomes are claimed.

Comments (0)

Sign in to join the discussion

Be the first to comment!