We’re recruiting a small cohort of platform engineering teams to take Liquid Compute from a working proof-of-concept to production. Your workloads. Your pain points. Direct line to the engineering team building what comes after Kubernetes.
AI coding is detonating service counts. Containers are 13 years old. The tools that worked for a dozen services don’t work for a hundred. Liquid Compute makes services flow across nodes, regions, and providers at runtime — no redeploys, no downtime, no team coordination. We’re looking for a handful of teams to prove that out alongside us.
Platform engineering teams running Java/Spring services at scale, where at least one of the following is unmistakably true:
Cloud spend is a board-level concern. You suspect significant overprovisioning across your service fleet and quarterly cost reviews aren’t closing the gap.
Service placement is a recurring headache. Rebalancing means redeployment, coordination, and downtime risk — so it doesn’t happen often enough.
Multi-cloud or data residency. Deployment complexity from regulatory boundaries or provider diversity is outgrowing manual processes.
Call graphs are non-trivial. Static placement leads to hotspots, chatty cross-AZ traffic, and wasted bandwidth that static autoscaling can’t resolve.
You’re shipping services faster. AI-assisted development is multiplying service count and your ops tooling can’t keep up with the granularity.
Java and Spring at scale. A meaningful share of your service estate runs on the JVM — the surface where @Liquid annotations make a service instantly portable.
Design partnerships work when the value flows both ways. We’re explicit about what we ask and what we deliver — no surprises on either side.
Business phases describe what we ship and sell. Technical milestones describe what the brain learns to do. Design partners influence the order and the depth at every step.
For partners: Run Liquid Compute in production with confidence that it handles failure and scales automatically.
For partners: Placement value no human operator could achieve manually — automatic reduction of network overhead and tail latency.
For partners: Cloud spend drops automatically because the brain packs services tighter when it’s safe and spreads out when load demands it.
@Liquid interfaceFor partners: Legacy and polyglot services participate in a Liquid cluster without running Java. The brain controls routing for the entire service graph.
For partners: No more lock-in. Services flow across provider boundaries in real time, responding to outages, pricing changes, and data residency.
For partners: The brain becomes a runtime optimizer for the entire compute estate — HotSpot for the cloud.
If you’ve read this far, odds are one of those pain points hit close to home. Tell us about your platform, your stack, and the workload you’d run on a Liquid cluster. We respond personally within the week.