AI SEO Analytics Dashboard
Personal Project · B2B · Product Design · AI-Augmented Workflow
Completed: June 2026 · Built with Next.js, Tailwind CSS, Vercel
Summary
I built a four-page B2B SEO analytics dashboard from a blank repo to a deployed product, including a custom Figma plugin pipeline for component generation. The original goal was simple: prove that an AI-native workflow could compress a multi-week process. What actually happened was different, and more useful. The hardest part of building with AI is not generating output fast enough. It is knowing when to stop automating and start owning the work yourself.
All pages : Dashboard, AI Visibility, Content Ops, Search Visibility. Shows the full scope of what shipped and the visual consistency across a product built in stages with multiple tools.
Deep Dive
Starting with speed
The first edition was the most straightforward. I wrote a brief, used v0 to generate the initial dashboard layout, and had a working prototype on Vercel within days. The Dashboard page had stat cards, a keyword ranking table, a contextual detail sidebar, bulk actions, sorting, and skeleton loading states. It was functional, it looked right, and I had moved fast because I was not writing repetitive UI code by hand. AI handled the structure. I made the design decisions.
That speed created an assumption I would spend the next several editions testing: that the rest of the workflow could be automated at the same pace.
Five editions spent on a problem that cannot be solved
After the prototype was stable, I wanted to bring the design system into Figma for layout planning and design expansion. The plan was to automate the link between code and canvas so that token changes in CSS would propagate to Figma components automatically.
This took five editions and produced results I did not expect. The Figma MCP server required Enterprise API access. Windsurf hallucinated fixes repeatedly. The setBoundVariableForLayout function I was using had been deprecated without documentation. At the component level, the gap between Figma and a live Next.js product is structural: Figma components are static, the live product is dynamic, and every product change creates new drift that costs the same manual effort to close regardless of how good the plugin is.
By Edition 05, I had a usable atom and molecule library in Figma, built by a custom plugin that generated components from a JSON config with full token binding. I also had an honest answer to the question I had been avoiding: automated code-to-Figma sync at component level is not a solvable problem with current tooling. It is a gap to manage, not eliminate.
2a. Plugin panel alongside the generated Figma component set. The atomic generator built in Edition 04, on top of color and typography variable systems from the two editions before it. A JSON config goes in, bound atom variants come out on the Figma canvas.
Changing the strategy
In Edition 06 I stopped trying to keep Figma in sync with code and started using Figma differently. Instead of automating the canvas, I wrote DESIGN_SYSTEM.md: a structured reference covering all color tokens, typography utilities, the full component inventory, and prompting conventions. Then I used Lovable to generate a new page from that document.
Lovable connected to my GitHub repo and read the entire codebase. Its output used TanStack routing instead of Next.js, shadcn token defaults instead of my custom tokens, and wrong layout constraints throughout. The reason: Lovable's internal runtime is TanStack Start. Reading a Next.js codebase does not change what framework it executes against. The document was well-prepared. The workflow assumption was wrong.
The correction pass that followed was the most clarifying work in the project. Rewiring Next.js App Router, replacing every shadcn token, redesigning the Coverage Matrix to replace a chart that was duplicating data from another page: this was the work that required understanding the system deeply enough to know what was wrong and why. DESIGN_SYSTEM.md did not eliminate that pass. It made it faster and more confident.
Lovable raw output vs. corrected page The visual difference is small. The structural difference underneath is everything: TanStack routing rewired to Next.js App Router, every shadcn token replaced with the correct project value.
Building without generation
Edition 07 I built the Content Ops page without Lovable. No generation step, no correction pass: just direct component work in the codebase. It shipped faster than the Lovable-generated page and with fewer errors.
More importantly, building it forced me to look at the product as a whole rather than page by page. Platform colors were colliding with semantic status tokens. The same citation data was being visualized twice across two different pages. Two pages were computing the same optimization metric with different formulas. None of this was visible while working in isolation. It became visible only when I stepped back and treated the product as a system.
Fixing it meant centralizing platform constants into a shared module, replacing a chart that was not earning its space with a view that answered a different question, and unifying the calculation so every page showed the same number for the same thing. None of that work is visible at first glance. But inconsistency in a tool that people use to make decisions erodes trust faster than missing features.
Critical Reflection
I spent three editions trying to automate something that cannot be automated at component level, and that was not wasted time. The plugin work produced a real Figma library I used for layout planning throughout the project. But the more durable value was understanding. I know exactly why Figma and production code drift apart. I know which parts of that problem tooling can address and which parts are structural. I know this because I hit every wall personally.
What I would do differently: start with the design system document in Edition 01 instead of Edition 06. As a solo designer building for portfolio purposes, the better investment earlier would have been documentation that made AI-assisted generation more reliable. The automation came from trying to solve the wrong version of the problem first.
The other thing I underestimated: consistency is the product. Every shortcut taken during early development accumulated as debt that had to be paid back at the system level, not the page level. That kind of work is slow and invisible. It is also what separates a collection of pages from an actual product.
Conclusion
Achieved: Four-page B2B SEO analytics dashboard deployed on Vercel. Custom Figma plugin pipeline generating atoms and molecules from JSON config with full token binding. DESIGN_SYSTEM.md as a living reference for consistent AI-assisted expansion. Platform color system centralized. Data visualization redesigned so each view answers a question no other view answers.
New tools shipped while I was building this. New approaches appeared before the previous ones were fully tested. There is no final answer with AI, only a current one. This is a record of what the current answer looked like across seven editions