The Dashboard Problem: How I Decided to Split Havnwright by User, Not by Feature

When people ask how Havnwright is structured, the honest answer right now is three dashboards. Homeowner, contractor, and admin. Each one is its own experience, built around how that specific role works. There is a fourth dashboard for businesses that I have designed and partially built, but it is not operational yet, and I want to talk about why that is a deliberate choice rather than a missing feature.

This was not an obvious decision when I started. The default play in product design is a single dashboard with different views, toggles, or role-based widgets. One codebase, one interface, different content for different users. That is how most SaaS products start.

I did not go that way. I want to explain why.

The question behind the decision

Before you decide how many dashboards to build, you have to answer a different question. Do the users of your platform have fundamentally different jobs, or are they doing the same job with different permissions?

Most SaaS products have one answer and the role-based-widgets pattern works for them. Everyone is roughly trying to do the same thing, some people just have access to more features than others. In that world, one dashboard makes sense.

Havnwright is different. A homeowner planning a renovation and a contractor running a job site are not doing the same job. They are not even doing similar jobs. They have different questions, different time pressures, different tools they need, and different moments where they open the platform. Putting them in the same dashboard and toggling visibility would have produced something that was mediocre for both of them.

Once I saw the problem that way, separate dashboards per user type were not a trade-off. They were the only honest answer.

The homeowner dashboard

This is the one I put the most thought into, because it is the one that is most unlike a typical dashboard.

Most dashboards show you statistics. Graphs, KPIs, activity feeds, recent items. That format works when the user's job is to monitor an ongoing process. It does not work for someone who is about to start a renovation and has no idea where to begin.

A homeowner coming to Havnwright for the first time is not looking at statistics. They are trying to answer questions like "where do I start," "how much will this cost," "do I need permission," "how do I find someone to do this." A stats dashboard is useless for those questions.

So the homeowner dashboard is not a stats dashboard. It is a step-based journey. Six steps, each one a phase of the renovation process from the very first idea to the finished project. At every step the homeowner sees the tools they need and the information relevant to where they are. They are not presented with the entire platform and asked to find what matters. They are walked through the process.

This meant the homeowner dashboard is closer to a guided workflow than a traditional dashboard interface. Content-heavy, structured, paced. Designed for someone who does not already know what they are doing, which is most people when it comes to renovation.

The contractor dashboard

Contractors have the opposite problem. They know what they are doing. They just need the right tools in the right place.

The contractor side of Havnwright lives primarily in the native mobile app. That is where the daily workflow happens, because contractors are on job sites, not at desks. But I also built a full web dashboard for contractors, because there are things you want to do at a proper keyboard that are painful on a phone. Writing longer responses. Reviewing detailed documents. Managing team members.

The web dashboard mirrors the features of the mobile app rather than replacing them. Same backend, same data, same auth. The mobile app and the web dashboard are two windows into the same contractor experience, each tuned to the device you are using. The only real difference is at the payment layer. Subscription billing goes through Stripe on the web and through RevenueCat on the mobile app, because the stores require their own payment systems. Beyond that, the experience is consistent.

Building a separate web dashboard for contractors when they already had an app felt like extra work at the time. In retrospect it was clearly the right call. Contractors open it when they want to do the kind of work a phone is not ideal for, and the platform is better for having both surfaces.

The admin dashboard

This one does not get talked about much, but it is the one that keeps the whole platform running.

Running a multi-sided platform solo means I need a place to actually see what is happening. Not just marketing numbers, but operational reality. Which users are active. What content is being created. Where errors are happening. How the pipeline is behaving. Whether anyone is trying to break something.

The admin dashboard covers architecture visibility, security monitoring, content management, and CI pipeline status, among other things. When something goes wrong, and things will go wrong, this is where I start. It lets me understand the problem before I touch anything.

A proper admin dashboard is one of those investments that feels excessive while you are building it and essential the first time you need it at two in the morning. I treat it as critical infrastructure, not a nice-to-have.

I also want to be honest about the difficulty of actually building this, because "build your admin dashboard early" is the kind of advice that sounds simple and is not. Wiring up real operational visibility requires knowing the ins and outs of your own platform. You need to understand your data model well enough to surface the right signals. You need to understand your infrastructure well enough to connect to it without breaking anything. You need to understand what "things going wrong" actually looks like before you can build the tools to catch it.

If you are experienced, this is a known amount of work. If you are building your first or second platform, it is genuinely harder than you expect. Modern tools make it faster than it used to be, but the technical knowledge required has not disappeared. I do not want to pretend otherwise.

The fourth one, on hold

There is a fourth dashboard in the plan. It is for businesses that sit around the renovation industry. There is a dedicated page on the Havnwright site that describes what I am trying to build for them, and the dashboard itself exists as designed structure, but it is not operational at this moment.

The reason is staging. Right now I am focused on growing the user base of homeowners and contractors. Every hour spent on the business side is an hour not spent growing the core two sides, and without enough homeowners and contractors on the platform, a business dashboard would not have a real audience yet.

So the business dashboard is part of the plan, the thinking is laid out, and it will come online when the rest of the platform is at the scale it needs to be. Not before. I am deliberately not giving away the full shape of what this will look like. That story will write itself once the infrastructure is ready.

Why the two user-facing sides are not connected yet

A natural question is "if you have homeowners and contractors on the same platform, why can they not find each other yet?"

This is intentional. I wrote about it in my post about why Havnwright exists. The short version: each side has to be worth using on its own before it is worth connecting them. A homeowner who lands on a directory of three contractors is worse off than a homeowner who lands on a useful planning tool. A contractor who signs up to see no jobs is worse off than a contractor who has good workflow tools for their existing business.

So the current phase is about making each dashboard valuable in isolation. Homeowners use it to plan renovations and learn. Contractors use it to run their business. Admins run the platform. Connecting them will happen when connection makes each side better, not when I want to flip a switch and have a marketplace overnight.

What I would tell someone designing for multiple user types

A few things I have learned.

Ask if your users are doing different jobs or the same job with different access. If different, separate dashboards will serve them better. If same, role-based widgets are fine. Do not default to one answer without asking the question.

Design the dashboard around the user's actual workflow, not around your data. A homeowner does not want to see statistics. They want to be guided. A contractor does not want to be walked through a workflow. They want fast access to the tools they already know. Let the user's shape dictate the dashboard, not the shape of your database.

Build the admin dashboard early, but do not underestimate what it takes. Even as a solo founder, you are the ops team, the support team, and the engineer. You need the visibility. But wiring up a real admin dashboard requires deep knowledge of your own platform. If this is your first or second one, expect it to take longer than the advice makes it sound.

Do not try to connect user types before each is valuable on its own. A premature marketplace is worse than no marketplace. Let each side mature first.

Have a plan, and let it guide what you ship. The business dashboard exists in the plan but not in production yet, because that is what the plan says it should do right now. Shipping everything you have built is not the same as shipping what makes sense. The plan is the filter.

---

This is part of a series about building products as a solo founder. Earlier posts cover why I built Havnwright, shipping a native mobile app, the centralised authentication pattern, and Postgres RLS. More coming.