Why we made it
Most "edge" platforms start with a globe map and a region picker. You pick which regions you want, and your app runs there. The thinking is reasonable — until you realise you're now responsible for: which regions, when to add more, how to keep data consistent across them, and what to do when one goes down at 2am.
We wanted a runtime that handled all of that automatically. Deploy a function — it runs at every PoP we operate. Read a KV key — it comes from the nearest PoP. Write an object — it replicates everywhere. The unit of work is the function, not the deployment region.
That sounds obvious in retrospect. It wasn't until we tried building it.
Who we built it for
Teams shipping things to humans, where 200 ms of latency is the difference between people using the product and people not noticing it. SaaS APIs. Mobile backends. Real-time tools. Anywhere "fast enough from one US East server" turns into "slow enough that we lose customers in APAC."
We don't try to be Lambda. Lambda gives you a function and a way to wire any AWS service to it. We give you a function, KV, and object storage — that's the surface. If you need EventBridge and SQS and DynamoDB Streams, you'll be happier on Lambda. If the three primitives are enough, compute-edge deploy is the entire deploy story.
How we run it
We are two people. We are bootstrapped. We have no investors, so we have no obligation to grow at any particular speed. We do customer-funded work, and the company grows from the surplus of running it well.
What that means in practice: you can email us and a human reads it. Pricing won't quietly increase because someone needs to hit a revenue target this quarter. We won't pivot to a different product because the existing one isn't growing 3x year-over-year. The product gets better, the surface stays small.