Projects

How we think through the systems we build

These are concept builds: worked examples that show how we approach architecture, scope, and trade-offs in each discipline. They are not client engagements, and no results are claimed for them.

Websites

Code editor showing the component structure of a corporate website build

Concept build

Meridian Corporate Website Platform

Concept build — a multi-region corporate website for a mid-sized services group, structured around division-level landing pages, a careers area, and an insights hub. It would suit organisations whose current site has grown by accretion and no longer reflects how the business is actually organised.

The challenge: Corporate sites often accumulate pages from several agencies and internal teams, so navigation, tone, and page performance drift apart over time. Marketing then struggles to publish a campaign or a regional variant without developer involvement, and visitors cannot tell which division they should be talking to.
Proposed approach: The front end is a Next.js App Router application with statically rendered marketing pages and incremental regeneration for the insights hub. Content is modelled in a headless CMS as reusable blocks — hero, feature grid, statistics-free proof strip, quote, call to action — so editors compose pages rather than edit markup. A design-token layer in Tailwind CSS keeps division themes visually related but distinguishable, and route-level metadata feeds Open Graph and structured data. Regional variants are handled by locale-aware routing with per-market content overrides. A Lighthouse budget in continuous integration guards against performance regressions on every pull request.

Next.js
TypeScript
Tailwind CSS
Headless CMS
Vercel
Playwright

Clinician using a mobile device to review clinic information

Concept build

Northwind Clinic Group Website

Illustrative concept demonstrating an accessible healthcare group website, combining practitioner directories, service descriptions, and location pages with an appointment request flow. It is aimed at multi-site clinics that need one credible public presence instead of a page per practice.

The challenge: Healthcare providers must publish a great deal of regulated information — practitioner credentials, opening hours, service descriptions, accessibility details — while keeping it accurate across several locations. Patients frequently abandon the search when they cannot confirm whether a specific service is offered at a specific site.
Proposed approach: Content is modelled as locations, services, and practitioners in a structured schema, with relationships driving automatically generated location-by-service pages so no combination is missed. Server-rendered pages meet WCAG 2.2 AA targets: semantic landmarks, visible focus states, keyboard-operable directory filters, and text alternatives for all imagery. An appointment request form validates against the selected service's intake requirements, acknowledges the request by email, and forwards it to the relevant practice inbox rather than confirming a slot the clinic cannot guarantee. Static rendering with ISR keeps pages fast on mobile connections, and a scheduled content review workflow nudges staff when opening hours pass a staleness threshold.

Next.js
React
TypeScript
Tailwind CSS
PostgreSQL
Resend
Vercel

Students browsing programme information together on a laptop

Concept build

Atlas Institute Public Website

Concept build — a public website for an education or research institute, covering course and programme listings, faculty profiles, news, and an events calendar. The intended audience is institutions publishing frequently changing, deeply interlinked content.

The challenge: Institutions publish across faculties that each keep their own calendars and editorial habits. Prospective students see outdated programme pages, and internal teams duplicate the same information in several places, which guarantees that at least one copy is wrong.
Proposed approach: A single content model holds programmes, faculties, people, and events, with a shared taxonomy so anything can be filtered by faculty, level, or format. The site is built in Next.js with server components for listing pages and cached data fetching, plus a search layer that indexes programmes and events for typo-tolerant retrieval. An editorial workflow adds draft, review, and scheduled publication states so faculties can prepare content without publishing early. Calendar feeds are generated as iCalendar endpoints for reuse in external tools, and automated link and accessibility checks run on a nightly schedule to catch drift.

Next.js
TypeScript
Node.js
PostgreSQL
Meilisearch
Tailwind CSS
GitHub Actions

E-Commerce

Concept build

Meridian Retail Commerce Platform

Illustrative concept for a headless storefront serving a retailer with physical branches alongside online sales. The design targets catalogue-heavy retail where stock availability, click-and-collect, and consistent pricing across channels matter more than novelty features.

The challenge: Retailers that sell in store and online frequently run two stock truths, so customers order items that are not actually available at the chosen branch. Pricing and promotion rules also diverge between channels, which creates disputes at the counter and erodes trust in the online catalogue.
Proposed approach: The storefront is a Next.js application rendering catalogue pages statically and personalising only the cart and availability views, which keeps browsing fast under load. Commerce primitives — products, variants, price lists, promotions — come from a headless commerce backend, while a single inventory service acts as the source of truth for both the storefront and branch systems. Payment is delegated to a PCI-compliant provider using hosted fields, so no card data touches our servers, and checkout is designed as a short, resumable flow. Click-and-collect availability is resolved per branch at request time and degrades to a pickup estimate when the branch feed is unavailable rather than failing the page.

Next.js
TypeScript
Stripe
Redis
PostgreSQL
Tailwind CSS
Algolia

Point-of-sale terminal representing a wholesale ordering workflow

Concept build

Harborlight B2B Supply Portal

Concept build — a business-to-business ordering portal for a distributor, with account-specific price lists, bulk ordering, and approval routing. It suits wholesale operations still taking orders by email and spreadsheet.

The challenge: Wholesale ordering over email forces sales staff to re-key quantities, check credit status by hand, and reconcile pricing exceptions from memory. Customers cannot see what they paid last time or whether an item is in stock, so every order becomes a short negotiation.
Proposed approach: The portal separates identity from commerce: a customer account carries contracts, price lists, and credit terms, and orders are validated against those rules before submission. A fast bulk-order grid accepts pasted SKU and quantity lists, resolves them against the live catalogue, and reports unmatched lines rather than silently dropping them. Orders above a threshold enter an approval queue with an audit trail of who changed what. The backend exposes the same order API to the internal sales team and to the customer portal, so there is one set of business rules, and ERP synchronisation runs as an idempotent background job with retry and dead-letter handling.

Next.js
TypeScript
NestJS
PostgreSQL
Redis
Docker
AWS

Laptop showing marketplace sales analytics and seller performance charts

Concept build

Verdant Goods Marketplace

Illustrative concept demonstrating a multi-vendor marketplace where independent sellers list produce and pantry goods under one storefront. The design targets operators who need seller onboarding, split payments, and dispute handling rather than a single-merchant cart.

The challenge: Marketplaces carry risk that single-merchant stores do not: sellers supply inconsistent product data, commission must be split correctly at payment time, and refunds or disputes can involve three parties. Poor tooling here turns a commercial disagreement into an operational crisis.
Proposed approach: The catalogue applies per-seller schemas and validation on submission, so inconsistent attributes are rejected before they reach buyers. Payments are handled through a provider that supports connected accounts, with commission calculated at capture and payouts scheduled on a rolling basis rather than held manually. Each order line records its seller, fulfilment status, and commission, which makes partial refunds and disputes tractable. Search is delegated to a hosted index with faceting across category, seller, and dietary attributes. An admin console exposes seller health signals such as late dispatch and cancellation patterns so the operator can act before buyers complain.

Next.js
TypeScript
Stripe Connect
PostgreSQL
Algolia
Redis
Terraform

Business Applications

Laptop displaying a scheduling dashboard with appointment and capacity views

Concept build

ClinicFlow Appointment System

Concept build — an internal scheduling and patient-flow application for a multi-practitioner clinic, covering diary management, room allocation, reminders, and front-desk check-in. It would suit clinics replacing a paper diary or a calendar tool never designed for clinical scheduling.

The challenge: Clinical diaries involve constraints a generic calendar cannot express: room availability, equipment, practitioner specialisms, and appointment types of different lengths. When those are tracked separately, double bookings and idle rooms become routine, and reminder messages are sent by hand.
Proposed approach: Availability is computed by a scheduling service that treats practitioner time, room capacity, and appointment type duration as explicit constraints, returning candidate slots rather than accepting whatever is dragged onto a grid. The database uses exclusion constraints to make overlapping bookings impossible even under concurrent requests. Reminders are queued as background jobs with per-channel templates and delivery tracking, so a failed message is visible instead of silently lost. Front-desk check-in is a lightweight, keyboard-first screen built for speed under pressure, and every change to an appointment is written to an append-only audit log. Access is role-based, with practitioners seeing their own schedules and administrators seeing the whole site.

React
TypeScript
NestJS
PostgreSQL
Prisma
Redis
Docker

Field engineer reviewing job details on a laptop alongside equipment

Concept build

Ledgerline Field Operations Suite

Illustrative concept demonstrating an offline-capable field operations application for technicians and surveyors, with job dispatch, photo evidence, and parts tracking. It targets organisations whose staff work in places with unreliable connectivity.

The challenge: Field teams lose hours when a job sheet lives in an office system they cannot reach on site. Work is recorded on paper, re-entered later, and photographic evidence ends up in personal camera rolls, which makes job history incomplete exactly when a dispute or compliance review needs it.
Proposed approach: The mobile client is an offline-first application built on a local database that queues mutations and reconciles them when connectivity returns, using per-record versioning and a last-writer-wins-with-conflict-flag policy rather than silent overwrites. Job dispatch assigns work by area, skill, and current load, and technicians see today's route with the parts expected for each job. Photographs and signatures are captured against the job record, compressed on device, and uploaded directly to object storage using pre-signed URLs so the application server never proxies large files. The office console shows job status, parts consumption, and exceptions in near real time, and an integration layer pushes completed jobs to the finance system.

React Native
TypeScript
SQLite
NestJS
PostgreSQL
AWS S3
Terraform

AI & Automation

Circuit board detail representing an intelligent document processing pipeline

Concept build

Atlas Document Intake Automation

Concept build — an assisted document intake pipeline that extracts structured fields from invoices, forms, and correspondence and routes them for human confirmation. It suits back-office teams processing high volumes of semi-standard paperwork.

The challenge: Documents arrive as scans, email attachments, and photographs in inconsistent layouts. Staff copy fields into line-of-business systems, which is slow, error-prone, and impossible to audit when a value is later disputed.
Proposed approach: Incoming files land in object storage and are normalised, split, and classified by type before extraction. Extraction combines a document model for layout-aware reading with deterministic parsers and validation rules for fields such as totals, tax identifiers, and dates, and every extracted value carries a confidence score and its source region. Items below threshold are queued to a review interface that shows the document beside the parsed fields, so a person confirms rather than retypes. Confirmed records are written through an idempotent integration with duplicate detection, and each decision is logged with the model version and reviewer. The pipeline is designed so the model layer is replaceable without touching the validation or routing logic.

Python
FastAPI
OpenAI API
PostgreSQL
Celery
AWS S3
Docker

Support team reviewing assistant answers and cited sources at a shared desk

Concept build

Sentinel Support Assistant

Illustrative concept demonstrating a retrieval-grounded assistant over a company's own help centre, policies, and past tickets. It is intended for support teams that answer the same questions repeatedly and need answers traceable to a source document.

The challenge: Support knowledge is spread across a help centre, internal wikis, and closed ticket threads, so agents search three systems and still answer from memory. A general-purpose chatbot makes this worse by producing confident answers with no citation, which is unacceptable for policy or contractual questions.
Proposed approach: Documents are chunked with layout awareness, embedded, and stored in a vector index alongside metadata that carries access permissions, so retrieval respects the same role boundaries as the source systems. At question time the assistant retrieves candidate passages, reranks them, and answers only from that context, returning inline citations and an explicit 'not found' response when coverage is weak instead of guessing. Ticket drafting suggestions are generated only after the agent has selected the relevant articles. An evaluation harness replays a labelled question set on every prompt or model change to catch retrieval regressions before release, and all prompts, retrieved passages, and responses are logged for review.

TypeScript
Next.js
pgvector
PostgreSQL
OpenAI API
Redis
Vercel

Cloud & DevOps

Engineers reviewing infrastructure status inside a data centre aisle

Concept build

Bastion Cloud Landing Zone

Concept build — a reference landing zone for organisations moving their first production workloads into a public cloud account structure. It fits teams that need guardrails, networking, and delivery pipelines defined before application teams start deploying.

The challenge: Cloud adoption commonly starts with a single shared account, shared credentials, and manual console changes. Cost ownership becomes unclear, production and test drift, and a routine mistake can affect unrelated systems because nothing separates them.
Proposed approach: The account structure separates environments and business domains, with centralised logging, a security tooling account, and service control policies that restrict regions and risky services at the organisation level. Networking is defined in code: hub-and-spoke connectivity, private subnets for workloads, and egress through inspected routes rather than open internet paths. Terraform modules with remote state and peer-reviewed plans provide the provisioning path, and CI/CD runs plan on pull request and apply on merge with manual approval for production. Baseline controls cover encryption by default, secret storage in a managed vault, and alerting on configuration drift, while tagging standards make cost allocation reportable from the first day rather than retrofitted later.

AWS
Terraform
GitHub Actions
Docker
Kubernetes
Prometheus
Grafana

Engineers working beside server racks maintaining a container platform

Concept build

Lumen Delivery Pipeline Modernisation

Illustrative concept for modernising a manual release process into an automated delivery pipeline for a containerised application estate, including environment promotion, progressive rollout, and rollback. It suits teams releasing infrequently because every deployment is an event.

The challenge: When releases depend on checklists, tribal knowledge, and weekend windows, they happen rarely. Infrequent releases mean large change sets, which raise the chance of failure, and the absence of a fast rollback path turns a small defect into an outage.
Proposed approach: Application services are containerised with reproducible multi-stage builds, immutable image tags, and a registry policy that blocks deployment of unscanned images. The pipeline runs unit and integration tests, static analysis, dependency and image scanning, then promotes the same artefact through staging to production so environments cannot diverge. Deployment uses progressive delivery — a canary slice with automated health and error-rate analysis — and rolls back automatically when the analysis fails. Configuration is externalised and validated at start-up so misconfiguration surfaces before traffic arrives. Observability is treated as part of the deliverable: structured logs, RED metrics per service, distributed tracing across calls, and dashboards and alerts defined in code alongside the services they describe.

Kubernetes
Docker
GitLab CI
Helm
Prometheus
Grafana
OpenTelemetry

Concept builds are illustrative and created to demonstrate solution categories and technical approach. Names are fictional. We do not publish client work, results, or testimonials without the client's permission.

Start the conversation

Have a system like one of these in mind?

Tell us what you need it to do. We will walk you through the architecture we would recommend and the trade-offs involved, before you commit to anything.

Discuss Your Project See engagement models

No obligation and no pressure
Reply within one business day
Clients worldwide