Expertise
Cloud software that has to keep running
When a product has to ship on the cloud you already run and your own engineers are spoken for, it usually waits for headcount.
We build that application and its APIs on Azure, AWS, Google Cloud or Cloudflare, inside the identity, secrets and network boundary your security team already governs. Infrastructure is code from the first release, every pull request gets a preview environment, and the operations that must not half-complete run on Temporal.
The people who scope the work are the people who ship it, so your project never goes to a delivery team you haven't met. When the data platform is part of the job, we build that as well.
Azure
The cloud most of our enterprise work lands on, usually because the identity estate is already there. Entra ID is the reason an Azure decision is rarely just an Azure decision.
- Container Apps and App Service for the workloads that do not warrant Kubernetes
- Entra ID, managed identities and Key Vault, so nothing ships with a connection string in it
- Azure Databricks inside the same network boundary as the applications that read it
- Landing zones adopted where they exist, rather than a parallel estate nobody governs
AWS
Where the product teams we join tend to already be. The work is usually an application and its data path rather than a migration.
- ECS and Lambda chosen against the shape of the traffic, not the shape of the diagram
- RDS and Aurora with the failover actually exercised
- IAM designed around roles people hold, so access review is possible
- Databricks on AWS with storage credentials and external locations set up once, properly
Cloudflare
The edge in front of the rest. Workers, static assets and the routing that decides what a visitor waits for, which is where most perceived performance is actually decided.
- Workers for the request-time logic that should never reach an origin
- Static assets and caching rules set per route rather than globally
- Turnstile, WAF and rate limiting on anything that accepts input
- R2 where egress would otherwise dominate the bill
Delivery and environments
The pipeline is part of the product. A team that cannot ship on a Friday afternoon has an environment problem, and it will eventually become an architecture problem.
- Infrastructure as code, with the same definition running every environment
- Preview environments per pull request, seeded well enough to be worth opening
- Secrets held in the platform's own store, rotated on a schedule somebody owns
- Observability from the first release, so the first incident is not also the first dashboard
What we build
- Applications and APIs on the cloud you already run
- Databricks workspaces that sit inside that same boundary
- Durable workflows for the sequences that cannot half-complete
- Identity, secrets and environments you can hand to security
Accelerators doing the work.
When the product needs a governed mutation pipeline or an in-workspace app, these are already built.
Platform is how the applications your team builds on Databricks keep an audit trail. Every change those applications make, by a person or an AI agent, has to pass a policy before it happens and is recorded with who made it and why, so when someone asks who changed a record and on whose authority, the answer is a query.
Runway takes the manual steps out of releasing Databricks Apps, for data teams who can build one but can't ship one after another without somebody doing it by hand. Each pull request gets a preview your reviewers can open, an app that fails its evaluation can't be promoted, and you can see who owns every app in the workspace and what it costs.
How this is delivered
Product development
Full product delivery: multi-tenant architecture, operator consoles and the data layer under them. On Azure, AWS, Google Cloud or Cloudflare, and as a Databricks App where the product belongs next to the lakehouse.
FAQ
Questions we get asked
Which clouds do you work on?
We build on Azure, AWS, Google Cloud and Cloudflare, and Databricks is where we have chosen to go deepest. Temporal sits underneath the operations that must not fail.
Are you a cloud migration firm?
No. We will move a workload when the product requires it. The work we take is building the system that runs afterwards: the application, the API, the lakehouse, the agent. Platform delivery is at /services/platform.
Do you only work if we are on Databricks?
No. Plenty of the products we have shipped run on Azure or AWS without a lakehouse in the first release. When the data platform is the job, start at /databricks.
How can we help?
A technical conversation with a senior engineer about what has to run, and where.