Why we run Celebrari at the edge
Our product lives in the two worst network conditions on the consumer internet. That decided the infrastructure before we had a choice.
Celebrari runs on Cloudflare's network, close to wherever the guest is standing. The database is Neon Postgres, photos and voice notes live in R2, rate limits live in Redis. None of that is visible to anyone using the product, which is exactly the point.
Our product lives in the two worst places to be slow
A guest leaving a message is standing in a room, holding a drink, on venue wifi, sharing one access point with two hundred other people. They have about fifteen seconds of patience and a phone in one hand. Every extra second of loading is a person who puts the phone away and means to do it later.
The host has the sky on a projector in front of the entire room. If it stutters, the failure happens in public, to the one person who trusted us with their evening.
Those are the only two places our product lives, and they are the two hardest network conditions on the consumer internet. There was never a version of this where infrastructure was a background concern.
Performance is hospitality
We think about speed the way a venue thinks about a coat check. Nobody praises it. If it works, it is invisible. If it does not, the whole evening feels careless and people blame the host.
So we treat it as part of the service rather than as an engineering metric. A page that loads in half a second and a page that loads in three seconds contain identical text. They are not the same product.
Why we moved, not just where we moved to
The old stack was not broken. It was shaped and priced for a different kind of company: one with steady traffic, a subscription, and a customer who logs in on a weekday.
A wedding is the opposite of that. Two hundred people arrive within twenty minutes, spend an hour, and then the sky goes quiet for a month. Paying by the seat, by the region and by the idle month is a bad fit for a shape like that, and a bad fit eventually becomes a limit on what we can promise.
What running at the edge actually buys
The page is assembled near the guest rather than in one region on one continent. A guest in Belgrade and a guest in Toronto get the same page from a location that is close to each of them, without either of them waiting on a round trip across an ocean.
Nothing has to wake up. The burst of a live event does not hit a server that has to start first, which is the failure mode that would hurt most at exactly the wrong moment.
A pay-once product has to be cheap to run forever
This is the less romantic reason, and it matters just as much. There is no second payment. Moment is $12, once, and it has to cover serving that sky for as long as we promised it would exist.
That arithmetic is why the media window is printed in the price instead of hidden in the terms. It is also why we moved: a stack that bills by the seat and by the region quietly sets a limit on how many promises we can keep.
What nobody will ever tell us
No one is going to write in and say the sky felt fast. There is no feature to announce and nothing to put on a pricing page. The reward for getting this right is that it never comes up.
That is fine by us. Performance is not a feature we sell. It is the floor everything else stands on, and the floor is where trust gets built.