Commercial

The question every parts buyer asks first: does this part fit?

Someone whose appliance has stopped working does not want to learn about part numbers. They want the right filter, the right seal, the right battery, and to be certain before they pay. Get it wrong and the part comes back, the refund goes out, the sale is gone.

Behind that sit 2 more doubts, so the whole purchase turns on 3 questions:

• will this part fit my machine
• when will it arrive
• is it genuine

Answering all 3 plainly is how a parts store earns its living.

One engagement, bought in pieces: identity, data, search, storefront

The business is an owner-operated Australian retailer selling parts nationally through its own BigCommerce storefront and the major marketplace channels, and it is growing into new appliance categories. We were engaged directly, and the first thing we settled together was the order of work, not a design or a technology.

The engagement runs as 5 independent streams:

• the visual identity
• the compatibility data
• the fitment search on top of it
• improvements to the current store
• the rebuild

Only the rebuild has a real predecessor: it implements the identity, so it waits, and we said so in the quotation instead of starting it at low intensity. For a client, that reads as control: each stream starts when it is worth starting, and nothing sits half-built while it waits.

Across the streams we have provided discovery, brand and design, architecture, data engineering and development.

A brand decided by looking: personas, logo systems, complete directions

The business already had the verbal half of its brand, commissioned separately and approved. Ours is the visual half.

We started with the customers rather than a mood board:

• personas built from the store's own order data
• a brand brief
• a visual audit of the category

Then, rather than argue for a single direction, we built several complete ones and set them side by side, each with its own logo system, colour, typography and mockups, so the choice could be made by looking rather than by imagining.

2 moments matter. Our first persona analysis leaned on a sample that under-counted parts of the catalogue; the client caught it, we rebuilt it from the authoritative export with numbered corrections, and the recommendation held. Correcting ourselves in public bought more trust than being right would have.

Later the owner drew his own mark, so we vectorised it and rebuilt the identity around it.

Turning fitment into structured data and a live search widget

Which machines a part fits is the most important fact about that part, and in a catalogue grown over years that knowledge lives in the product description, written by whoever put it there.

Our job was to turn it into data the store can use. We built a scripted, unit-tested, rerunnable pipeline that reads the catalogue, extracts every compatible-model mention, and resolves the ambiguous ones into clean brand, series and model records mapped to the products that fit them.

AI does a single job in that chain, the judgement call; the rest is deterministic code that can be tested and re-run. Every mapped row keeps the sentence it came from, and because an AI pass always discards something, the discards are reviewed as a deliverable in their own right.

On top of that data sits the finder. A firm rule against recurring app fees ruled out every paid fitment app, and the constraint produced better engineering.

We used the platform's own category system as the managed vocabulary of machine models, native and free, then built the search as a small widget reading live from the storefront's GraphQL API. No app, no monthly fee. A customer types their model and sees only the parts that suit it, whether that part fits a single machine or hundreds.

Changing a live catalogue: a staged, reversible deployment

A catalogue-wide change on a store that is taking orders today is what keeps an owner awake, so the deployment is written down before it runs, as a document for the client. It is staged rather than a single switch, with the safeguards written into the plan:

• every stage individually reversible
• a full store export as the restore point
• idempotent scripts
• a rehearsal on a sandbox before production
• the original descriptions archived rather than replaced
• rollback triggers agreed in advance on business measures rather than error logs

For a store owner, that reads as a decision they can reverse: any stage can be stopped and undone on measures the business already watches.

The rebuild, meanwhile, has its discovery banked, including an information architecture organised around compatibility rather than product categories and built from the start to carry additional product ranges.

And since a brand cycle runs for months, we sorted the current store's improvement work by whether an item survives the rebuild, so what holds its value can go ahead now.

Where it stands: identity delivered, fitment search proven in a sandbox

• the identity is locked and the brand book delivered
• the fitment search is proven in a sandbox and waiting on the production data load
• the migration is planned but not yet run

A fitment search built on the storefront's own category system and GraphQL API: no app, no monthly fee.

What is already paying off is the order the work is being done in.

For stores where the wrong part comes back

Everything on this page is 5 of our services running on one live retail catalogue: discovery and sequencing, brand and design, architecture, migration of the product data, and custom development on the storefront. The extraction pipeline is AI-assisted delivery in its plainest form: AI makes the judgement call, deterministic code does the rest, and what the AI discards is reviewed by a person.

If you sell parts, spares or consumables where the buyer has to be sure a product fits before they pay, this is the shape the engagement takes: compatibility pulled out of the descriptions it is buried in, a search built from what the platform already gives you, and a catalogue-wide change staged so it can be stopped and undone.

If your product descriptions know what fits but your storefront does not, tell us what your catalogue looks like.

When a website has to sell a regulated product: energy pricing before a quote

Most websites show a price. An energy retailer's website has to work one out first.

Before anyone can be quoted, the platform has to establish:

• which meter sits at their address
• which distributor serves it
• which tariffs apply
• which offers may legally be sold in that state

Only then is there a number to put on the screen. That chain runs live, while someone waits on a form.

Everything attached to it is regulated too, from the fact sheet that accompanies every offer to the wording on the offer itself. It is a transaction engine wearing a website's clothes, and it still has to stay editable by the marketing team.

Our part in the work: Drupal architecture and the delivery toolchain

The client is a national energy retailer, selling electricity and gas to households and small businesses across several states and territories. In 2020 it replatformed its public website onto Drupal(Opens in a new tab/window).

We were engaged through a partner agency, which ran the delivery programme, as the Drupal architecture and platform engineering partner, while a specialist design agency supplied the experience design.

Alongside the architecture, we stood up and ran the delivery toolchain the whole engineering team worked through:

• the source-control organisation
• the continuous integration account
• the automated code quality checks
• a containerised local environment so every developer ran the same stack

For a client, that shared setup reads as consistency: every developer on the programme worked to the same checks, whoever they worked for.

The brief itself was easy to state and hard to build: let the marketing and sales teams manage their own offers and content.

5 sign-up journeys, and one of them is moving house

The platform carries 5 separate sign-up journeys rather than one, because a household, a home office, a small business and a specialist offer are each sold and priced differently. The main one is a 5-step checkout.

Moving house has its own 7-step flow. Relocating is the highest-intent moment in energy retail, and it asks different questions: when the power needs to be on, and what a technician will find at the property.

That last part is what separates this from an ordinary web form. The output of the funnel is a work order for someone who will physically attend a house.

Around them sit the things regulation requires:

• energy fact sheets issued as part of the flow
• separate concession forms for the states that administer them their own way
• payment handled by dedicated providers

An address is not an address: validating it into a regulated meter identity

The hinge the whole funnel turns on is a translation the customer never sees. Someone types a street address the way they would write it on an envelope.

The platform validates it, then converts it into the shape the national electricity market registry expects, so a typed address becomes a regulated meter identity.

If one meter matches, the journey continues without the customer noticing. If several do, they pick from a short list. Electricity and gas resolve separately.

Everything downstream depends on that one step. Without a meter identity there is no distributor, without a distributor there are no tariffs, and without tariffs there is nothing that can lawfully be sold. It looks like a form field and it is actually the architecture.

Editable by the people who own the offers: a content model marketing can run

Energy offers change often and their presentation is regulated, so the people accountable for the wording need to change it without waiting for a release.

The offer model was built so every element of an offer card is separately editable, and page structure lives in a visual layout builder rather than in code. Giving the business that control was the stated goal of the replatform, and it is the part that outlasts a redesign.

For a marketing team, that reads as autonomy: changing the wording on an offer is a content edit, not a release.

What we carried forward: request logging and integration health

2 ideas from this build have shaped how we approach integration-heavy platforms since.

The first is request-scoped debug logging: when one page depends on a dozen live calls to other systems, you want the story of a whole request in one place, not scattered across log lines.

The second is treating the health of those integrations as a feature, so anyone can see which upstream systems are answering. We have since built that idea into a package of our own.

5 sign-up journeys and a 7-step move-home flow, all hanging off a single address lookup.

Most people picture Drupal as a content site. This was a regulated transaction engine with a content site attached, and the content management was the least interesting part of it.

For platforms where signing up is the product

Everything on this page is 3 of our services running on one regulated acquisition platform: Drupal architecture for a transaction-heavy build, development against live upstream systems, and the delivery toolchain and containerised environments the engineering team worked through.

If you sell a regulated product online, in energy, insurance or telecommunications, this is the shape the engagement takes: an architecture built around the one lookup everything downstream depends on, sign-up journeys designed per customer type, and a content model the business can change without a release. The same engineering is available with AI-assisted delivery where it suits the work.

If your sign-up funnel is the slowest part of your platform to change, or your quoting depends on systems you do not control, tell us what the funnel has to do.