Industries

We build web platforms, apps and content systems for healthcare, fintech, edtech, SaaS, ecommerce and media companies. The code is mostly the same; what changes by industry is the set of rules around it, and those rules decide the architecture, the review steps and what we test before launch.

This page explains what is specific about each sector we work in, shows one project per industry, and covers how compliance scope, accessibility, approvals and data handling change the work.

Which industries do we work in?

We list only the industries where we have shipped work you can read about. Each project links to an anonymized case study with the figures from that engagement.

Outside these six, we have shipped work for logistics, marketplaces, manufacturing, energy and a public-sector services portal. The full list is on our case studies page.

What is specific about building for each industry?

Healthcare

Most healthcare software has two halves: content that patients and providers read, and systems that hold patient records. We keep them apart. A marketing site or provider directory should never store protected health information, so it can run on a normal headless CMS without pulling the CMS into HIPAA scope. Clinical tools are different: they need access control, logging and display rules, because clinicians act on what they see. See healthcare software development for the product side and headless CMS for healthcare for content teams.

For a European enterprise healthtech organization, we moved more than 1,200 content nodes in four languages off Drupal 7. LCP dropped from 4.3s to 1.5s and editor publish time fell by roughly half, with zero SEO ranking regressions at cutover.

Fintech

In fintech, every public sentence about rates, fees or risk goes through legal review. The content system has to model that review, not work around it. Product systems add audit trails, payment data scope under PCI DSS, and anti-fraud checks. Our fintech software development page covers the product work.

For a US-based Series-B fintech, draft, legal review and published states in Payload mapped to the client’s sign-off process. Time to publish dropped by about 65% and LCP went from 4.2s to 1.4s.

Edtech

Edtech products are bought by institutions and used by learners and teachers who did not choose them. That means LMS integrations through standards like LTI 1.3, rostering from student information systems, accessibility targets set by public buyers, and student privacy rules such as FERPA and COPPA in the US. Our edtech development page goes through each.

SaaS

SaaS work is about the platform under the product: multi-tenancy, roles and permissions, billing, and the path from MVP to scale. For a European growth-stage B2B SaaS, our multi-tenant rebuild cut tenant provisioning time by about 97% and per-tenant support tickets by about 40%. Our SaaS development page covers architecture, billing and auth.

Ecommerce and media

Ecommerce and publishing have the same pressure: speed on pages that earn money, and no lost rankings when the platform changes. For a US-based enterprise digital media publisher, we moved off legacy WordPress to a headless CMS. LCP on article pages fell from 4.2s to 1.5s and no organic ranking positions were lost at cutover.

How do industry constraints change the work?

In our projects, regulations rarely change the tools we pick. They change what we document, who approves what, and which data goes where. Four areas move the most.

Compliance scope

We start by drawing the boundary: which systems handle regulated data and which do not. The smaller that boundary, the less of your stack your auditor has to review. A CMS that serves public content stays outside it. A patient portal or payment flow sits inside it, with encryption, access logs and a vendor list your counsel can check. We do not certify anything. We build so that your certification is easier.

Accessibility

Public buyers, universities and large retailers often ask for WCAG 2.2 AA conformance and an accessibility conformance report before they sign. We design and test to that level from the first sprint, because fixing it later costs more. Our web accessibility services page explains how we audit and fix existing products.

Approvals

Healthcare has medical review, fintech has legal review, edtech often has curriculum or district review. We put these steps into the CMS or the product as named workflow states with roles, so nothing reaches production without the right sign-off, and the history of who approved what is kept.

Data handling

Where data lives, how long it is kept and who can export it differ by sector and by country. We decide hosting region, retention and logging with you before the build, and we keep analytics free of personal data unless you need it and have a basis for it. For a European client, that usually means EU hosting and a data processing agreement with each vendor that touches personal data. For a US healthcare client, it means a business associate agreement wherever protected health information flows.

How we staff industry projects

Most projects start with a short audit or a discovery phase, then move to a fixed-scope build or an ongoing team. If you already know the scope and need people, you can hire a dedicated team that works inside your process and your compliance rules. Senior engineers scope the work and stay on it, so the constraints found in discovery are still in the code at launch.

Tell us your industry, what the product does and which rules apply. We will come back with the questions a first audit needs to answer.