Engineering

We build software that has to keep working.

Web and mobile products, e-commerce platforms, and the integrations underneath them. Some of it starts with an empty repository. Some of it starts with a system that already carries real users. Either way it ends up in production, where a bad release is visible the same day.

What we build

Where it gets hard

Four situations we get called into more than any others. Two arrive before a line of code exists; two arrive with a system already carrying real users.

When you’re starting from nothing

Shipping where compliance is a design constraint

  • Native iOS
  • ResearchKit
  • Medable
  • HIPAA

For the University of Michigan’s clinical pharmacy department, HIPAA shaped data handling, storage, user flows and access control from the first sprint, not from a review at the end. The app measures gait, balance and finger coordination in patients on chemotherapy, and stays accessible while it does it.

Read the case
The Michigan app, turning gait, balance and coordination measurements into something a clinician can read

When you’re starting from nothing

Launching in several markets at once

  • React Native
  • VTEX
  • Node.js
  • Five markets

3M+

app downloads in the two years after a launch that took five months. One direct-to-consumer platform that opens country by country, with real-time sync of inventory, pricing, promotions and orders.

Read the case
TaDa Delivery, AB InBev’s direct-to-consumer platform

When it’s already running

Migrating a store that can’t go down

  • Adobe Commerce
  • Magento 1.9 → 2
  • React
  • Live migration

3.5%

conversion, up from 1.2% immediately after go-live, with support tickets down 40%. Migrated live from Magento 1.9 to Adobe Commerce Cloud, then years of evolving it.

Read the case
Lentesplus, vision care across Latin American markets

When it’s already running

Taking over a build that didn’t work

  • Magento 2
  • Checkout
  • Takeover

33%

better conversion in 2020 versus 2019. KURU had migrated to Magento 2 with someone else and lived with severe site issues for two years. We took the platform over and fixed checkout before anything else.

Read the case
KURU Footwear’s Magento 2 storefront

What changed, and how we know

Each of these says what it was measured against, and when.

3.5%
conversion rate, up from 1.2%
Lentesplus, after the migration to Adobe Commerce Cloud went live.
How we know Same store, measured before and immediately after go-live.
40%
fewer support tickets
Same platform. Customers could complete purchases and manage orders without calling anyone.
How we know Tickets received by the customer service centre, before and after.
3M+
app downloads
TaDa Delivery for AB InBev, across multiple Latin American markets.
How we know Counted in the two years following a launch that took five months.

What we work in

What happens when we leave

The work is finished when your team can run it without us. Sometimes that means handing it over; sometimes it means staying, because you asked us to.

The platforms we’re certified on

A partnership means the vendor has checked our work, that we build on their platform with their tooling, and that we have a direct line when the thing that’s broken is their product and not our build.

See all partners

Questions we get before the first call

  1. What do you build in?

    Backend on .NET, Node.js and Python. Web and mobile on React, React Native, Angular and native iOS. Azure and AWS underneath. PostgreSQL, SQL Server and GraphQL for data. Adobe Commerce, Magento 2 and VTEX for commerce. .NET and React carry most of our enterprise work, and React Native is what we reach for when one product has to ship on both phones. This is what we work in regularly, not everything anyone here has ever touched.
  2. Do you work in our stack, or do you bring your own?

    Yours, when it’s mature and your team knows it. We don’t propose replacing a stack to suit how we’d rather build. That costs you a migration and buys you nothing. Where we do push back is when the stack can’t carry what you’re asking it to do, and we say that before the contract rather than during it.
  3. Which cloud do you build on?

    Both, and the choice is usually already made by the time we arrive. Azure is where most of our .NET work is deployed: App Services, Azure SQL, Storage and Data Factory, plus the AI services for document extraction and conversational interfaces. On AWS we work with Lambda, SNS, SQS and the usual managed pieces. We don’t have a preference we’ll try to sell you.
  4. Can you take over a codebase somebody else wrote?

    Yes, and it’s a regular way projects start here. KURU is the published example: they had migrated to Magento 2 with another team and lived with severe site issues for two years. We took the platform over and fixed checkout before anything else, and conversion improved 33% the following year. Before we take one over we read it first: what it does, what it touches, and what breaks if it stops.
  5. Do you do QA and DevOps?

    Testing and release engineering are part of every project we deliver, not a separate line item. What we don’t sell is a standalone QA practice the way some firms do. If that’s what you’re looking for, we’ll say so early.

Bring us the hard part.

Whether that’s a product that doesn’t exist yet or a system you’re afraid to touch, in a 45-minute working session we’ll tell you what we’d do first, what we’d leave alone, and roughly what it would take. Bring the project; we’ll bring the questions.