Architecture · March 22, 2026

Starting narrow: why Placefolio needs a calm backend before a wide feature set

Early systems fail less often from missing features than from unclear boundaries. The first backend should make a few workflows explicit and leave the rest unclaimed.

What the first backend actually owns

The initial surface should stay centered on four things: user identity, project storage, revision history, and collaboration membership. These are the places where ambiguity gets expensive quickly.

Everything else should be treated as secondary behavior layered on top. Search, analytics, automation, and rich derived views can come later if the core model remains legible.

Why revisions matter early

Place-based work tends to change under uncertainty. A user revisits a listing, updates impressions, replaces assumptions, or reframes a decision entirely. Revision history is not a premium feature here; it is part of the product memory.

What we deliberately defer

The backend should not pretend to know every future workflow. Public sharing, notification rules, AI summaries, and complex role systems are all valid future candidates, but they should not distort the first data model.

A narrow system is easier to test, easier to reason about, and much easier to migrate when product truth arrives from actual usage rather than planning documents.

Build the memory of the product first. Add the performance tricks and convenience layers after the memory is trustworthy.

Operational effect

This decision keeps the API small, authorization rules inspectable, and entity ownership clear. It also gives the Android client a stable contract while the field workflow is still evolving.