MoveTribe

The problem

Pickup sports run on group chats. Someone knows a court, someone else knows six people, and the two facts never quite meet — so games fall apart over a roster rather than a venue. The coordination problem is small, repetitive, and exactly the shape software is good at.

The approach

Three independently deployed surfaces — a marketing site, the application, and an admin console — each its own edge-hosted static project, all sharing a single managed PostgreSQL backend with row-level security and hosted authentication.

Splitting them rather than shipping one large application means the marketing site cannot be broken by an application deploy, and the admin console can carry stricter access controls without complicating the main app’s routing.

What was actually hard

The project needed live product counts on an operations dashboard, and the obvious approach failed twice over. The dashboard tool could only read values from a JSON response body — but the database’s REST layer returns row counts in an HTTP header, and the aggregate-function route was disabled on the project. Both endpoints also required an API key, which would have meant the dashboard holding a credential it had no business holding.

The fix was a small edge function that runs the count probes server-side, reads the header, and returns flat JSON. Each probe is independently error-handled, so one broken table returns a null field instead of failing the whole response. The credential never leaves the backend.

It is a small piece of code, but it is the shape of a lot of integration work: the constraint was never the data, it was where the data was allowed to travel.

The outcome

Live in public beta at movetribe.fit, with real users organising real games. The feature set is still moving, which is the point of the label.