Strategy
meets code.

The problem

HomeCare Direct is a nurse-led home care provider working across England and Wales, including specialist neurological, mental health and autism care. Two nations means two regulators, CQC in England and CIW in Wales, and one website could not speak honestly to both. Referrals, job listings, team profiles, news and documents were handled through fragmented manual processes, and every content change had to wait for a developer.

What we built

We built two separate Next.js sites, homecaredirect.co.uk and homecaredirect.wales, each written to its own regulatory framework and sharing one Firebase back end and a thirteen-module content system. The team now publishes news with drafts and scheduling, manages professional referrals through multi-section validated forms, and edits page-level SEO and redirects without a deploy. Access control covers six staff roles and is enforced in the database rules rather than the interface, so the gate holds even when the browser is bypassed. Zoho CRM synchronisation captures incoming leads, a newsletter handles scheduling and open tracking, and audit logging and retention controls run throughout for GDPR.

The problem

A single-operator dog grooming business running on a paper diary and a phone. Appointments lived in a calendar, customer history lived in memory, and prices were worked out per visit. The sharpest problem was not administrative. A dog that needs a muzzle, or reacts badly to clippers, is a safety matter, and that information was not reliably in front of the groomer at the start of a visit.

What we built

We built a booking site and an operator portal on Next.js and Firebase. Customers book online against real availability. The portal runs the day, and every booking shows the live profile for that dog, its blade sizes and its behaviour flags, resolved from the customer record rather than a copy taken whenever the booking was made. Finishing a visit captures the price, the payment method and before and after photos in a single step. Behind that sit a credit ledger with a full audit trail, SMS and email reminders, photo-based quoting, and a nightly calendar sync that turns recurring appointments into real bookings so an upcoming visit is never invisible.

The problem

Pool leagues run on spreadsheets, group chats and one person who knows how the fixtures work. The existing league software is dated, priced for organisers rather than players, and gives a player almost nothing between match nights. We wanted to know what a league platform looks like when the player is the primary user, so we built one.

What we built

Chalk It Up is our own product and our proving ground. It is a multi-league platform with standings, player statistics and Monte Carlo simulations that project how a season is likely to finish, plus insight generation that turns those numbers into plain English. Captains manage rosters and score matches live. Venues run a standalone kiosk on a screen in the pub that feeds results straight back into the league. It ships as a web app and through the Play Store, with passkey and PIN sign-in designed for someone using a shared venue tablet rather than a personal laptop.

The problem

Puck-Luck is a daily one-flick physics game with a real audience and a product that had grown fast. It was live and taking players, and needed two things at once: a route onto the Play Store, and an honest read on what would break as it scaled.

What we built

We shipped an Android app built as a native shell around the live site, so the game stays one codebase and every web release reaches the app the same day. Alongside it we added rewarded video as an alternative to the in-game retake, and gated the paid league behind platform billing rules so the store listing stays compliant. We then audited the product across accessibility, performance, search, observability, moderation, scale and cost, and delivered each finding as a prioritised plan the client can hand to any developer. A player reporting and moderation system with an administrator review queue followed, along with the operator and privacy disclosures the store requires.

The problem

Our own site was built on a no-code platform and served 68 visible characters of HTML on every page. Everything a person saw was assembled afterwards in the browser. To a visitor it looked finished. To a search crawler, and to any AI assistant asked to recommend someone in our field, it was a blank page. We were selling AI search optimisation from a site that could not be read.

What we built

We rebuilt it on Next.js and Firebase, server-rendered, and then audited it five times over with an independent reviewer until the findings stopped being serious. The audits are the interesting part. They found an import that had silently dropped a bulleted list from every article, an editor that would have deleted those lists the first time anyone pressed Save, database rules that exposed unpublished drafts to anyone holding the public key, and content that was server-rendered and then hidden with CSS, which is the entire point of the exercise undone in one line. Every one of those was invisible to a code review and obvious the moment somebody fetched the deployed page and read it. That is the standard we now hold client work to.