April/May 2026: Beta is Live

As of this morning, the beta program is live and the first 50 beta testers got access to the new Walling!

After months of foundation work, refactoring, and steady building, we are finally ready for real user testing and feedback to help us iron out the remaining bugs.

Here's where things stand:

• 540+ people signed up for the beta — far more than we expected
• Wave 1 is open — ~50 users, starting today
• Waves 2 and 3 are queued — +100 users, then the remaining ~390
• The product is in production — deployed with proper observability and ready for real-world use

April was about getting from "almost ready" to "ready." This is what that looked like.

A beta program, not just a beta release

When we opened beta signups, we weren't sure what to expect. 540+ signups later, we had a much better problem on our hands than we anticipated — and a decision to make about how to roll it out.

Onboarding 540 people on day one would have been the wrong move. Early beta is when the most unexpected things surface, and we wanted to be able to respond to each wave of feedback before opening the door wider. So we structured the rollout in three waves:

• Wave 1: ~50 users — small enough that we can engage closely, watch how the product behaves under real usage, and fix issues quickly
• Wave 2: ~100 users — once Wave 1 feedback has been absorbed and the most important issues addressed
• Wave 3: ~390 users — the remainder, once we're confident the experience is solid

This structure lets us learn fast, respond fast, and progressively widen access without compromising the experience for the people coming in.

If you signed up, you should know what wave you are in, and we'll be in touch as the next waves open. If not, please reach out to us at beta@walling.io.

Hardening the critical user flows

Going into April, we knew which paths had to be rock-solid before we let real users in — and we spent the month tightening them.

Edge cases that only surface at scale. Subtle inconsistencies that compound across a session. Error states that need to fail gracefully instead of confusingly. We went through the flows that matter most and made sure each one behaves the way it should — not just on the happy path, but in the messy reality of real use.

The result: the core experience holds up better under real-user pressure — though we expect more opportunities for improvement to surface.

Deployed to production with observability

Back in February, we deployed the backend to the cloud and built out a smooth, repeatable deployment workflow. In April, we took that one step further — deploying our production environment with foundational observability across our infrastructure.

That means structured logging, metrics, and error tracking — the visibility we need to understand what's happening inside the system at any given moment. When a beta tester runs into an issue, we want to be able to see it, diagnose it, and resolve it — without guessing.

It was important to have this in place before users started coming in, so we could respond to user feedback quickly without spending time reproducing and investigating. We will continue to refine this system as we learn.

The beta program itself

Standing up a beta isn't just about the product. It's about everything around it: how testers get access, how they communicate with us, how we communicate with them, and how feedback flows back into development.

This month we built out:

• The access system — secure, controlled entry for approved testers, with the ability to manage waves and individual accounts
• Communications — onboarding emails, welcome materials, and the channels testers will use to reach us
• Feedback loops — clear paths for testers to report issues, request features, and tell us what's working (and what isn't)

The goal is simple: make it easy for testers to engage, make it easy for us to listen, and make sure nothing important falls through the cracks.

Challenges we're navigating

The hardest part of approaching beta isn't building the features — it's knowing when something is ready enough. There's always one more polish pass, one more edge case worth chasing, one more refinement that would make a flow feel a little better.

At some point, you have to put it in front of real users.

That's the value of a phased rollout. Wave 1 is small enough that we can be responsive — fix what needs fixing, listen carefully, and improve quickly — before opening up to a larger group. We know the product is unfinished. We're letting it be tested, in the real way it needs to be tested, by people who are going to use it.

That's a different kind of work than what we've been doing for the past several months, and we're ready for it.

Looking ahead

With Wave 1 underway, May shifts from "getting ready to ship" to "responding to real users."

Our focus:

• Engaging closely with Wave 1 testers and acting on what we hear
• Resolving issues as they surface and tightening the experience based on real usage
• Preparing for Wave 2 — making sure the product is in even better shape when the next group comes in
• Continuing to improve the editor, the mobile experience, and the AI features we shipped earlier in the year

Reaching beta is an important milestone for us, but it's the start of the loop that's really going to make Walling what it should be.

• • •

Thank you

To everyone who signed up, waited patiently, and is following along: thank you. We know it's been a long road, and we're genuinely grateful for the support.

To the Wave 1 testers who jumped in this morning: welcome. We can't wait to hear what you think.

See you next month.

— The Walling Team