Set the platform's founding decisions in the weeks after the repository opened in November 2025 — the layering, database‑first data access and the zero‑warnings bar — and they still hold nine months on.

Situation. The repository opened on 25 November 2025 with nothing in it. What gets decided in the first few weeks of a project like that is disproportionate: the layering, where the business logic is allowed to live, what the quality bar is. Those choices are cheap to make on day three and close to impossible to reverse by month six, by which point everything written since assumes them.

Task. The founding decisions had to be made deliberately and early, and made in a form that could survive being handed to other people and to a much larger codebase than existed at the time.

Action. Three decisions did most of the work. The stack was layered so each part has one job — a Next.js frontend, a Go API that validates and forwards, a PostgreSQL function layer that owns the business rules — rather than logic being placed wherever it was convenient that afternoon. Data access was put behind stored functions from the start, which is the choice everything else in the database record follows from; retrofitting it later would have meant rewriting every handler. And a zero‑warnings bar went in before there was much code to hold to it, because a standard introduced at commit 5,000 is a cleanup project, whereas the same standard at commit 50 is just how the repository works. None of the three were the easy option at the time, and all three cost momentum in the first month.

Result. Nine months and several thousand commits later, all three still hold: the layers have not blurred, no handler talks to a table directly, and the build still has no warnings in it. That is the check worth applying to a founding decision — not whether it sounded right, but whether it survived contact with the volume of work that came after, which is the point at which convenient choices usually get quietly abandoned.