Fieldnote.

The problem

The risk wasn't technical. Every feature I imagined (profiles, follows, comments, gamification) was a way to avoid the real question: is the write → share → discover loop compelling enough on its own?

What made it technically interesting

Cutting to one loop meant saying no to a dozen features that felt mandatory — and building the one loop so well it didn't feel small.

The reading experience carries the product: typography, maps and image handling needed real polish, because the test was about desire, not workflow.

Content had to be structured data in the application's own database — portable and queryable — rather than documents inside a third-party CMS.

Decisions

One primary loop, ruthlessly

Every feature had to serve write → share → discover or wait. That constraint is what made the six-week deadline possible.

Reading experience over admin features

The polish budget went to the guide pages — typography, maps, image handling — because the risk being tested was emotional, not operational.

Postgres-backed content model, no CMS

Guides are structured rows, not documents in a service, keeping the product portable and the data queryable as the concept evolves.

Result

• A working MVP in six weeks: focused editor, shareable guide pages, a minimal discovery feed.
• Clear evidence for and against the founding hypothesis — the MVP became the argument for what to build next.