An EDI partner's certification queue, a tax rule nobody raised, fifteen years of duplicate records. Three of these four slipped, and none of them slipped because of engineering difficulty.
Our Work
Four engagement profiles, including the parts that went badly.
A case study with no friction in it is marketing. Each profile below names what was hard — the integration that ran three weeks late, the migration nobody sized properly, the feature we built that the client's team didn't use. Those are the parts that tell you how we behave when a project stops being easy.
Read this first
Client names are withheld under NDA — several clients treat the system we built as a competitive advantage. The delivery figures below are real: timelines, team sizes and what was built. We don't publish client revenue or conversion outcomes, because we can't evidence them here and an unverifiable number is worth less than none.
Reference calls are available at proposal stage. We ask the client each time rather than keeping a standing list — a reference who gets called once a quarter stops being a useful one.
Logistics · GCC · 3PL operator
Real-time shipment tracking across three countries
Dispatch ran on spreadsheets and phone calls. No live visibility, no customer-facing tracking, and no route to operating in a second country without doubling the office headcount. We built the driver app, the dispatch console and the customer portal — then stayed on to operate it.
11 wksconcept to first production release
Namedtechnical lead, scope through launch
3countries live at launch
2 wkssprint cadence, demo every cycle
What we built
- Flutter driver app with offline queue, barcode scanning and photo proof of delivery
- Dispatch console with live map, job allocation and an exception queue owned by a named person
- Customer portal and public tracking links that removed most inbound status calls
- Telematics ingestion deduplicated by device and timestamp, so tunnels don't create phantom journeys
- Two carrier API integrations plus a legacy EDI feed from the largest client
What was hard
The legacy EDI feed cost three weeks nobody had planned for. The trading partner's certification queue ran at their pace, not ours, and their test environment rejected messages for a reason their own support team took eleven days to identify. We had built against a mocked contract so the rest of the work continued — but the go-live date moved, and we told the client in week four rather than week ten.
Second problem: the first dispatch console design put too much on one screen. Dispatchers work on 1366×768 laptops in a warehouse office, not on the 27-inch monitor it was designed on. We rebuilt the main view in sprint five.
Healthcare · multi-site clinic group
Appointments and records across nine clinics
Nine sites, three different booking systems and a central team reconciling them by hand every morning. Patients calling one clinic couldn't be booked into another. The brief was a scheduling system; the actual problem was that no two sites defined "appointment type" the same way.
- Unified scheduling across sitesWith per-site resource rules, because a physiotherapy room and a GP room don't book the same way.
- Patient portalBooking, reminders, documents and results release governed by consent rules.
- FHIR integrationDemographics and appointments synchronised with the incumbent records system.
- Access logging on every record viewNot just edits — who looked, and when.
16 wksdiscovery to first site live
Phasedone clinic first, then eight more over ten weeks
What was hard
Data migration was quoted at one week and took four. Fifteen years of patient records across three systems, with duplicate patients created whenever someone was registered at a second clinic, two incompatible address formats and a "notes" field that in one system held clinical information and in another held billing comments.
We found it during discovery because we profiled a real extract rather than a sample — but we had still under-priced the deduplication work. We absorbed the difference on that engagement and changed how we price migration afterwards: it's now always a separate line item with its own estimate.
The second lesson was adoption. Reception staff at two sites kept using the old system for walk-ins because our booking flow took eleven clicks to their four. We rebuilt the walk-in path as a single screen before rolling out to the remaining sites.
What was hard
Tenant isolation had been implemented in application code only. Every query filtered by tenant because a developer remembered to add the clause — with no database-level backstop. We found two endpoints where the filter was missing. Neither had been exploited, both were one support ticket away from a customer seeing another customer's data.
Fixing it meant introducing PostgreSQL row-level security across 60+ tables while the product stayed live, which we did over five weeks in batches, with a shadow-comparison job checking that query results were identical before and after each batch.
We also told them not to do half of what they asked for. The brief included a rewrite in a different framework. The codebase didn't need it — it needed isolation, an audit trail and a billing entitlement fix. We said so, which reduced the engagement by roughly a third.
SaaS · B2B platform, 40+ tenants
Taking over a live SaaS product before its first enterprise deal
A profitable B2B platform with forty-odd paying tenants, built fast by a founding engineer who had since left. The trigger was a large prospect whose security review asked for SSO, audit export and evidence of tenant isolation — none of which existed.
- Two-week audit firstArchitecture, dependencies, test coverage, security exposure and deployment risk, before touching production.
- Row-level security across the schemaRolled out in batches with shadow comparison, product stayed live throughout.
- SAML SSO and audit exportThe two features that unblocked the enterprise deal.
- Billing entitlement layerMoved out of live provider calls into their own database, so a webhook delay stopped locking out paying customers.
2 wksaudit before any production change
0planned downtime during the isolation rollout
eCommerce · multi-brand retailer
Replatforming a store that was already earning
Three brands on an ageing platform with a shared warehouse, a shared ERP and separate storefronts. The revenue didn't pause for the migration, which is what made it the highest-risk work on this page.
Baseline before design
Full crawl, every indexed URL from Search Console, current rankings, current Core Web Vitals and a revenue baseline by channel. No design work started until this existed — without it, nobody can tell afterwards whether a drop was the migration or the season.
Catalogue reconciled row by row
Products, variants and customer records migrated to a staging store, then compared against source line by line rather than spot-checked. Eleven hundred products had variant data encoded in the SKU string rather than as real attributes.
ERP and 3PL integration rebuilt with idempotency
The previous integration created duplicate orders when a webhook retried — the operations team had a manual daily check for it. Idempotency keys plus an hourly reconciliation replaced the manual check entirely.
Redirects mapped individually, including retired products
Around 2,400 discontinued SKUs mapped to their nearest live equivalent or their parent collection. Dull, manual work over four days. The default plugin behaviour would have sent all of them to the homepage, which Google treats as a soft 404.
Eight weeks of monitoring after launch
Coverage, rankings and conversion rate were pulled every Monday and compared against the pre-migration baseline. Damage surfaced in week three rather than at cutover, which is why the monitoring window was contracted for eight weeks and not two.
What was hard
Tax turned into a technical emergency two weeks before launch. Selling into the UK, the EU and the GCC from one estate meant three VAT treatments and an IOSS question nobody had raised because it was a finance matter, not a development one. We integrated a tax engine rather than hand-coding rates, and the launch moved by nine days.
That one was our miss. Tax jurisdictions are now a standard discovery question on every eCommerce engagement we scope.
Across all four
What these engagements have in common
Read together, the four profiles say the same three things.
Twice, staff kept using the old system because ours took more clicks for the ninety-per-cent case. Both times we rebuilt the frequent path before rolling out further.
Every slippage above reached the client within a sprint of us knowing. Two-week demos exist so that bad news arrives with time left to act on it.
Questions
References, figures and what's missing
Why are client names not shown?
Most of our work sits inside an NDA, and several clients treat the system we built as a competitive advantage they'd rather not advertise. We publish named case studies only where the client has approved the specific wording, and we won't imply endorsement from a company that hasn't given it.
Can we speak to a reference client?
Yes, at proposal stage and for serious engagements. We ask the client first each time rather than keeping a standing list — a reference who's called once a quarter stops being a useful one. Expect us to match you to a reference in a comparable domain rather than whoever is easiest to reach.
Are the figures on this page real?
The delivery figures are — timelines, team sizes, sprint cadence and what was built. We deliberately don't publish client business outcomes such as revenue or conversion uplift, because those depend on decisions we didn't make and we can't evidence them here without the client's own data behind them.
Do you have work in our industry?
In healthcare, logistics and transport, almost certainly, and we'll describe comparable work on a first call. Outside those three, we'll tell you honestly whether we've done something similar or would be learning your domain — and we price that learning into discovery rather than absorbing it and running late.
What happens to projects that go wrong?
They surface at a sprint demo rather than at a deadline, because there's one every two weeks. When scope proves wrong we re-plan with the client and show the cost impact before continuing. Every profile on this page includes what was hard, because a case study with no friction in it is marketing rather than evidence.
Related pages
Get a Free Quote
Describe your version of one of these.
If any of the four sounded familiar, the conversation starts faster. An engineer replies within one business day — and will tell you which parts we think will be harder than they look.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732
- Reference calls available at proposal stage