Refactor the Everwood dashboard from a Booking-centric layout to a platform-level shell that treats Booking as one product among many.
The old dashboard put Booking at the center. Clicking "All Products" broke the layout. Every future product would either squeeze into Booking's navigation or create a disconnected experience.
When your SaaS grows beyond one feature, the dashboard has to change from product-level navigation to platform-level navigation. The sidebar is where that decision lives.
The Build
Everwood started as a single product: an AI booking widget for local businesses like nail salons. The dashboard existed to manage that product. Appointments, workers, services, availability, blocked dates. Everything in the sidebar pointed at Booking because Booking was everything.
That worked. The user logged in, saw their booking stats, managed their schedule, and left. There was Everwood branding around it, but the mental model was clear: this is the booking dashboard.
Then I started planning the next products. CRM to track customers after they book. Messaging and reminders to reduce no-shows. Review capture to turn completed appointments into Google reviews. These were not random additions. They were the natural next steps in the booking workflow. A customer books, you follow up, they come back, they leave a review.
But once I started thinking about where these products would live, the dashboard structure stopped making sense. The overview page was Booking-specific. The sidebar was Booking-specific. If CRM launched tomorrow, where would it go? Inside the Booking sidebar? That is misleading. Its own separate dashboard? That fragments the experience. Neither option scales.
The Problem
The moment I saw the problem clearly was when I clicked "All Products." I was building a page to show all Everwood products, subscribed and unsubscribed. But when the page loaded, the left sidebar was gone.
It was a different layout. Different route structure, different shell. The sidebar that told the user "you are inside Everwood" had disappeared. It felt like I had left the main app and entered a disconnected product catalog.
That was the surface-level issue. But it pointed at something deeper.
The real problem was ownership. The dashboard shell belonged to Booking. The overview page showed Booking stats. The sidebar showed Booking navigation. The entire experience assumed the user was there to manage bookings and nothing else.
That assumption was baked into the navigation, not just the UI. And it meant every new product would face the same question: do you squeeze into Booking's sidebar, or do you build your own isolated view? Both answers are wrong. Squeezing in misrepresents the product. Isolating it fragments the platform.
I realized the dashboard needed a new owner. Not Booking. Everwood.
Assumption vs Reality
I assumed I could bolt a product page onto a Booking dashboard and it would feel coherent. The sidebar was already there. The shell was already there. Adding an "All Products" link seemed like a small navigation change.
The mental model was wrong. The shell belonged to Booking, so anything outside of Booking felt foreign. The product page was not the problem. The problem was that Booking was the landlord when it should have been a tenant.
The Fix
The fix was not a visual redesign. It was a change in how the dashboard is structured and who controls the shell.
First, I created a product registry. One list where every product declares its own name, description, status, and its own sidebar navigation, so Booking became one entry in that list instead of the thing the sidebar was built around. A product can be in one of four states: subscribed, available, coming soon, or available on request.
Second, I rebuilt how the sidebar is assembled. Instead of Booking navigation being written into the shell, the sidebar is now built on the fly from whatever the business is actually subscribed to. It starts with an Overview section that always links to the platform dashboard. Then it loops through subscribed products and adds their sidebar groups. Then it adds a Products section with an "All Products" link. Finally, the Account section goes at the bottom with Audit Logs, Support, and Settings.
The order matters. Products sit above Account in the sidebar because products are what the user came to use. Account is where they manage their relationship with Everwood. That hierarchy tells the user the platform is about the products, not the settings.
Third, the "All Products" page now renders inside the same DashboardShell. Same sidebar. Same header. Same layout. The user does not leave the platform to browse products. They stay inside the shell and the content area changes. That sounds obvious, but the previous version broke this completely.
Fourth, the overview page changed. Instead of showing only Booking stats, it now shows a Platform Dashboard heading with a note that additional product metrics will appear as products are enabled. Booking data still shows because Booking is currently the only subscribed product. But the framing shifted from "this is your Booking dashboard" to "this is your Everwood dashboard, and here is what Booking is doing."
Navigation is not UI polish. It is product architecture. The sidebar tells users what your product is. When Booking owned the sidebar, the product was a booking tool. When Everwood owns the sidebar, the product is a platform. That is not a cosmetic difference. It changes how users understand what they are paying for and what else might be available to them. The deeper lesson is about timing. I did not need to build a multi-product platform from day one. Starting with Booking as the entire dashboard was the right call when Booking was the only product. But there is a moment when the navigation starts lying about what the product is becoming, and that is when you have to fix it. Do not overbuild a platform architecture before you have the products to fill it. But do not ignore the signal when your single-product dashboard can no longer hold what you are building.
For a salon owner using Everwood, this change means one place for everything. Today, that means booking management. But when CRM launches, it appears in the same sidebar they already know. When messaging launches, same thing. They do not have to learn a new app or remember a different login for each feature. The "All Products" page lets them see what is available and what is coming. A product marked "Available" can be added. A product marked "Coming Soon" shows that Everwood is growing. Neither of those experiences should feel like leaving the main dashboard. The goal is that a business owner logs in, sees everything in one place, and never feels lost. That sounds simple, but it required rethinking who owns the navigation.
Builder Notes
This was a product architecture decision that showed up as a navigation change. The code changes were straightforward. The mental model shift was the hard part.
Technical Note 1
The registry is a typed list, and each product declares its own navigation alongside its own description. Adding a product to the sidebar means adding it to the registry, not editing the dashboard shell. That is the whole point of the change.
Technical Note 2
The four product states are currently fixed in code rather than looked up. The registry says as much about itself: the next step is to replace fixed availability with a real entitlement check, which means the database has to start tracking which products each business actually pays for.
Technical Note 3
The sidebar is assembled from whatever products the business is subscribed to. Today that check resolves to Booking and pulls Booking's navigation out of the registry. Future products follow the same path with no new shell code.
Technical Note 4
Audit Logs sit in the Account section because they are platform-wide, not product-specific. Each audit log entry should eventually include which product the event belongs to. The current implementation does not have product attribution yet.
Technical Note 5
The database has not changed. This is a navigation and architecture decision running ahead of the data model. The next step is building the products and subscriptions tables so the hardcoded statuses can come from real entitlement data.
Technical Note 6
Analytics is still uncertain. I included it in early planning but pulled back. A nail salon owner probably does not need a complicated analytics suite. They need simple answers: how many appointments are coming, did reminders go out, are reviews improving. Analytics might become product-specific cards on the overview rather than its own top-level section.
Before / After
- Login landed on a Booking-specific overview with booking stats
- Sidebar was hardcoded around Booking navigation
- "All Products" opened a different layout without the sidebar
- Every future product would need to squeeze into Booking's structure or create its own disconnected view
- The mental model was "you are in the Booking dashboard"
- Login lands on a Platform Dashboard with a product-aware overview
- Sidebar is built dynamically from a product registry based on subscriptions
- "All Products" renders inside the same DashboardShell with the sidebar visible
- A new product joins the registry and gets its sidebar navigation automatically
- The mental model is "you are in the Everwood platform, and Booking is one of your products"
What I'd Do Differently
I would have defined the shell as platform-owned from the start, even with only one product. The refactor was not painful, but the mental model shift would have been easier if Booking had always been "a product inside Everwood" rather than "the thing Everwood is." A product registry with one entry is still a registry. It costs almost nothing to set up and saves you from rethinking the navigation later.
I would also decide on analytics earlier. Not build it earlier, but decide what it is for. Right now I am unsure whether analytics is a top-level feature, a per-product card, or something I should drop entirely. That uncertainty comes from not asking the right question up front: what does a local business owner actually check every day?