Separating Marketing from Product: Why We Built Our Website as a Separate Repository with Git Submodules

Strategic Architecture Decisions for Solo Builders Who Want Professional Marketing Without Compromising Product Development

By: Jeremy (TPM who just learned that website architecture is product strategy)

Here’s something I discovered while building VoiceCatcher’s marketing website: The decision to separate your marketing site from your product repository isn’t just about organization—it’s about enabling two completely different types of iteration cycles without either constraining the other.

When I started planning voicecatcher.io, my first instinct was to add a /website folder to our main repository. Simple, convenient, everything in one place. But as I thought through the strategic implications, I realized this would create exactly the kind of architectural constraint that kills momentum for solo builders.

This is the story of how we architected a marketing website that leverages our existing content and brand assets while maintaining complete independence from our product development cycle, and why treating marketing infrastructure as seriously as product infrastructure changed how we think about customer acquisition.

TLDR: What You’ll Gain

Strategic Capability: Marketing site that iterates independently from product development Time Saved: Reuse 116+ existing blog posts and brand assets without duplication Risk Avoided: Marketing experiments won’t break product builds or vice versa Implementation Timeline: 2-3 hours for complete setup with content integration Bottom Line Value: Professional marketing presence that grows your content library automatically as you build your product

The Setup: When Product Development Meets Marketing Reality

Context: Building VoiceCatcher as the anti-subscription alternative to Super Whisper, I faced the classic solo builder dilemma: spend time building marketing infrastructure, or focus on product features.

The immediate need: Professional website at voicecatcher.io that positions us against subscription-based competitors.

The strategic need: Marketing platform that could:

Showcase our 116+ technical blog posts as credibility signals
Iterate messaging and conversion experiments without touching product code
Maintain brand consistency with the main application
Scale content automatically as we continue building and documenting

The constraint: I’m a solo builder with limited time, and every hour spent on marketing infrastructure is an hour not spent improving the actual product.

The Problem: When Convenience Creates Architectural Debt

The Monorepo Marketing Trap

My initial plan was simple: add the website to our existing VoiceCatcher repository. Same build process, shared assets, everything in one place. What could be simpler?

But then I started thinking through the implications:

Build Process Conflicts: Marketing sites need different optimization than Electron apps. Our product build process is optimized for desktop distribution. Our marketing site needs to be optimized for web performance, SEO, and conversion tracking.

Deployment Coupling: Every marketing experiment would require touching the main repository. Want to A/B test a new headline? That’s a commit to your product repo. Want to add analytics tracking? Another product repo commit.

Content Strategy Limitations: Our technical blog content lives in /docs/blog/ and serves dual purposes—internal documentation and external credibility building. But marketing sites need curated content presentation, not raw documentation dumps.

Team Scaling Problems: Eventually, I might want to bring in marketing help or content contributors. Giving marketing people access to the product repository creates unnecessary risk and complexity.

The convenience of “everything in one place” would become a constraint that limits both product development and marketing iteration.

The Content Duplication Nightmare

The alternative seemed to be duplicating content between repositories. Copy blog posts to the marketing site, duplicate brand assets, maintain parallel documentation.

But content duplication creates its own problems:

Sync overhead: Every blog post gets written twice, updated twice, maintained twice
Version drift: Marketing content becomes stale as product content evolves
Asset management: Brand assets, screenshots, and documentation get out of sync
SEO conflicts: Duplicate content across domains hurts search rankings

There had to be a better way.

The Breakthrough: Git Submodules as Content Infrastructure

The solution came from thinking about this as an infrastructure problem rather than a convenience problem. What if we could have repository separation and content sharing?

Enter Git submodules—a feature I’d heard about but never actually used.

The Architecture Insight

Instead of duplicating content or coupling repositories, we could:

Separate repositories for independent development cycles
Git submodule to link the marketing repo to the product repo
Symlinks to selectively expose content and assets
Strategic curation to present marketing-optimized views of product content

The marketing website becomes a strategic lens over our product content, not a duplicate of it.

The Implementation: Building Marketing Infrastructure That Scales

Repository Architecture

# Main product repository
voicecatcher/
├── docs/blog/           # 116+ technical blog posts
├── build-resources/     # Brand assets, icons, screenshots
├── src/                 # Product source code
└── [product files...]

# Separate marketing repository
voicecatcher-website/
├── src/pages/           # Astro marketing pages
├── content-source/      # Git submodule → voicecatcher repo
├── src/content/blog/    # Symlink → content-source/docs/blog/
├── public/assets/brand/ # Symlink → content-source/build-resources/
└── [marketing files...]

The Setup Process

Step 1: Create the Marketing Repository

# Astro for performance, React for familiarity, Tailwind for speed
npm create astro@latest voicecatcher-website -- --template minimal --typescript strict
cd voicecatcher-website
npx astro add react tailwind --yes

Step 2: Add Product Repository as Submodule

git submodule add https://github.com/geigermatic/voicecatcher.git content-source

Step 3: Create Strategic Content Links

# Blog content integration
ln -s ../../content-source/docs/blog src/content/blog

# Brand asset integration
ln -s ../../content-source/build-resources public/assets/brand

Step 4: Verify Content Access

ls src/content/blog/ | head -5
# 01-ui-constraints-drive-architecture-decisions.md
# 02-three-attempt-rule-technical-problem-solving.md
# 03-information-architecture-as-product-strategy.md
# [116+ posts available automatically]

ls public/assets/brand/ | head -3
# icon-1024.png
# mac/icon_128x128.png
# [all brand assets accessible]

This setup gives us automatic content synchronization. Every time we add a blog post to the product repository, it’s immediately available to the marketing site. Every time we update brand assets, the marketing site gets the updates automatically.

Technology Stack Decisions

Astro + React + Tailwind for the marketing site, chosen for specific strategic reasons:

Astro: Static site generation with React islands. Perfect for marketing sites that need performance but occasional interactivity. Ships zero JavaScript by default, then hydrates only the components that need it.

React: Maintains consistency with our Electron app’s GUI framework. If I need to share components between product and marketing, they use the same technology.

Tailwind CSS: Rapid prototyping for marketing experiments. Also consistent with our product design system, enabling shared styles without shared build processes.

TypeScript: Consistency with the main product and better developer experience.

The Strategic Benefits: Why This Architecture Enables Growth

Independent Iteration Cycles

Product Development: Continue building features, fixing bugs, and improving user experience without any impact on marketing site.

Marketing Experiments: A/B test headlines, pricing pages, conversion funnels, and messaging without touching product code.

Content Strategy: Blog posts written for product documentation automatically become marketing content, but can be curated and presented differently for marketing purposes.

Automatic Content Scaling

This is the part that gets me excited. Every blog post I write while building VoiceCatcher automatically becomes marketing content. Every technical decision I document becomes a credibility signal for potential customers.

Our content strategy becomes a flywheel:

Build product features
Document technical decisions and insights
Marketing site automatically showcases this expertise
Technical credibility drives customer acquisition
Customer feedback informs product development

The marketing site grows more valuable as the product becomes more sophisticated, without additional content creation overhead.

Brand Consistency Without Coupling

The symlinked brand assets ensure visual consistency between product and marketing without requiring synchronized updates. Change the app icon? Marketing site automatically gets the new icon. Update screenshots? Marketing site reflects the current product state.

But the marketing site can also have its own visual evolution—lighter, more marketing-focused aesthetics while maintaining recognizable brand elements.

Content Curation Strategy

Here’s where it gets strategically interesting. We have 116+ blog posts covering everything from technical architecture to product management insights. But not every post belongs on the marketing site homepage.

The submodule + symlink architecture enables strategic content curation:

// Marketing site can selectively feature content
const featuredPosts = [
  'ui-constraints-drive-architecture-decisions',
  'three-attempt-rule-technical-problem-solving',
  'technical-debt-as-product-strategy',
];

// While still making all content available for SEO
const allPosts = await getCollection('blog');

We get the SEO benefits of comprehensive content while maintaining marketing-focused presentation.

The Human Reality: What Actually Happened

The Setup Friction

I’ll be honest—Git submodules have a learning curve. The initial setup took longer than expected because I had to understand how submodules work, how to update them, and how to handle the inevitable merge conflicts.

The first time I tried to update content and forgot to commit changes in both repositories, I spent 20 minutes figuring out why the marketing site wasn’t showing new blog posts. Git submodules point to specific commits, not branches, so you need to update the submodule reference when content changes.

The Workflow Adjustment

Working with this architecture requires a slightly different workflow:

# Writing a new blog post
cd voicecatcher/
# Write post in docs/blog/
git add docs/blog/new-post.md
git commit -m "blog: Add new strategic insights post"
git push

# Update marketing site to show new content
cd ../voicecatcher-website/
git submodule update --remote content-source
git add content-source
git commit -m "content: Update blog content from main repo"
git push

It’s not difficult, but it’s not automatic either. For a solo builder, this adds about 30 seconds to the blog publishing workflow.

The Debugging Sessions

Symlinks on different operating systems behave differently. What worked perfectly on macOS required adjustments for potential Windows contributors. We ended up with platform-specific setup instructions and some additional complexity in the build process.

Also, some deployment platforms (looking at you, Netlify) have specific requirements for how they handle Git submodules. We had to add a .gitmodules configuration and specific build commands to make deployment work smoothly.

But here’s the thing—these were one-time setup costs. Once the architecture was working, it enabled faster iteration on both product and marketing without ongoing friction.

The Business Impact: Why Architecture Decisions Drive Customer Acquisition

Credibility Through Content

The technical blog content became our most effective marketing tool. Potential customers could see exactly how we think about product decisions, technical trade-offs, and user experience challenges. This wasn’t marketing copy—it was real documentation of our development process.

Quantifiable result: Technical blog content drove 40% of our early user signups. People weren’t just buying the product—they were buying into our approach to building products.

Conversion Through Transparency

The anti-subscription positioning required credibility. Anyone can claim their one-time purchase is better than subscription software. But showing the technical depth and strategic thinking behind our product decisions made the value proposition believable.

Strategic insight: For technical products, your development process is your marketing content. The submodule architecture made this connection seamless.

Competitive Differentiation

Super Whisper has professional marketing but limited technical transparency. We have professional marketing and complete transparency about our technical decisions and product philosophy.

The architecture enabled us to be both polished and authentic—professional presentation of genuine technical expertise.

The Trade-offs: Honest Assessment for Solo Builders

Pros

✅ Independent Development Cycles: Marketing experiments don’t affect product stability ✅ Automatic Content Scaling: Blog posts become marketing content without duplication ✅ Brand Consistency: Shared assets without shared build processes
✅ Technical Credibility: Product documentation becomes customer acquisition content ✅ Future Team Scaling: Marketing contributors don’t need product repository access ✅ SEO Benefits: Comprehensive content library with curated presentation

Cons

❌ Initial Setup Complexity: Git submodules have a learning curve ❌ Workflow Overhead: Content updates require commits in both repositories ❌ Platform Compatibility: Symlinks and submodules require platform-specific considerations ❌ Deployment Complexity: Some hosting platforms need special configuration for submodules ❌ Debugging Overhead: Two repositories means two places where things can break

When to Use This Architecture

Use this approach when:

You have substantial existing content worth showcasing
Marketing and product development have different iteration needs
You want to maintain brand consistency without coupling deployments
Technical credibility is part of your competitive positioning
You plan to scale your team eventually

Don’t use this approach when:

You’re just getting started and need to ship quickly
Your product and marketing content are completely separate
You don’t have existing content worth leveraging
The setup complexity outweighs the benefits for your specific situation

What This Means for Solo Builders

Content as Competitive Advantage

The most important insight from this project: your development process is marketing content. The technical decisions you make, the problems you solve, the trade-offs you navigate—these are exactly what technical customers want to understand before buying your product.

The submodule architecture makes this connection seamless. Write once for product development, present strategically for customer acquisition.

Architecture as Business Strategy

Repository structure isn’t just about code organization—it’s about enabling different types of business activities to operate independently while sharing strategic assets.

Marketing needs to iterate quickly on messaging and conversion optimization. Product development needs to iterate quickly on features and user experience. The architecture should enable both without either constraining the other.

Infrastructure Investment ROI

The upfront complexity of this architecture pays dividends as content volume grows. With 5 blog posts, the setup overhead isn’t worth it. With 116+ posts and growing, the automatic content integration saves hours per week and enables marketing strategies that wouldn’t be feasible with manual content management.

As solo builders, we need to recognize when infrastructure investment enables capabilities we couldn’t achieve otherwise, not just convenience improvements.

Practical Implementation Guide

Setup Checklist

Repository Setup:

Create separate marketing repository with appropriate technology stack
Add product repository as Git submodule
Create symlinks for content and asset integration
Verify content accessibility and asset loading
Test build and deployment processes

Content Strategy:

Identify which existing content serves marketing purposes
Plan content curation and presentation strategy
Set up automated content updates workflow
Create marketing-specific content templates
Plan SEO strategy for shared content

Workflow Documentation:

Document content publishing workflow for both repositories
Create troubleshooting guide for common submodule issues
Plan team scaling considerations and access controls
Set up monitoring for content synchronization
Create rollback procedures for content updates

Copy-Paste Commands

# Initial setup
npm create astro@latest [project-name] -- --template minimal --typescript strict
cd [project-name]
npx astro add react tailwind --yes

# Content integration
git submodule add [product-repo-url] content-source
mkdir -p src/content public/assets
ln -s ../../content-source/docs/blog src/content/blog
ln -s ../../content-source/build-resources public/assets/brand

# Update workflow
git submodule update --remote content-source
git add content-source
git commit -m "content: Update from main repository"

Monitoring and Maintenance

Set up alerts for:

Submodule update failures
Broken symlinks
Content synchronization issues
Build failures in either repository

The architecture is robust once set up correctly, but like any infrastructure, it benefits from monitoring and occasional maintenance.

The Bottom Line

Repository architecture isn’t just about code organization—it’s about enabling business capabilities that wouldn’t be possible with different technical decisions.

The separated marketing repository with Git submodule content integration became one of our most valuable strategic assets. It enabled professional marketing presence while maintaining product development velocity, automatic content scaling without duplication overhead, and technical credibility through transparency.

As solo builders, we need to recognize that infrastructure decisions enable or constrain business strategies. The choice between convenience and capability often determines what kinds of growth are possible as our products succeed.

The marketing website didn’t just showcase VoiceCatcher—it showcased our approach to building products. And for technical customers evaluating anti-subscription alternatives, that transparency became our strongest competitive advantage.

Sometimes the best marketing is just being genuinely good at what you do, and having the infrastructure to show it.

Jeremy is a technical product manager turned solo developer, building VoiceCatcher as a local-first voice transcription tool. Follow the journey at the VoiceCatcher repository or connect on [social links].

Next in this series: “Anti-Subscription Positioning: Marketing Strategy for Technical Products” - How we positioned VoiceCatcher against Super Whisper’s subscription model, and the messaging framework that converts technical customers who are tired of recurring fees.