Skip to content
Tekansa
Case studies

Selected work. Systems that shipped, and held.

Real platforms for real operators, with the numbers, the trade-offs, and the parts we would do differently the second time.

See the workTalk to Tekansa
Case studies
4
Sectors
4
Months delivered
40
In tech since
2012
Results at a glance
The work

Every study: the problem, the build, the numbers.

Filter by sector. Each row gives you the short version; the full study has the detail, the trade-offs and the questions clients asked afterwards.

  • A unified EMR for a multi-site hospital network
    Healthcare2025 · 9-month engagement
    Client
    Northline Health
    A multi-site hospital network with 14 hospitals and ~12,000 staff

    A unified EMR for a multi-site hospital network

    Fourteen hospitals, four legacy EMRs, one clinical spine. 4.2M patient records migrated with zero downtime, and clinicians got hours back per shift.

    1. 1. The challenge

      Northline had grown by acquisition. Fourteen hospitals inherited four different EMRs, three billing systems and a patchwork of manual reconciliations between them.

    2. 2. The approach

      We built a FHIR-native clinical platform on Next.js and Postgres (the same technology stack Northline's own team could maintain) with Kubernetes for the deployment envelope and a hardened event bus for the write path.

    3. 3. The outcome

      The whole network runs on one record now. Clinicians see the full patient history in a single view, orders route to the right department without a phone call, and billing closes in hours instead of weeks.

    Patient records migrated
    4.2M
    Documentation time reclaimed
    42%
    Downtime during cutover
    0 min
    • Next.js
    • TypeScript
    • Postgres
    • FHIR
    • Kubernetes
    Read the full study: A unified EMR for a multi-site hospital network
  • Ledger and treasury for a mid-market lender
    Fintech2025 · 11-month engagement
    Client
    Meridian Capital
    A mid-market specialty lender with $4.8B AUM

    Ledger and treasury for a mid-market lender

    Ledger, treasury and risk rebuilt end-to-end. Reconciliation used to take three days; it now closes before the analysts arrive.

    1. 1. The challenge

      Meridian's book was spread across eight systems: a core banking platform for lending, a bolt-on treasury tool, a spreadsheet for FX exposure, and five downstream reports that never agreed with each other.

    2. 2. The approach

      We built an event-sourced ledger in Go with Kafka as the transport, Postgres as the read-side, and a compliance-grade audit log baked in from the first commit.

    3. 3. The outcome

      Reconciliation runs unattended and closes before the analysts arrive. Risk exposure is visible in real time.

    Legacy systems retired
    8 → 1
    Reconciliation cycle
    3d → mins
    Manual adjustments in 2025
    0
    • Go
    • Kafka
    • Postgres
    • AWS
    • Terraform
    Read the full study: Ledger and treasury for a mid-market lender
  • A retailing platform for a global tour operator
    Travel2024 · 8-month engagement
    Client
    Voya Travel Group
    A global tour operator across 8 markets, 2.1M annual bookings

    A retailing platform for a global tour operator

    Mobile-first commerce spine shipped in time for peak season, and held. Booking latency dropped from 4.2s to under a second and conversion jumped 34%.

    1. 1. The challenge

      Voya's peak season traffic runs twelve times its baseline. Mobile was where most of their new customers landed, and their mobile conversion rate had been stuck under 1.4% for two years.

    2. 2. The approach

      We rebuilt the mobile app in React Native on top of a single GraphQL commerce layer, so search, price and checkout finally spoke the same language.

    3. 3. The outcome

      Mobile conversion is up 34% and holding. Peak season came and went without a single incident escalated past on-call.

    Mobile conversion
    +34%
    Booking latency
    4.2s → 0.9s
    Peak traffic held
    12× baseline
    • React Native
    • GraphQL
    • Node.js
    • Redis
    • GCP
    Read the full study: A retailing platform for a global tour operator
  • Omnichannel commerce for a national retail chain
    Retail2024 · 12-month engagement
    Client
    Riverbend Retail
    A national retail chain with 340 stores, 3 e-commerce brands

    Omnichannel commerce for a national retail chain

    One catalog, one cart, one identity, across 340 stores, 14 warehouses and three brands that had never spoken to each other before.

    1. 1. The challenge

      Riverbend had grown into three e-commerce brands, 340 physical stores and 14 warehouses, and none of them saw the same version of the truth.

    2. 2. The approach

      We built one catalog on an Elasticsearch-backed product graph, one identity service that reconciled the three legacy customer databases, and one cart that could span brands and channels without losing state.

    3. 3. The outcome

      Every channel now sees the same customer, the same catalog and the same inventory. In-store fulfillment of online orders started shipping in month eight, three months ahead of the board's deadline.

    Stores unified
    340
    Repeat-purchase rate
    +23%
    Brands, one checkout
    3 → 1
    • Next.js
    • Node.js
    • MongoDB
    • Elasticsearch
    • Azure
    Read the full study: Omnichannel commerce for a national retail chain
What they have in common

Different sectors. The same three habits.

Read the studies side by side and the same delivery decisions keep showing up. They are why these systems are still running.

  • Old and new run side by side

    The new system runs in parallel with the old one, reconciled record by record, before anything is switched over. The cutover becomes a routing change rather than a leap.

    Seen in

  • Staged rollout, never a big bang

    Hospital by hospital, journey by journey, store wave by store wave. Every step small enough to roll back, so problems surface at a scale a team can absorb.

    Seen in

  • The client owns it afterwards

    Code, infrastructure and runbooks are handed over, and the client's own team ships on the platform without us. Built to be extended, not just operated.

    Seen in
Questions clients ask

What people want to know after reading a study.

One question from each study. Open it for the answer; the study page has the rest.

Northline Health
How do you migrate millions of patient records without downtime?

By running both systems in parallel rather than switching between them. The new platform is populated and kept in sync with the legacy EMR for weeks before anyone uses it, and every record is reconciled against the source until the counts and checksums match exactly. The cutover itself is then a routing change, which is why it took no clinical downtime. The rollback plan stayed live for a month afterwards.

Read the healthcare study →
Meridian Capital
How do you replace a ledger without losing a single transaction?

You do not replace it in one move. The new ledger runs in parallel against live traffic, and every balance is reconciled against the incumbent daily until the two agree to the cent for an unbroken stretch. Only then does the old system stop being authoritative. The reconciliation harness is built before any migration code, because without it you are migrating on faith.

Read the fintech study →
Voya Travel Group
How do you handle peak-season traffic without over-provisioning all year?

By load-testing against your real historic peak rather than a generic curve, then designing what degrades first when the ceiling is hit. Search can get slower before booking does; booking must not fail. Autoscaling covers the rest. The platform held twelve times baseline because that number came from the client's own worst week, not from a round figure.

Read the travel study →
Riverbend Retail
What does unifying 340 stores actually involve?

Mostly reconciling what each store believes to be true. Stock, pricing and customer records had drifted apart across locations and brands, so the work is less about connecting systems than about deciding which system owns which fact, then making every other one defer to it. The integration is the easy half.

Read the retail study →
How these are written

The same four parts, every time.

Each study follows one structure so they can be compared rather than admired. Where a number appears, it is the one the client measured, not a figure we modelled. That is 12 measured results across 4 studies.

A note on names. Client names in these studies are anonymised at the client's request. The systems, the engineering and the numbers are as delivered. Named references are available on request once a conversation is underway.

The challenge
What was actually broken, in the operator's words, including the constraints that ruled options out.
The approach
How it was engineered, the trade-offs taken, and what we chose not to build.
The outcome
What changed for the people using it, and what we would do differently a second time.
Three metrics
Concrete numbers the client tracks, not vanity figures assembled for a slide.
Have a system in mind?

Bring us the hard part.

A short call is enough to tell whether your problem looks like one of these, and what the first month would involve.

Talk to Tekansa