What the first partner gets.

We have opened the partner program. The first team to join is going to get something no later partner will: the ability to shape what the program is.

Early partnerships are a two-way deal. You get something cheaper, faster, or more customized than a later customer ever will. In exchange, you bend your product around a platform that has not finished setting yet, and you are patient when it does not.

Here is the specific deal.

**What you get.** The same platform the portfolio runs on — compute, storage, databases, CI/CD, observability, 24×7 on-call. Direct engineering partnership: the person who owns the platform is the person who works with you. Early pricing, shaped together. A named point of contact who picks up the phone, not a ticket queue.

**What we get.** A real production workload running on our stack, in a domain we have not yet stress-tested from the outside. Feedback loops that cannot be faked by internal use. Reference customer status if things go well.

**What you give up.** Some amount of control. Platform updates ship regularly. You are part of testing them. You will be informed; you will not block us. In exchange, you get a direct line to change the roadmap if you see something we do not.

**What we give up.** Fast iteration on platform shape. The first partner anchors decisions. We know this. We accept it because the alternative — iterating in isolation — produces a worse platform.

The math is simple. Every real workload on the stack exposes assumptions that internal use alone will not. The first partner is the outside signal.

If you are thinking about it, the questions to ask are: Do you have a real production workload you can move? Do you want to trade a little control for a lot of access? And are you comfortable being the first reference for a company that has not published one yet?

If the answers are yes — apply.