How we've solved real problems for real clients

The Problem

Northbound Travel, a boutique tour operator, had a booking flow spread across three separate pages built on an old CMS template. Analytics showed nearly 40% of users abandoned between the itinerary page and payment, and the support team was fielding daily emails from confused customers.

Research

We ran a short round of user testing with five recent customers and reviewed session recordings from the past quarter. Two problems stood out: the price shown on the itinerary page didn't match the final total after fees were added, and the payment form reloaded the page on validation errors, losing entered data.

The Solution

We redesigned the flow as a single-page checkout with three visible steps, live price calculation (including all fees, shown upfront), and client-side validation that never triggers a full page reload. The itinerary, traveler details, and payment now live in one component-driven page.

Architecture

The frontend was rebuilt in vanilla JavaScript with a small state management layer; the backend price-calculation logic was moved from the CMS template layer into a dedicated API endpoint so the displayed price and the charged price could never drift apart again.

Challenges

The biggest constraint was zero downtime — Northbound takes bookings around the clock. We shipped the new flow behind a feature flag, routed 10% of traffic to it for two weeks, and compared conversion before rolling out to everyone.

Outcome & Metrics

Six weeks after full rollout, checkout abandonment fell from 40% to 26%, support tickets related to pricing confusion dropped by roughly 70%, and average time-to-complete-booking fell from 6.5 minutes to just under 4.

The Problem

Ledger Loop's finance team was reconciling transactions across four separate spreadsheets, manually copying data between them every morning. Errors were common, and reconciliation took roughly two hours a day across two people.

Research

We shadowed the reconciliation process for two full days to understand exactly which fields mattered, where discrepancies typically showed up, and which edge cases the spreadsheets were quietly handling that a new system would need to cover.

The Solution

We built a single dashboard that pulls transaction data from their payment processor and bank feed automatically, flags mismatches, and lets the team resolve discrepancies inline instead of hunting across four files.

Implementation

Data syncing runs on a scheduled edge function every 15 minutes; the dashboard itself was built with a lightweight component structure on top of Supabase, so the finance team could add custom views themselves without engineering involvement.

Challenges

The payment processor's API had inconsistent field naming across transaction types, which required a normalization layer before matching logic could run reliably.

Outcome & Metrics

Daily reconciliation time dropped from roughly two hours to under twenty minutes, and the team caught two real discrepancies in the first month that had gone unnoticed in the old spreadsheet process for over a quarter.