The Beta Phase: How I Rebuilt the Contractor Dashboard Without Breaking the One People Were Using

When Havnwright started, it was a single web app serving both homeowners and contractors. At some point I decided the contractor experience needed a native mobile application, and that decision quietly changed the shape of everything that followed. The mobile app got my full attention. The web app contractor side went on the back burner. Updates went to mobile first, web second, and over time the gap between them grew into something I had stopped paying attention to.

Then the traction came.

A head contractor I had been working with started promoting the platform to his network. Sign-ups picked up. The number of contractors on the platform climbed past a thousand. And I realised, with the sort of clarity you only get when the cost of ignoring something is suddenly real, that some of these new users were going to land on the web app first. They would see a domain, type it in, and look at whatever the contractor dashboard had become while I was busy with mobile.

Whatever it had become was not good.

The horror situation

When I opened the contractor side of the web app and went through it as a new user would, I found a dashboard that had quietly fallen out of sync with the mobile app over the course of months. Some features that existed on mobile were missing from web. Some were present but wired to wrong endpoints. Some had layouts that had been designed for a phone screen and never adapted for a desktop. The list of things that needed to change was long enough that I could not just fix it one issue at a time without users seeing the bugs midway through.

This is where the constraint clarified the problem. I had around a thousand signed-up users at this point. The numbers were real enough that any disruption would be noticed by someone. They were also small enough that I had not yet built the operational infrastructure that mature companies use to manage this kind of work safely. I had a live platform and a tight deadline. I could not afford to break the dashboard that users were currently relying on while I rebuilt it. I also could not afford to take months to do it properly.

The first instinct was to start fixing things in place. Touch up the layouts, swap the endpoints, ship a flurry of small improvements. The problem with that approach was that users would see each individual change as it happened. A button moves on Monday. A page redesigns on Tuesday. A new section appears on Wednesday. From the user's perspective, the dashboard is in flux every time they log in, which is the worst possible kind of trust signal for a contractor trying to run a business through your platform.

The second instinct was to take the contractor dashboard offline for a few days and ship the whole rebuild at once. The problem with that approach is obvious to anyone who has ever taken down a live product for "a few days." There is no such thing as a few days.

I needed a third option, and I did not have one.

I am not the first person to have this problem

The first useful thing I did was stop trying to invent a new solution and start looking for the pattern someone else had already discovered.

It turns out enterprises have been managing this exact problem for decades. The pattern is variously called a beta phase, a soft launch, a parallel implementation, or a dark launch depending on which company you ask and which exact variation you mean. The core idea is the same in all of them: do not modify the existing thing. Build the new thing alongside it. Let users move between them on their own terms. Retire the old thing only when enough people have moved over that you are confident the new one is genuinely better.

This was the first time I had implemented this pattern myself. Every previous project I had worked on was either small enough that a hard cutover was fine, or worked at a company where someone else had already set up the infrastructure for staged rollouts. I had heard the words. I had not done the work.

Once I had the right mental model, the actual implementation became a sequence of clear steps rather than a panic.

What the beta phase actually looks like in Havnwright

The contractor logs in and lands on what I am still calling the main dashboard. It is the dashboard they have always had. Everything they remember is in the place it has always been.

The only new thing on that page is a small block near the top of the screen, with a clear explanation of what is going on. We are testing a new version of the dashboard. If you want to try it, here is the link.

The link takes them to settings. Settings has a section clearly labelled beta phase, with a checkbox and a sentence describing what flipping it will do. When they tick the box, the new dashboard becomes their default. When they untick it, they go back to the old one. There is no friction. There is no commitment. They can move between the two as many times as they want.

Behind the toggle, the new dashboard is a completely separate route in the application. Different layout, different navigation, different widgets. It shares the same database, the same authentication, the same backend services. What it does not share is the visual surface area. Users who have not opted in will never see any of it. Users who have opted in will see only it, until they decide otherwise.

The third piece of the system is the timeline. The old dashboard is not going away the day the new one ships. It will keep running for as long as enough users are still using it that retiring it would cause disruption. When enough have moved over, when the new dashboard has earned its position by being measurably better in the ways that matter, the old one quietly comes out of the codebase. Big enterprises run this transition over six months. Mine will probably take less because there are fewer users to migrate, but the structure is the same.

This is the pattern. There is nothing in here that is novel. The reason it worked for me is not that I came up with anything clever. It is that I stopped trying to invent and started copying what has been working for everyone else.

Five sections and a customisable Quick Actions

When I sat down to design the new dashboard itself, the first problem I had to solve was the one that had been hiding inside the old dashboard the whole time. Havnwright has around thirty-eight tools available to a contractor. Calendar, jobs, expenses, scheduling, photo documentation, team messaging, and so on. The old dashboard presented them as a flat menu, and even I, who had built them, would get confused looking at the list.

If I would get confused, a new contractor signing up has no chance.

I went through every tool and asked which group it belonged to. The answer was five groups. Not because five is a magic number. Because that is what came out when I asked the question honestly. Some tools relate to your day. Some relate to your jobs over time. Some relate to your team. Some relate to your money. Some relate to running the business as a whole. Five sections in the sidebar, each one a mode the contractor switches into when they need that part of the work.

On top of the five sections, the Today screen has a Quick Actions block that the contractor can customise. They pick up to eight tools they use most often, and those are surfaced as one-click shortcuts at the top of their dashboard. The shape of a contractor's daily work is different for everyone. Some live in the calendar. Some live in jobs. Some live in messaging because their team coordination is the bottleneck. The customisable Quick Actions let each contractor put their bottleneck within reach without forcing me to design eight different dashboards.

Here is the kitchen example, because it makes this concrete.

A contractor gets a job for a kitchen renovation. They open the job in the Havnwright Contractor app. There is a diary section where they record what stage the project is at on any given day. There is a notes section for things they need to remember. There is a variations section for changes the client has agreed to that need to be priced and tracked. There is a photos section for documenting the work. There is a calendar entry that links back to the job from the schedule. If that contractor uses the kitchen workflow heavily, their Quick Actions will probably include jobs, calendar, and photos. If they use a different workflow, their Quick Actions look different. The platform does not assume.

This kind of decision becomes possible only once you have built the substrate that lets users opt into a new experience without forcing them. You can iterate on the dashboard without breaking the dashboard. You can ship the customisation feature without it being the thing every contractor sees on day one. The beta phase is not just a deployment pattern. It is a permission slip to design more thoughtfully.

The version foundation that had to come first

There is one piece of this story that is worth pulling out, because it caught me by surprise.

Before any of the alpha builds for the new dashboard could land, I had to do something I had been putting off for months. I had to give the Havnwright web app a versioning story.

I had been shipping the web app without proper version numbers. Each deployment was a commit on master, no tags, no CHANGELOG, no clear way to refer to "the version before the beta phase started." That had been fine when the platform was small and I was the only one who needed to keep track. It stopped being fine the moment I needed to label the new dashboard as v1.2.0-alpha.1 so I could refer to it distinctly from the current production version.

So before the rebuild work could start, I bumped the web app to a real version number, backfilled a CHANGELOG covering everything I could reconstruct from git history, and adopted semver as the discipline for everything that followed. That sounds tidy when described in a sentence. In practice it was an unglamorous afternoon of going back through commits and trying to remember what counted as a breaking change versus a feature versus a fix.

The lesson buried in that sequence is one I have written about on this site already, in a different form. The absence of infrastructure does not hurt until it does, and then it hurts all at once. Rules in your head about how to ship are not infrastructure. A real CHANGELOG with real version numbers is infrastructure. When the rebuild forced me to need versioning, the cost of not having it was not the half-day to set it up. It was the half-day plus the cognitive overhead of doing setup work in the middle of a tight deadline I had not budgeted for it.

If you are running a project without version numbers, the time to fix that is before the moment you need them.

What the rollout actually felt like

Most blog posts about rollouts make them sound serene. A clear plan, a clean execution, a smooth handoff. The reality of this one was nothing like that. A long string of commits in a quick rush, half of them building on commits that had landed a few minutes earlier, written between drafting blog posts and answering emails and dealing with whatever was breaking on the mobile side at the time. The version-numbering work happened in parallel with the alpha builds. The CHANGELOG was written retroactively while the actual rebuild was still in flight.

This is what shipping looks like when you are solo and the deadline is sharper than the plan. It is not pretty. It is not how a textbook would describe it. The work gets done because you keep doing the next thing in front of you, and because the structure you put in place earlier, the beta phase pattern in this case, gives you permission to ship rough work without breaking the people you have already.

I am writing this down partly because it is honest, and partly because every founder who is about to do this work needs to know that the experienced version of it does not feel any more controlled than the inexperienced one. The technique is what makes it work. The technique is also what makes it survivable.

What I would tell another founder

The thing I wish I had internalised earlier is that almost no idea is unique. Either someone is doing it, or someone has done it. The dashboard rebuild problem I just described has been solved by hundreds of companies before me. The beta phase pattern I used has a documented history going back decades. None of this is my invention. My contribution was the willingness to look it up and copy it.

A lot of solo founders waste time waiting for a unique idea before they start building. The unique idea, in my experience, almost never arrives that way. Innovation comes from doing the work, getting feedback from real users, and noticing the small places where what you built does something nobody else's version of the same thing does. That noticing only happens after you have built the thing.

So if you are sitting on a problem that feels like nobody has solved it, the most useful first move is to assume someone has, and find them. If you genuinely cannot find anyone who has solved it, then maybe you do have a unique idea, and you should pursue it. But in something like ninety-nine cases out of a hundred, the answer is already out there in a form you can adapt to your specific situation.

I am not the first person to have any of the problems I have written about on this site. The dashboard rebuild is one of them. The cross-platform subscription work was another. The agent infrastructure was a third. The pattern is consistent. The work is the doing, not the discovery. The discovery has usually already happened.

If you have one piece of advice you want to take from this post, take that one. Do the work. The ideas are already there.

---

This is part of a series about building products as a solo founder. Earlier posts cover subscriptions across web, iOS, and Android and why the Founder Knowledge Graph exists. More coming.