18,000 Lines of Code to Replace a Screenshot

Before I get into why I wrote 18,000 lines of code to avoid taking a screenshot, let me tell you about the most tedious part of product marketing, the part that nobody ever talks about.

Keeping product imagery up to date.

Product imagery isn't just screenshots. It's screenshots for the website. PNGs for the docs. GIFs for the emails. Different GIFs for social posts. Videos for the landing page hero. An OG image so link previews don't look like garbage, and every single one of these needs to be updated every time you change the UI.

You know the dance. Take a screenshot, spend 20 minutes getting it cropped just right, realize you need one with the dark theme too, do the whole thing again, then export a GIF version for the email, then a square crop for Twitter, then a 16:9 for LinkedIn, and then a week later you ship a UI update and every single one of those assets is wrong.

That thing has a name. It's called asset debt, and I just made that term up, but honestly it should be a real term because the surface area is way bigger than people think. It's not one screenshot. It's dozens of assets across the website, docs, emails, social, and OG images... all going stale the moment you ship a UI update.

And that's just the maintenance side. The creation side is just as painful. Every new GIF means opening the app, setting it up in exactly the right state, populating it with realistic-looking content, hitting record, getting the timing right, watching the recording back, realizing the timing was wrong, re-recording, cropping, exporting for the right platform, then doing it all again at a different aspect ratio. It's a 30-minute process for a single asset. Need four formats? That's your afternoon.

There's two of us at Blueberry. I focus on growth, Renato on the product. Which means every hour spent on manual busywork is an hour we don't have. So when I caught myself doing this dance for the third time in our first month... Renato redesigns something in the app, we feel great about it, ship it, then realize every visual asset across the website, docs, emails, and social is now out of date... I stopped and asked a different question.

Not "how do I update the assets faster?" but "how do I never have to do this again?"

When there's two of you, you can't afford to think in tasks. You have to think in systems.

Every manual process you repeat is a process you should be asking: can this be automated? Can this be eliminated? Because you don't have a team of 20 to absorb the overhead. The things that don't scale will eat you alive.

What if, and stay with me here, I just didn't use screenshots at all? What if every single image of the app on the website was a real, rendered React component?

Not a screenshot. Not a Figma export. Not a carefully cropped PNG that will be wrong by next Tuesday. An actual component that uses the same design tokens, the same colors, the same layout logic as the real app. When the app changes, the website changes. Automatically. Everywhere.

My immediate reaction was somewhere between "that's genius" and "I need to go outside more." Both were valid.

To pull it off, I'd need to rebuild every panel of the app as a standalone component. Terminal, editor, file tree, preview browser, source control, the works. A design token system to keep it all in sync. Scripted animations for the demos. Dialogs, settings panels, a music player, even a phone frame for mobile mockups, and a way to capture all of it as GIFs, PNGs, and MP4s for the places where you can't embed React. Emails. Social media. OG images.

So that's exactly what I built.

The system has six layers, and honestly, each layer is where you go "OK that's reasonable" and then see the next one and go "wait, you did what?"

Layer 1: The Design Tokens

Everything starts with design-tokens.ts, 205 lines that define the entire visual language. Colors in OKLCH (perceptually uniform, so gradients look natural), typography scales using Geist Sans and Geist Mono, spacing constants, animation curves with spring physics configs, 8 wallpaper theme presets, and mockup defaults for desktop (960×600) and mobile (375×812).

When we change a color in the real app, I update one file and every mockup on the website, in the docs, in the emails, everywhere, picks it up. That's the whole point.

Layer 2: The Panel Components

Each panel of the real Blueberry IDE has a corresponding mock component, and when I say "mock," I don't mean a grey box with some text in it. These are accurate enough that even I've confused them for screenshots of the actual app. That's the bar. If it looks "mocked up," the illusion breaks.

Here's the terminal component. I want to be very clear: this is not a screenshot. This is a live React component rendering in your browser right now. Click the tabs. Hover around. It's real.

Live Component - TerminalCard

Claude

Codex

Gemini

Server

✻

|

▟█▙

▐▛███▜▌

▝▜█████▛▘

▘▘ ▝▝

Claude Code v2.1.45

Opus 4.6 · Claude Max

~/apps/blueberry-website

 

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

❯ Try "how does route.ts work?"

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

? for short

╭─────────────────────────────────────────────╮

│ >_ OpenAI Codex (v0.104.0) │

│ │

│ model: gpt-5.3-codex /model to change │

│ directory: ~/apps/blueberry-website │

╰─────────────────────────────────────────────╯

 

› Implement {feature}

 

? for shortcuts 100% context left

███ █████████

░░░███ ███░░░░░███

░░░███ ███ ░░░

░░░███░███

███░ ░███ █████

███░ ░░███ ░░███

███░ ░░█████████

░░░ ░░░░░░░░░

 

Logged in with Google: user@example.com /auth

Plan: Gemini Code Assist for individuals

 

? for shortcuts

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

shift+tab to accept edits

 

- 1 GEMINI.md file

- 1 MCP server

- 7 skills

▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

> Type your message or @path/to/file

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

blueberry-websiteno/model Auto

(mockup-generator*)sandbox(Gemini 3)

andrew@MacBook-Pro ~/apps/blueberry-website (mockup-generator) $ npm run dev

 

> blueberry-website@0.1.0 dev

> next dev

 

▲ Next.js 16.1.4 (Turbopack)

- Local: http://localhost:3000

- Network: http://192.168.1.67:3000

- Environments: .env.local

- Experiments (use with caution):

· optimizePackageImports

 

✓ Starting...

✓ Ready in 3s

GET /mockups 200 in 634ms (compile: 428ms, render: 206ms)

Here's the full roster:

• MockTerminal (1,483 lines)
  Full terminal emulation with Dracula colors, ANSI 256-color palette, 4 CLI presets (Claude, Codex, Gemini, and dev server), blinking cursor at exactly the right cadence, interactive tabs you can add/close/reorder, and a running-process indicator that pulses green.
• MockEditor (1,127 lines)
  Custom syntax highlighting with tokenization for TSX, CSS, and JSON. No libraries, hand-rolled tokenizer with Monaco-inspired colors. File tabs, line numbers, breadcrumb navigation, expandable sidebar with file tree and source control view.
• MockFileTree (585 lines)
  Expandable folder tree with git status indicators. Modified files get a yellow badge. Untracked files get green. Deleted files get red. Because obviously.
• MockPreview (642 lines)
  Browser preview panel with a URL bar, dev tools inspector toggle, and responsive content rendering.
• MockSourceControl (900 lines)
  Git staging UI with staged/unstaged sections, diffs, commit message input, branch display, and ahead/behind indicators.
• MockSearchPanel (414 lines)
  Full-text search with results, match highlighting, line numbers, and a case sensitivity toggle that actually toggles.
• MockCommandCenter (934 lines)
  Command palette overlay with fuzzy search and keyboard navigation. Because if you're going to over-engineer something, commit to it.
• MockElementPicker (300 lines)
  Browser element inspector with hover highlights and clickable selection. For when you need to show the dev tools experience.
• MockCodeArea (541 lines)
  Lightweight code viewer for when you need syntax highlighting without the full editor bloat.
• MockEmptyState (164 lines)
  The empty workspace home screen with a search bar and keyboard shortcut hints.
• MockPinnedApp (123 lines)
  Pinned app content area with header chrome (favicon, title, navigation buttons).
• MockPinnedAppContent (1,140 lines)
  Eight mock pinned apps: Vercel (deployments), GitHub (PR view), Slack (chat), Supabase (table editor), Linear (ticket), Figma (design file with canvas), Notion (page), and PostHog (analytics dashboard). Each one styled to match the real app's dark theme. Click any pinned app icon in the sidebar above to see them.

Every single one of these pulls from the same design-tokens.ts file. When we change a color in the real app, the website components will pick it up. That's the whole point.

Live components are great for the website and docs. They render inline and stay up-to-date automatically. But the website is only one of the places we need these visuals.

Emails need GIFs. Social posts need GIFs and videos. OG images need static PNGs. You can't embed a React component in any of these. LinkedIn doesn't support interactive content, because of course it doesn't.

So I built a full media generation pipeline. It's a dedicated page in the site that renders any mockup component and captures it frame-by-frame, then encodes the frames into GIFs, MP4s, WebMs, or PNGs using a Web Worker so the UI doesn't freeze during encoding.

One system, every format, every destination:

• Website & docs. Live React components render inline, always up-to-date
• Emails. Animated GIFs generated from the same components
• Social media. GIFs and MP4s with platform-specific aspect ratios (1:1 square for Twitter, 4:5 portrait for Instagram, 16:9 for LinkedIn, 9:16 story)
• OG images. Static PNG snapshots for link previews
• Videos. MP4 and WebM exports for landing page heroes and demos

And the pipeline itself handles:

• Custom FPS. 4 to 60 frames per second
• Duration control. Capture for exactly as long as the animation loop needs
• Trim & loop modes. Infinite loop, play-once, or pingpong (which is surprisingly useful for subtle UI animations)
• Batch generation. Queue up "Website Hero GIF," "Email Header GIF," "Social 1:1 Terminal," "OG Image PNG," and "Landing Page MP4" and export them all in one go

The memory management alone is its own little engineering project. A 500MB frame buffer budget, ImageData reuse to avoid garbage collection pressure, and a dedicated thumbnail canvas that persists across calls. The initial implementation used 1.2GB for a 10-second 60fps capture at 1920×1080. I got it down to 500MB through a ring buffer that reuses ImageData objects, a downsampled preview canvas (¼ resolution), and lazy GIF palette quantization in a Web Worker.

But here's the thing that surprised me most: the system is even more valuable for creating assets than for maintaining them. Need a GIF of the terminal running Claude Code for a tweet? <TerminalCard presets={["claude"]} />, hit capture, done. Need a 9:16 story showing the worktree feature? Point the pipeline at the WorktreeDemo, set the aspect ratio, export. A new asset that used to take 30 minutes is now a one-liner and a button click.

Change something in the app, re-run the batch, and every asset across the website, docs, emails, social, and OG images updates in minutes. Not hours. Not days. Minutes.

OK so writing 18,000+ lines of code for marketing screenshots sounds ridiculous. I get it. Two years ago, this would have been a hard no even with a full team. The conversation would have gone something like this:

"I want to rebuild every panel of my app as a standalone component, create a design token system, build scripted cursor animations, add a settings dialog, a music player, phone frames for mobile mockups, and a GIF capture pipeline."

"How long?"

"Three months, maybe four."

"For... screenshots?"

"...Yes."

"Hell No!"

And that would have been the right call! Three months of engineering time, especially when there's two of you, to solve a problem you can hack around with a screenshot and a Figma file? The ROI doesn't work. Not even close.

But the math has changed.

With AI-assisted development, this entire system, 51 files, 18,000+ lines, the whole pipeline, took me about two days of focused work. Not two days of planning and three months of building. Two days, start to finish.

The design tokens were extracted from the real codebase in an afternoon. The mock components were built iteratively with Claude reviewing the actual source components and generating pixel-accurate replicas. Not screenshots, the real source code, so it understood structure, not just appearance. The cursor animations, the ones with the millisecond timing and the typing speed debates, were choreographed through a conversational back-and-forth that would have taken a week of manual keyframing. The dialog components, the music panel, the card wrappers, all of it emerged from the same iterative loop: hand it the source, get a mockup, refine until indistinguishable.

Two days of work for a system that saves us every single time we update the product. The app, the website, the docs, the emails, the social posts, all of it. No more screenshot sessions. No more "did we update the email GIFs?" No more finding stale imagery in the docs three months later. No more manually exporting social assets at four different aspect ratios. The website, the docs, the emails, the social imagery, the OG images... all of it stays in sync because it's all generated from the same components.

And yes, you can argue this was a stupid use of time pre-product-market-fit. Fair. But it was also genuinely fun, and sometimes you need that too. Not everything has to be a cold ROI calculation. Sometimes you build something because the craft itself is energising, and that energy carries into everything else you ship.

That's not over-engineering. That's just engineering, done at a speed that makes the ROI work for the first time.

And that's really the thesis of this whole blog. AI doesn't just speed things up. It moves the line of what's worth building.

When there's two of you, you learn to think in systems very quickly. Every process that repeats is a process that should be automated. Every manual step is a future bottleneck. You don't have the luxury of throwing people at problems, so you throw systems at them instead.

The problem is, building those systems used to be its own massive investment. The internal tool that would save 20 minutes a day but take 6 weeks to build. The test harness that would catch edge cases but requires mocking half the system. The design system that would make everything consistent but nobody has time to extract the tokens. You could see the system you should build, but you couldn't justify the time.

Those ideas are all back on the table.

What used to be a 3-month project is a 2-day project now, and the calculus is completely different. A 2-day investment that saves you 4 hours every month for the lifetime of your product? That's a no-brainer. The exact same investment at 3 months? You'd never approve it. For a two-person team, this is transformative. You can finally build the infrastructure that lets you operate like a team of 20.

The tools haven't changed what's possible. They've changed what's practical, and for tiny teams especially, that distinction is everything.

The heavy lifting is done. We're not going deeper down this rabbit hole. The system does what it needs to do. But we'll keep making small improvements as the app evolves. New features in Blueberry get new mockup components. The design tokens stay in sync. Maybe I'll add keystroke sounds to the terminal animations, because the cost of trying is about 20 minutes of work now and can be run in parallel with other work, so why not?

That's kind of the whole point. When the cost of building drops by 100x, the definition of "worth building" expands dramatically, and when the cost of maintaining drops too, because the system is designed to evolve with the product, you stop thinking about it as a project and start thinking about it as infrastructure.

Welcome to Over-Engineered. This is the first of many stories about things that would have been a bad idea two years ago and are a great idea now. If you're the kind of person who builds a working music player inside a mockup of your own IDE, you're in the right place.

One last thing. None of this would be possible without the incredible work Renato has done on the product itself. I'm just building mockups of what he's built for real. If you like what you see in these demos, you should try the actual thing. It's next level.