Product Engineering

Why this sits next to the AI work#

Most of what we are asked to build is not an AI feature. It is a booking engine, a franchise provisioning portal, a ticketing platform or a customer account area — with AI somewhere inside it, doing one specific job.

Treating those as separate disciplines is how you get a good model bolted onto a platform that falls over at launch. The platform is the product. The AI is a component of it, and it should be scoped, built and operated by the people who own the whole thing.

What we actually build#

Booking and reservation systems. Availability, holds, group and multi-party bookings, cancellation and refund logic, and the payment flows underneath. The hard part is never the calendar — it is concurrency, partial failures and the states a booking can be in when a payment times out.

Provisioning and multi-tenant platforms. Spinning up a new site, franchise, branch or tenant with its own configuration, branding, users and billing, without a human doing setup by hand each time.

Customer portals and account areas. Self-service that genuinely deflects support volume rather than adding a login page in front of the same phone number.

Commerce and packaging. Catalogues, bundles, subscriptions, upgrades, proration and the reconciliation to finance that nobody scopes until it is missing.

Real-time and high-concurrency surfaces. Live scores, live availability, live inventory — where the interesting engineering is fan-out and cache invalidation rather than the read itself.

The states that decide whether a build is finished#

A demo shows the happy path. Production is mostly everything else, and this is the list we work through explicitly rather than discovering under load.

Concurrency. Two people booking the last slot. The hold that expires mid-checkout. The admin editing a package while a customer is buying it.

Payment edge cases. Authorised then failed. Succeeded but the webhook never arrived. Refunded partially. Disputed three weeks later. Each needs a defined system state, not an exception in a log.

Partial failure. The payment worked and the confirmation email did not. The booking saved and the downstream sync did not. Deciding what is authoritative, and how it reconciles, is a design decision made once rather than a bug found repeatedly.

Expiry and time. Holds, sessions, offers, promotional windows and time zones. Every booking system we have inherited has had at least one bug here.

Scale shape. Not average load — the shape. A ticket on-sale, a results announcement and a sale launch are all spikes with different profiles, and the profile is what breaks you.

How this pairs with the rest#

Product Engineering is the build rung. Either side of it:

• Before — AI Strategy & Readiness when the problem is not yet framed, and it is not obvious that building is the right answer.
• Underneath — Infrastructure Management and DevOps for the environments, pipelines and capacity.
• Inside — Custom AI Development for the intelligent component, and AI Automation for the operational workflows around it.
• After — NoOps to run it, and Growth & Demand Generation to make it earn.

What we will talk you out of#

Building what you can buy. If a mature SaaS product covers eighty per cent of your requirement, the honest answer is usually to buy it and integrate the missing twenty, and we will say so even though it is a smaller engagement for us.

The case for building is specific: the process is genuinely how you compete, the integration surface is unusual, the unit economics of per-seat pricing do not work at your volume, or you need to own the data. Where none of those hold, a build is an expensive way to get a worse version of something that already exists.