The Build Log: why we write this in public

PlayaOS is a planning and operations platform for Burning Man theme camps. A camp gets a portal on its own subdomain — roster, applications, dues, shelter assignments, shifts, kitchen logistics, documents — and a member-facing app for the people in it. It is free, with no tiers and no member caps.

This log is where we write about building it.

Why write it down

Camp software has an unusually honest feedback loop. There is one deadline a year, the user base is a few thousand people who all know each other, and the failure mode of a bad tool is a camp lead reconciling spreadsheets in a tent on a phone with one bar of signal. You find out quickly whether a decision was right.

Most of those decisions are not interesting on their own. "We store the packing list as three layers and merge them at read time" is not a headline. But the reasoning behind it — and the two simpler approaches we tried first — is the part worth keeping, because the next person to touch it (possibly us, next season) starts from scratch otherwise.

So the entries here are written the way we would want to read them: what the problem actually was, what we chose, and what we gave up. When there is a trade-off, we will name it instead of pretending it wasn't there.

What "built by engineers" means here

The short version is that the same people design the schema and answer the support email. That shows up in small ways:

• One database, one tenant model. Every camp is an org in the same database, and access is enforced in one place — not per-camp copies that drift.
• An API first, not an API eventually. Camps that outgrow the hosted portal can build their own front end against the same REST API and data, and keep the hosted portal working alongside it.
• Boring, verifiable choices. Static pages where a static page will do. Real tests for the things that can quietly corrupt data. No tracking scripts on the marketing site, because a camp's members are not inventory.

What this log is not

It is not a changelog. Changelogs list what shipped; this is about why. It is also not a promise that everything here is finished — some of the most useful entries will be about things we got wrong and changed.

If you run a camp, the practical pages are the features overview and pricing (which is short, because everything is free). If you build software, start at developers or the API reference. And if you just want the posts, the RSS feed is the subscription path — we do not run a newsletter, and there is nothing to sign up for.