From Beta to Launch: The 669 Founding Members Who Carried Us

There is a habit in software where companies write blog posts thanking their “community” without naming anyone, citing anything, or admitting how big — or small — that community actually was. We want to do the opposite. The early life of Baseline Maps was not a movement. It was a private beta that opened in January 2026, a steady trickle of signups, and a cohort of 669 founding members who carried the app all the way to public launch in June. Out of roughly 1,100 early users, those 669 are the ones who showed up and stayed.

This is the gratitude post we owe them. Not abstract thanks for “supporting us on the journey.” Specific thanks, for the kind of feedback that shaped specific screens. If you have ever wondered whether one well-written note actually moves the needle on a piece of software, the rest of this post is for you. The short version: it does, and the long version is everything below.

The beta we almost didn’t open

We almost didn’t open the beta when we did. The app was rough, the install count was small, and the working theory was that we’d wait until things felt “more ready.” Then a friend pointed out that “more ready” is what you tell yourself when you’re afraid of the answer. So we opened it. The first founding-member signup landed on January 6, 2026, and the cohort grew from there, person by person, until we closed it in early June ahead of public launch.

What we didn’t expect was how lopsided the signal would be. The people who cared enough to write to us were, overwhelmingly, the people who cared enough to stay. The feedback box became, accidentally, a kind of retention probe. Engagement and loyalty weren’t two different things; they were the same thing showing up twice.

How the feedback actually came in

We didn’t run a polished research program. We ran an in-app feedback box and we read what came through it. No Likert scales, no NPS, no star ratings — just a place to say what was broken, what was missing, and how the app fit into a real day outside.

The benefit of that format was that the replies were paragraphs and voice-style descriptions instead of numbers. Every one contained an actual sentence about an actual moment of using the app. We learned about a hard-to-read label because someone described squinting at it at dawn. We learned a download had failed quietly because someone walked us through the moment before they gave up. None of that survives a five-star rating.

What founding members told us the product was

The most useful thing the feedback did was make people describe the product instead of grade it. “It’s the only map that shows me where the boundary actually is.” “It loads when the cell tower doesn’t.” “It doesn’t try to be a social network about my fish.” Reading enough of those in a row is how we learned what we had actually built.

Which turned out to be slightly different from what we thought we were building. We thought the product was an outdoor app. Users told us the product was an honest map. We thought the brand was the differentiator. Users told us the data was. We rewrote the home screen, the onboarding, and the store description on the strength of that. None of those changes would have come from a satisfaction score.

The patterns that reorganized the business

Three patterns showed up again and again. First, the data was the product — accurate boundaries, current regulations, real elevation — not the interface or the brand or anything we could have A/B tested. Second, users kept asking for features we hadn’t considered, several of which were obvious in retrospect and embarrassing in foresight. Third, the people who wrote carefully were the same people who stayed for months.

That third pattern quietly reorganized how we think about the whole business. The willingness to describe a problem in your own words turned out to be a far stronger signal of long-term retention than session counts or install dates. The lesson generalized: the user who is talking to you is usually the user who is staying.

From a feedback box to the Development Queue

Early on, the feedback lived in inboxes and notebooks. As the cohort grew toward 669, that stopped scaling. So we built the Development Queue into the app itself: a place where requests are visible to everyone, where users can vote on what matters, and where you can watch a feature move from “asked” to “shipped.” A lot of what founding members surfaced in those first months made it into the app before public launch. Some of it shipped in the weeks after. A few requests are still in flight, visible in the Queue with the original requester credited by name when they opt in.

Our honest cadence hasn’t changed since then. Bugs often get fixed within days. Most features land within a week or two of the request. We don’t always get it perfect, but we try to build in the open, where the people who asked can see the work happening.

Who the 669 are

We are not going to pretend we know all 669 founding members personally, or that we can recite their stories from memory. That would be the kind of fabricated intimacy this post is trying to avoid. What we can say honestly is that they are anglers, hunters, and foragers across the states we cover — people who opened a rough build, found the broken thing, and told us about it instead of walking away. Some are now among the most active voices in the Development Queue. A handful have become informal testers for risky changes, the kind of work where you need someone who will actually open the build and dig in.

The 669 are not a demographic. They are a cohort defined by a single shared behavior: they showed up early and they kept showing up. They know who they are, and so do we, and that mutual recognition is the whole point.

The signal nobody talks about

There is a signal most product teams ignore because it doesn’t fit in a dashboard. It’s the difference between a user who taps “Submit” on a generic form and a user who takes a minute to describe, in their own words, exactly where the app let them down on a riverbank. Both technically count as “engagement.” Only one of them is telling you anything.

Founding-member feedback was almost entirely the second kind. Looking back, the beta was less a research instrument than a self-selection filter for the kind of people we wanted to build alongside. The open-ended, plain-language format mattered, because it gave people room to say something real instead of clicking a number. If you only ever ask for clicks, the people who would have told you a story never get the chance.

How we run it now

The spine of the work hasn’t changed. We still ask what’s broken and what’s missing. We still read every answer. We still build for the people who write back. The difference is that the kitchen-table version has grown up into the in-app feedback box and the Development Queue, which now handle most of what used to live in scattered emails.

We would rather know a cohort of people who care than a much larger crowd who barely notice we exist. That is not a humility flex. It is an operating decision, and it is the one decision from the beta era that has cost us nothing and given us everything. Guessing what users want from aggregate metrics is how most outdoor apps end up feeling like they were designed by people who have never been outside. We’d rather just ask.

---

If you are one of the 669: thank you. You carried this app from a rough January beta to a real public launch, and the version everyone uses today is the version you shaped. If you are not, but you are reading this on a phone with Baseline Maps installed, the door is still open. Open the feedback box. Tell us what’s broken, what’s missing, or about the moment the app failed you. We read everything, we triage everything, and the things we ship next are visible to every user in the in-app Development Queue. The product is built out in the open, by people who care, and that has not changed since the first signup in January.