Devlog #3: Prioritizing Core Features for First User Testing

This Week's Focus

With Patrick leaving Sunday for a week, we needed to get something testable in front of our first user by Friday. That meant prioritizing what would deliver immediate value for our first user's testing session while deferring other features to post-MVP iterations.

Key Decisions This Week

Documentation Features: Deferred to Post-MVP

We decided to hide all documentation and article creation features behind a feature flag for this test. The system will still classify conversations as potential documentation needs in the database, but won't push anything to Help Scout collections yet.

The reasoning: Documentation drafts are public-facing content that requires more polish. Without bidirectional webhooks to track edits made in Help Scout, we'd create a confusing state management problem. Bug reports and feature requests provide clearer, more immediate value for initial testing.

GitHub Integration: Starting with URL Scheme

Rather than implementing full GitHub OAuth and automatic issue creation immediately, we're building a simpler URL scheme approach for the MVP:

• Users paste their repo URL in settings
• Each work item gets a "Create Issue" button that opens GitHub's issue creation page with pre-filled title and description
• Automatic pushing to repos will come after we build proper approval workflows

This avoids the risk of flooding a production repo with auto-generated issues while still demonstrating value.

Help Scout Sync: Cron Job First, Webhooks Later

We're starting with a simpler cron job approach that runs every 30 minutes instead of implementing webhooks for the MVP. For one test user, near-instant updates aren't critical. The cron job will:

• Run initial scan for past 365 days of conversations after onboarding
• Subsequently scan last 12 hours every 30 minutes
• Trigger automatically after onboarding completes to reduce friction

Webhooks remain the goal for the production version.

Duplicate Detection as Priority

The most valuable feature we identified: detecting when multiple customers report the same issue. Instead of creating duplicate work items, Jetson should cluster similar requests and show "25 people have asked for this."

Currently, the system creates duplicates when re-scanning the same conversations. We need the scan to either update existing items with additional context or skip them entirely.

MVP Scope

Shipping Friday:

• Bug and feature request creation from Help Scout conversations
• Duplicate detection and clustering
• GitHub URL scheme for easy issue creation
• Automated scanning via cron job
• Production logging and error management with Sentry

Deferring to Next Sprint:

• Help Scout draft article creation
• Full GitHub OAuth integration with automatic issue creation
• Webhook-based instant syncing
• Billing, Stripe, and email notification features
• Sentry integration for customer errors (keeping internal Sentry only)

Timeline

• Wednesday-Thursday: Focus entirely on the four priority items
• Friday: Test call with first user
• Structure: 30-minute call with user, preceded by 30-60 minute prep session

Next Steps

Priority order for implementation:

1. Hide documentation features behind feature flag (quick win)
2. Set up Help Scout cron job with intelligent duplicate handling
3. Fix duplicate detection and clustering
4. GitHub URL scheme integration

The goal: When user opens Jetson on Friday, he sees his actual support conversations transformed into actionable work items, with clear indicators of which issues multiple customers are experiencing. From there, we'll iterate based on his feedback to build out the full feature set.