← Build log

From Two Weeks to Two Hours: Building Production-Ready Help Systems in the Age of AI

How AI-assisted development is fundamentally changing what’s possible for solo builders

The Tale of Two Help Systems

Twenty years ago, I landed my first developer job partly because I spent two weeks building a comprehensive help system for a fictitious product during the interview process. It was a grueling exercise in HTML, CSS, JavaScript, and content creation that demonstrated my ability to ship complete features.

Last night, while watching The Sopranos with my family, I built an entire help system for VoiceCatcher—a real production application—in the time it took Tony Soprano to navigate a single episode’s worth of family drama. Not just the technical infrastructure, but comprehensive user documentation covering 20+ sections, from basic setup to advanced CLI automation.

The world has changed. Here’s how you can leverage that change.

What We Actually Built

In roughly 90 minutes of active development time, we created:

Technical Infrastructure:

  • Complete help window with custom title bar and navigation
  • Search functionality with real-time filtering
  • Dark/light theme integration matching the main app
  • IPC communication between help system and main application
  • Responsive layout with sidebar navigation and content areas

Comprehensive Content:

  • 20+ detailed help sections covering every feature
  • Step-by-step tutorials for new users
  • Complete troubleshooting guides
  • Reference documentation with tables and examples
  • Professional UI/UX patterns throughout

This wasn’t a prototype or MVP—it’s production-ready code that shipped immediately.

The Prompting Strategy That Worked

1. Start with Structure, Then Scale

What Worked:

"Let's build a comprehensive help system for VoiceCatcher. I want to start with the basic infrastructure and then expand with detailed content for all user guide topics."

Why This Worked: Established clear scope and allowed for iterative development. The AI understood we were building something substantial, not just a quick demo.

What Didn’t Work Initially:

"Add some help content to the existing help window"

This was too vague and led to minimal, placeholder-style content.

2. Be Specific About Production Quality

What Worked:

"Write comprehensive user guide content for all topics. This should be professional-quality documentation suitable for both novice and expert users."

What Didn’t Work:

"Fill in the help sections"

Generic requests produce generic results. Specificity about quality expectations is crucial.

3. Leverage the AI’s Contextual Understanding

What Worked:

"Based on the existing VoiceCatcher codebase, create detailed troubleshooting guides that address real problems users might encounter."

The AI analyzed our actual application structure and created relevant, specific troubleshooting content rather than generic help text.

4. Iterate with Concrete Examples

What Worked:

"Add a complete keyboard shortcuts reference with organized tables for different windows, customization guide, and conflict resolution."

Specific feature requests with clear deliverables produced exactly what we needed.

The Technical Decisions That Accelerated Development

1. Build on Existing Patterns

We didn’t reinvent the wheel. The help system used the same:

  • Neumorphic design language as the main app
  • IPC patterns already established
  • Theme system integration
  • Window management approaches

Lesson: Consistency accelerates development and improves user experience.

2. Content-First Approach

Rather than building elaborate infrastructure first, we:

  1. Created basic HTML structure
  2. Added comprehensive content
  3. Enhanced styling and functionality iteratively

Lesson: Content drives design decisions better than abstract planning.

3. Real-World Problem Solving

Every help section addressed actual user scenarios:

  • Permission setup (common macOS friction point)
  • Microphone troubleshooting (hardware-specific issues)
  • Performance optimization (system resource considerations)

Lesson: AI excels when given concrete, domain-specific problems to solve.

What We Got Wrong (And How We Fixed It)

1. Initial Scope Underestimation

Mistake: Started with “add some help content” Fix: Expanded to “comprehensive user documentation” Lesson: AI can handle much larger scope than you think—don’t self-limit.

2. Generic Content First

Mistake: Initial content was too generic and placeholder-like Fix: Requested specific, detailed content for each section Lesson: Be explicit about quality and depth expectations.

3. Missing Integration Details

Mistake: Built help system without considering theme integration Fix: Added proper theme handling and settings integration Lesson: Think systemically—new features should integrate seamlessly.

4. The Hallucination Problem (And Why It’s Not Actually a Problem)

Mistake: AI documented several features that don’t actually exist in VoiceCatcher Fix: Standard technical review process caught and corrected these Lesson: This is identical to working with human technical writers—they need tech review too.

I should know. I was a technical writer for years before becoming a developer. Engineers doing tech reviews can attest to the fact that human writers constantly needed corrections for features they misunderstood, workflows they got wrong, or capabilities they assumed existed. The difference with AI? No hurt feelings when you make corrections. No defensive explanations about why the documentation says something that’s technically incorrect.

The hallucinations aren’t a bug in the AI process—they’re a feature that mirrors real technical writing workflows. You write, you review, you correct, you ship. The only difference is the AI doesn’t get offended when you strike through three paragraphs about a CLI feature that doesn’t exist yet.

The Prompts That Moved Mountains

Here are the exact prompts that produced the most value:

For Infrastructure:

"Create a professional help center with sidebar navigation, search functionality, and proper IPC integration with the main VoiceCatcher application. Include dark mode support and responsive design."

For Content:

"Write detailed user guide content for [specific section]. Include step-by-step instructions, troubleshooting, pro tips, and practical examples. Make it comprehensive enough for both beginners and advanced users."

For Polish:

"Add comprehensive CSS styling with proper tables, alert boxes, code blocks with copy functionality, and consistent typography that matches the neumorphic design."

The Broader Implications for Solo Builders

1. Scope Expansion is Real

What used to require a team can now be accomplished by one person with AI assistance. But this isn’t just about speed—it’s about maintaining quality while scaling scope.

2. The New Bottleneck is Vision, Not Implementation

The limiting factor is no longer “can I build this?” but “do I know what to build?” Clear requirements and good product sense become more valuable than pure coding ability.

3. Iteration Cycles Compress Dramatically

We went through multiple design iterations, content revisions, and feature additions in real-time. The feedback loop between idea and implementation has collapsed.

4. Production Quality is the New Baseline

There’s no excuse for placeholder content or half-finished features when AI can help you create production-ready implementations quickly.

Tactical Recommendations for Fellow Builders

For Technical Product Managers:

  1. Increase your scope ambitions - What you thought required a team might be a solo evening project
  2. Focus on product definition - Spend more time on user needs, less on implementation concerns
  3. Embrace rapid prototyping - Build real features instead of mockups
  4. Think in complete user journeys - Don’t just build features, build complete experiences

For Engineers:

  1. Learn effective prompting - It’s a skill as important as debugging
  2. Maintain quality standards - AI makes it easy to ship fast, but you still need to ship well
  3. Think systemically - Consider integration points from the start
  4. Document your patterns - What works becomes reusable across projects
  5. Always do tech review - AI hallucinates features just like human writers do

For Solo Builders:

  1. Start with working software - Build real applications, not just demos
  2. Ship complete features - Users notice half-finished experiences
  3. Leverage AI for both code and content - Don’t just automate programming, automate everything
  4. Build on proven patterns - Innovation in user experience, consistency in implementation
  5. Review everything - AI is incredibly productive but still needs human oversight

The New Reality of Software Development

We’re living through a fundamental shift in what’s possible for individual developers. The help system we built represents more than just a feature—it’s a proof point that comprehensive, production-ready software can be created by solo builders working at unprecedented speed.

But speed without direction is just chaos. The real opportunity is for developers who combine AI capabilities with strong product sense, clear vision, and relentless focus on user value.

The question isn’t whether AI will change software development—it already has. The question is whether you’ll adapt your approach to leverage these new capabilities.

Twenty years ago, spending two weeks on a help system demonstrated dedication and skill. Today, spending two hours and shipping something better demonstrates adaptation and leverage.

The future belongs to builders who understand both.


This help system was built during a single episode of The Sopranos. Tony Soprano’s problems didn’t get solved that quickly, but software problems increasingly do. The full implementation is available in the VoiceCatcher repository for anyone who wants to see how it’s done.