Capabilities
Websites, products and the systems behind them.
Three areas of practice and one way of working. Most projects start in one area and reach into the others.
Websites and commerce
Ask about websites and commerceThe part of the work people meet first. Websites, storefronts and product interfaces with considered typography, a clear structure and interaction that earns its place.
What it covers
- Company and marketing websites
- Storefront and catalogue experiences
- Product and application interfaces
- Design systems and component libraries
- Content structure and CMS integration
- Front-end engineering, accessibility and performance
Products and platforms
Ask about products and platformsSoftware people use every day: customer-facing products, internal tools, enterprise platforms and hospitality systems, shaped around the task and the person doing it.
What it covers
- Discovery, scoping and product definition
- Web applications and internal tools
- Enterprise and hospitality platforms
- Roles, permissions and multi-tenant structure
- Release planning and handover
Operations and integrations
Ask about operations and integrationsThe operational layer underneath: the workflows, the record the business runs on, and the connections between the systems it already has.
What it covers
- Workflow and approval design
- ERP and management software
- Hospitality operations
- Integrations between existing systems
- Data models, migration and reporting
- Infrastructure, deployment and operations
How the work is organised
One stack, five layers.
Whatever the starting point, the same five layers are involved. How far each goes depends on the brief.
L1
Experience
The surfaces people actually work in, often for eight hours a day, often under pressure, often on hardware nobody chose.
What the work involves
- Map the real task, including the parts staff currently work around
- Design operator interfaces for speed and error recovery, not for demos
- Build accessible, keyboard-complete interaction to WCAG 2.2 AA
- Design the degraded states: slow network, partial data, offline, failure
- Test against the devices and screen sizes the operation actually uses
What the client receives
- Task and interface inventory
- Component library with interaction and accessibility specifications
- Annotated screen flows covering error and edge states
L2
Workflows
The operational logic: what has to happen, in what order, who can intervene, and what happens when a step fails.
What the work involves
- Model the current workflow including its informal steps and workarounds
- Define state machines, approval chains, and exception handling explicitly
- Separate configurable policy from hard-coded rules
- Design for reversal: corrections, voids and re-runs are normal operations
- Specify what the system must refuse to do
What the client receives
- Workflow and state models
- Rule catalogue with owners and change process
- Exception and escalation matrix
L3
Integrations
The boundaries with everything the operation already runs. This is where most operational risk actually lives.
What the work involves
- Inventory upstream and downstream systems, their owners, and their limits
- Define contracts, idempotency, retries, and reconciliation for each boundary
- Design for partner downtime rather than assuming availability
- Instrument every boundary so failures are visible before customers find them
- Keep a replayable record of what crossed each boundary
What the client receives
- Integration register with direction, protocol, and owner per boundary
- Interface contracts and versioning policy
- Reconciliation and replay procedures
L4
Data
The record the business is run and audited from. It has to survive migration, correction, and years of change.
What the work involves
- Model the domain so the schema still makes sense in three years
- Design migration as a reversible, reconcilable, rehearsed operation
- Define retention, correction, and audit-trail behaviour up front
- Separate operational stores from reporting so neither degrades the other
- Make data-quality problems visible instead of silently absorbing them
What the client receives
- Domain and storage model with retention policy
- Migration plan including rollback and reconciliation
- Audit and correction specification
L5
Infrastructure & operations
What it takes to keep the system running after launch: the part of the work that outlasts the project.
What the work involves
- Define the permission and tenancy model before the first deployment
- Build repeatable, reversible deployments with a rehearsed rollback
- Instrument the operation: logs, metrics, traces, and meaningful alerts
- Plan capacity around the operation’s real peaks, not average load
- Hand over runbooks so the system can be operated without AxedStack
What the client receives
- Environment, permission, and tenancy model
- Deployment pipeline with rollback procedure
- Runbooks, alert definitions, and observability dashboards
Operational examples
Three systems, followed end to end.
Illustrative models of common problem classes, not client systems. Follow each from the business need to the architecture behind it.
Hospitality operations
Property management, distribution, and the front desk are one system with many owners. A single booking touches availability, pricing, housekeeping, payment, and the night audit before anyone checks in.
Business view
One booking, six departments, no room for a silent failure.
Hospitality operations run continuously. The cost of a broken workflow is not a support ticket. It is a guest standing at a desk while a member of staff apologises.
- Front desk, housekeeping, revenue, and finance all depend on the same record
- Overbooking, rate errors, and failed payments surface at the worst moment
- Staff turnover means the system has to be learnable in a shift, not a week
- Peak season is exactly when the system is least able to be taken offline
System view
A central record with many integrations and a narrow maintenance window.
The property management system sits at the centre of a busy integration surface, holds valuable guest and payment data, and rarely has an acceptable window for downtime.
- Availability and rate logic must stay consistent across every distribution channel
- Payment and door-access boundaries carry real security obligations
- Multi-property tenancy shapes the permission model from day one
- The night audit is a scheduled job the business genuinely depends on
Hospitality operations
A reservation is created
L1 Experience
- Booking surface, entry point, step 1 of 5 on the request's path
- Front desk, on the operational path
- Housekeeping, on the operational path
- Revenue console, alongside the path
L2 Workflows
- Availability check, step 2 of 5 on the request's path
- Rate & policy, on the operational path
- Room assignment, on the operational path
- Folio & charges, on the operational path
- Night audit, alongside the path
L3 Integrations
- Payment gateway, step 3 of 5 on the request's path
- Channel manager, on the operational path
- Door access, alongside the path
- Accounting, alongside the path
L4 Data
- Folio ledger, step 4 of 5 on the request's path
- Guest profile, on the operational path
- Room inventory, on the operational path
- Rate plans, alongside the path
L5 Infrastructure & operations
- Audit log, step 5 of 5 on the request's path
- Multi-property tenancy, on the operational path
- Scheduled jobs, alongside the path
- Monitoring, alongside the path
Illustrative. A model of the problem class, not a client system.
Enterprise workflows
Approval, procurement, and finance workflows carry the controls the business is audited against. The system has to be fast enough to use and strict enough to defend.
Business view
The control is only real if people can still get their work done.
When an approval workflow is slow or unclear, the organisation routes around it. The control then exists on paper and nowhere else.
- Delay in an approval chain is measured in stalled operations, not in clicks
- Finance needs the audit trail; operations needs the throughput
- Cost-centre and delegation rules change more often than anyone plans for
- A workaround adopted once becomes the process within a quarter
System view
Explicit state, explicit permissions, and an audit trail that holds up.
The workflow engine, the permission model, and the ledger boundary are the three places where this class of system usually fails.
- Approval chains are data, not deployments, so policy changes without a release
- Every state transition is recorded with actor, timestamp, and reason
- The ledger boundary is reconciled, not assumed
- Identity comes from the organisation’s provider, not a second user directory
Enterprise workflows
A purchase order is raised
L1 Experience
- Requisition form, entry point, step 1 of 5 on the request's path
- Approver inbox, on the operational path
- Finance console, on the operational path
- Policy admin, alongside the path
L2 Workflows
- Budget check, step 2 of 5 on the request's path
- Approval chain, on the operational path
- Goods receipt, on the operational path
- Three-way match, on the operational path
- Exception handling, alongside the path
L3 Integrations
- Supplier catalogue, step 3 of 5 on the request's path
- ERP ledger, on the operational path
- Identity provider, on the operational path
- Document store, alongside the path
L4 Data
- Approval history, step 4 of 5 on the request's path
- Cost centres, on the operational path
- Vendor master, on the operational path
- Audit trail, alongside the path
L5 Infrastructure & operations
- Retention policy, step 5 of 5 on the request's path
- Role & permission model, on the operational path
- Job queue, alongside the path
- Observability, alongside the path
Illustrative. A model of the problem class, not a client system.
High-performance digital platforms
Public platforms are judged on the first paint and on the incident that never became visible. Speed, correctness, and operability are the same problem.
Business view
The platform is the operation, so its performance is an operating cost.
When a platform is the primary channel, latency, downtime, and content bottlenecks all convert directly into commercial outcomes.
- Teams need to publish and change things without an engineering release
- Traffic peaks are commercial events, not infrastructure trivia
- A regression that ships on Friday is a weekend of lost revenue
- Accessibility and performance are procurement requirements, not extras
System view
Bounded work at the edge, an honest cache strategy, and a reversible deploy.
Most platform performance problems are architectural. They are decided long before anyone opens a profiler.
- Render strategy is chosen per route, not adopted wholesale
- Cache invalidation is designed with the content model, not retrofitted
- Every deployment is reversible, and rollback has been rehearsed
- Error budgets and real-user measurement drive what gets worked on next
High-performance digital platforms
A request enters the platform
L1 Experience
- Public interface, entry point, step 1 of 5 on the request's path
- Authenticated app, on the operational path
- Editor surface, on the operational path
- Admin, alongside the path
L2 Workflows
- Routing & validation, step 2 of 5 on the request's path
- Business rules, on the operational path
- Content model, on the operational path
- Search & retrieval, alongside the path
L3 Integrations
- Third-party APIs, step 3 of 5 on the request's path
- Auth provider, on the operational path
- Payments, alongside the path
- Measurement, alongside the path
L4 Data
- Media pipeline, step 4 of 5 on the request's path
- Primary store, on the operational path
- Cache & invalidation, on the operational path
- Event log, alongside the path
L5 Infrastructure & operations
- Real-user measurement, step 5 of 5 on the request's path
- Edge delivery, on the operational path
- Deploy pipeline, on the operational path
- Error budget, alongside the path
Illustrative. A model of the problem class, not a client system.
Assurance
Questions about security, testing, migration or ownership are best asked with your brief. Published statements are limited to what has been verified; see how assurance is handled.
Have a project in mind?
A website, a product or a system behind the business. Tell us what you are making.