Devlog #2: The Multi-Product Navigation Problem

Solving the multi-product dashboard problem for SaaS founders. Testing three navigation prototypes, killing our Redis queue system, and dogfooding our own bug reporting. Technical build log from Patrick & Aurnik on building an AI support autopilot.

💡
Jetson is our AI autopilot for customer feedback. It reads your Help Scout inbox and automatically turns conversations into bugs, feature requests, and documentation drafts, then syncs them with GitHub where work happens. No more copy-pasting support emails into issues or missing patterns in customer complaints. We're building it because we've spent years drowning in support across multiple SaaS products.

This Week's Focus

We spent most of our dev call this week debating navigation architecture for users with multiple products. The core challenge: how do you show both aggregate data across all products and product-specific details without creating a confusing interface?

The Problem

I (Patrick) run Recipe Kit, Wait.li, and Better Blog Comments. Each has its own Help Scout mailbox. When I log into Jetson, I need:

  • Bird's eye view of all bugs across everything
  • Ability to dive deep into, for example, just Recipe Kit's feature requests
  • Clear understanding of where I am in the interface

Standard sidebar with every mailbox listed falls apart at scale. Six products means 24+ menu items. The whole thing quickly becomes a UX nightmare.

Mailbox Switcher (Slack-style) Dropdown at the top to select your product. Clean, focused.

Problem: When viewing the overview page with aggregate data from all products, what does the dropdown show? The mental model breaks.

Everything in Sidebar List all mailboxes as collapsible parents with child items.

Problem: Doesn't scale. Too much visual noise. Cognitive overload from scanning irrelevant products.

No Sidebar Top navigation with breadcrumbs that have dropdown functionality.

Problem: Mobile users expect hamburger menu. Loses persistent navigation context.

What We're Building Next

We're creating different navigation options to test:

  • Overview as separate page with aggregate metrics and pie charts showing distribution
  • Mailbox-specific dashboards for product-deep dives
  • Testing whether users care more about overview or product-specific views

Key architectural decision: using organizationId as source of truth rather than user accounts. This enables multi-user access without permission complexity.

The Onboarding Value Hook

We decided the final onboarding step should analyze one recent conversation and show the classification result. Show them immediately: "Hey, we found this bug report that came in yesterday."

Not just aggregate numbers, but one specific example they probably missed. That's the "oh shit, I need this" moment.

We discussed filtering to ensure quality - maybe grab conversations with staff replies or multiple messages to avoid showing spam as the example.

Technical Decisions

Killing the Queue System (For Now) Initially planned Bull and Redis for distributed processing. Decided to use Node.js worker threads on the same server instead. Railway auto-scales to 32GB RAM. We can add horizontal scaling when we actually need it.

GRPC infrastructure is set up but not active. Current processing happens in-thread. Eliminates Redis configuration complexity for MVP.

What We're NOT Building

  • Help Scout documentation replacement (different product, different market)
  • Time-saved metrics (too speculative for MVP)
  • Distributed architecture (premature optimization)

Dogfooding Setup

We're setting up our own Help Scout account for Jetson development. Added the beacon to jetson.help so when we spot bugs while testing, we can fire off messages that Jetson will classify and turn into GitHub issues.

Currently we are manually creating GitHub issues from Slack messages, but Jetson is built exactly to eliminate this friction, so we may as well use it ourselves.

Business Stuff

Tracking expenses in Google Sheets for now. Considering Sentry for session replay and error tracking. Haven't incorporated yet - waiting until we have paying customers or need to apply for grants.

Timeline

Will test UX decisions with our first beta user (runs 6 Shopify apps). September 1st target for shipping based on feedback.

Next Steps

Decisions to validate with real users:

  • Overview vs Product-specific focus: Do users primarily want aggregate views or individual product dashboards?
  • Navigation patterns: Which approach reduces cognitive load while maintaining clarity?
  • Onboarding flow: Does showing one real example create more value than showing capabilities?

We'll solve these with usage data from beta testing, not theoretical debates.

Want to test Jetson? We need users with multiple products and messy Helpscout mailboxes: hello@jetson.help