From 500 Lines to 7000+ Lines: How I Accidentally Built a Design System (And Why It’s Moving to Private CDN)

Hello everyone, It’s Lee Cuong again! Today I’m sharing something that… well, let me be honest, this got way more complicated than I expected as a non-tech Product Guy. What started as a simple style guide for consistency turned into a 7,000-line monster that’s making AI agents sweat. Here’s the wild journey and why I am going full Cloudflare CDN on this thing.

🤔 The Problem: When Your UI Looks Like It Build by Multiple Coders

Picture this: I’m working on my thesis app, my SARI survey platform for my master’s thesis, my interview prep tools… and each one looks like 5 different people designed it. Actually, scratch that; it looks like 5 different people who’ve never met each other and have wildly different taste in colors and styles.

One part has blue buttons, another has slightly different blue buttons (because I forgot the exact hex code), the third one… let’s just say it involved a lot of “this looks close enough” decisions. It was giving me serious “developer aesthetic” vibe, functional but definitely not winning any design awards.

I knew I needed consistency. “Probably just need to create a style guide,” I thought. How hard could it be?

The Beginning: “Just 500 Lines, How Hard Can It Be?”

So there I was, thinking like a smart Product Manager: “Let me create a simple style guide with some buttons, colors, and forms. Maybe 500 lines of CSS max. I need this for my current and future web apps since I am not so happy with the results of Claude and Codex shipped using the made up css or event the shadcn styles.”

This reminds me of my 4-hour vibe coding journey – you know, those times when you think something will be quick and simple, then suddenly you’re 6 hours deep in a rabbit hole learning about CSS variables, bug fixings and wondering how you got there.

My original plan was beautifully simple (and beautifully naive):

• Define some colors (primary, secondary, success, error)
• Survey components
• Create button styles
• Add form components
• Done! Ship it!
• But then after 2 hours in, I proceeds to ignore this plan completely

What I Actually Built (1st day on Friday):

/* The humble beginning */
:root {
  --primary-color: #3b82f6;
  --secondary-color: #6b7280;
}

.btn-primary {
  background: var(--primary-color);
  padding: 8px 16px;
  border-radius: 4px;
}

Looking back… this was like saying, “I’ll just learn basic English” and ending up fluent in 3 languages plus accidentally becoming a linguistics professor. The scope creep was real, and it had a sense of humor.

Day 2: “Okay, Maybe I Need Dark Mode Too…”

You know how it is, you build something basic, then you see other design systems online and think “Hmm, mine could use dark mode too…” It’s like looking at your neighbor’s perfectly manicured lawn and suddenly deciding your lawn needs a complete landscaping overhaul.

Then you add:

• Dark mode variables
• Better typography scale
• Responsive breakpoints
• Form validation states
• Loading states
• Hover effects
• Focus states

File size tracker:

• Day 1: 500 lines ✅
• Day 2: 1,200 lines 😅

At this point, I confidently thought I was doing the right thing. “Professional design systems have all this stuff,” I told myself. Classic case of “fake it till you make it” except I was faking it to myself. Very convincingly, I might add.

Day 3: “Let Me Add Some Components…”

This is where things got… interesting. I started looking at my actual apps and thinking “Oh, I should probably make these components reusable too.” The list grew faster than my grocery bill:

• Cards (like, 8 different variations because apparently I’m very indecisive)
• Data tables (responsive, sortable, filterable – because basic tables are for quitters)
• Modals and dialogs
• Navigation components
• Toast notifications (because users need to know EVERYTHING)
• Progress indicators
• Breadcrumbs
• Pagination
• Tabs
• Accordion
• Tooltips

At this point, I was basically trying to recreate the entire internet in CSS. Arhh… so tham lam me.

PlantUML Diagram – The Expansion:

File size tracker:

• Day 1: 500 lines ✅
• Day 2: 1,200 lines 😅
• Day 3: 3,500 lines 😰

Why does it keep growing? It’s like feeding a digital pet that only eats CSS and gets bigger with every meal.

Day 4-6: Full-Blown Design System Architect Mode

This is when I completely lost control while working with such a smart AI like Codex 5 High. I discovered CSS custom properties, HSL color functions, and… accessibility guidelines. It was like opening Pandora’s box, except instead of releasing evil into the world, I released an obsession with perfectly organized CSS architecture.

You know, this experience perfectly embodies what I wrote about in AI agents being tools in a loop – the AI wasn’t making me over-engineer, but it was enabling me to explore possibilities I never would have considered on my own. Every suggestion led to “oh, what about this too?” in an endless cycle of improvement.

Suddenly I’m implementing:

• WCAG 2.1 AA compliance (because why not be professional from beginning?)
• CSS logical properties (for international support)
• 3-layer architecture (CSS vars → Tailwind → Components)
• Semantic color system (not just “blue” but “primary-50” through “primary-950”)
• Mobile-first responsive design (44px+ touch targets)
• Focus management (keyboard navigation support)
• Animation system (smooth transitions and micro-interactions)

A Snippet of The Architecture I Actually Built:

/* Layer 1: Design Tokens */
:root {
  --color-primary-hsl: 217 91% 60%;
  --color-primary-50: hsl(var(--color-primary-hsl) / 0.05);
  --color-primary-500: hsl(var(--color-primary-hsl) / 1);
  /* ...45 more color variations */
}

/* Layer 2: Component Base */
.btn {
  /* 47 lines of button foundation */
}

/* Layer 3: Component Variants */
.btn-primary {
  /* 23 lines of primary button styles */
}

Image Prompt: Vietnamese developer sitting in front of massive wall-mounted display showing complex CSS architecture diagram, looking like a mad scientist with coffee cups stacked everywhere, traditional Vietnamese study setup with books and family photos

File size tracker:

• Day 1: 500 lines ✅
• Day 2: 1,200 lines 😅
• Day 3: 3,500 lines 😰
• Day 4-6: 7,000+ lines 🤯

At this point, I realized I wasn’t building a simple style guide anymore. I’m building an enterprise-level design system, and I’m not an enterprise. Just a solo wannabe dev with delusions of grandeur and way too much free time on weekends.

The AI Agent Performance Problem

Here’s where things got SO real. I’m using AI agents (Gemini, Claude, Codex, Kiro AWS) to help with development, and I noticed they started getting… slow. Really slow, plus being back and forth with the same message.

Before (500 lines):

• AI reads file: 4 seconds ⚡
• Generates component: 5 seconds ⚡
• Makes changes: Instant ⚡

After (7,000+ lines):

• AI reads file: 15 seconds 🐌
• Generates component: 30 seconds 🐌
• Makes changes: “Please wait…Thinking…” 🐌
• Sometimes: “Thinking sooo long” 💀
• Me: nervously refreshing the page wondering if I broke the AI

The Problem: My styleguide-enhanced.html became this massive monolithic file that even AI agents struggled to process. It was like asking someone to read the entire Lord of the Rings trilogy to answer “What color is Frodo’s shirt?” The poor AIs were probably having existential crises trying to parse my CSS masterpiece.

That’s when I knew: this beautiful, comprehensive design system needed a new home other than my Mac.

The Research Phase: “How Do Real Teams and Companies Do This?”

I spent 3 hours researching how actual design systems work (okay, it was more like 6 hours because I kept getting distracted by cool design system websites), and found a few approaches:

Option 1: npm Package Approach

• Publish design system as npm package
• Apps install via npm install @cuong/sari-design-system
• Update by publishing new versions

Pros: Standard approach, version control
Cons: Manual updates, npm publishing overhead, I don’t know how to make packages yet (and honestly, npm scares me a little)

Option 2: Design Tokens + Build System

• Extract design tokens to JSON
• Use Figma/Tokens Studio workflow
• Build system generates CSS

Pros: Industry standard, tool integration
Cons: Too complex for one person, need design tools (and I’m barely managing CSS, let alone Figma workflows)

Option 3: Monorepo with Submodules

• Git submodules for shared components
• Each project includes as dependency

Pros: Git-native, good for teams
Cons: Submodule management is painful, still manual updates

PlantUML Diagram, The Decision Tree:

This decision-making process reminds me of what I discussed in diagrams and AI for product teams – sometimes visual thinking through PlantUML helps clarify the complexity and trade-offs better than endless text descriptions.

The Tick Happened: “Wait, What About CDN?”

During that late-night coding session (fueled by iced coffee and pure stubbornness), I had this random thought: “What if I just… put it on a CDN?” Sometimes the best ideas come when your brain is too tired to overthink them. This came from a few times when vibe coding I saw the Ai just install from npm this and npm that…

The idea was simple:

1. Host styleguide.html on private Cloudflare Pages
2. GitHub Actions auto-deploy when I edit
3. All apps load from CDN with API key
4. Edit styleguide → Everything updates instantly

Wait… this could actually work! Famous last words part 2, but this time with more confidence and caffeine.

The Vision:

<!-- In any project -->
<link rel="stylesheet" href="https://design.nlcuong85.com/sari-design-system.css?key=SECRET_KEY">

<!-- That's it. Instant access to latest design system build be me. -->

The Cloudflare CDN Solution: Design System as a Service

I do have some familiarity with Cloudflare, especially the Tunnels thing since I have host most of my stuff thru it for convience, don’t judge me, if I am famous and well-known with lots of traffic to my sites I will move to something more robust.

After talking it through with AI agents (the ones that weren’t struggling with my 7,000-line file), we designed this architecture:

Phase 1: Private Repository Setup

# New private repo structure
sari-design-system/
├── styleguide.html              # Source of truth (move from current repo)
├── build/
│   ├── extract-tokens.js        # Auto-extract from styleguide
│   ├── build-css.js            # Generate distributable CSS
│   └── build-api.js            # Create JSON APIs
├── dist/                       # Auto-generated CDN files
│   ├── sari-design-system.css  # Main stylesheet
│   └── api/
│       ├── tokens.json          # For AI agents
│       ├── colors.json          # Color-specific API
│       └── components.json      # Component specifications
└── .github/workflows/deploy.yml # Auto-deployment

Phase 2: Automation Pipeline

The Magic Workflow:

# When I edit styleguide.html:
on:
  push:
    paths: ['styleguide.html']

# GitHub Actions automatically:
1. Extracts design tokens to JSON
2. Builds distributable CSS
3. Deploys to Cloudflare Pages
4. Updates all consuming apps instantly

Phase 3: Private CDN with API Authentication

// Cloudflare Worker for security
if (apiKey !== env.SARI_API_KEY) {
  return new Response('Unauthorized', { status: 401 });
}
// Only I can access my design system, it's my precious!

Why This Solution is Perfect for Solo Developers and Indie Devs?

For Big Companies: Design systems need design teams, Figma integration, component libraries, documentation sites, etc.

For Me (Solo WANNABE Developer): I need something that:

• ✅ Keeps my styleguide.html as source of truth (I love working on 1 file)
• ✅ Updates all projects instantly (no manual steps)
• ✅ Stays private (not open source, just for my projects, period!)
• ✅ Works with AI agents (JSON APIs for programmatic access)
• ✅ Requires zero maintenance (GitHub Actions handles everything)

This approach scales from 1 project to 100 projects but hopefully doesn’t require me to become a DevOps engineer. Because let’s be honest, I’m still figuring out how to properly center divs.

The Implementation Reality Check

Let me be honest about what this actually involves:

What I Need to Learn:

• GitHub Actions workflows (never written one before – but hey, I have AI agents so… how hard can it be?)
• Cloudflare Pages deployment (never used Cloudflare Pages before, but I’m feeling adventurous)
• API key authentication (security stuff makes me nervous – I had bad memories with APIs as a PM where everything broke in production)
• CSS extraction scripts (JavaScript + CSS parsing – basically teaching a robot to read my messy CSS handwriting)

Time Investment:

• Phase 1 (Repository setup): 1-2 hours 🟢
• Phase 2 (Automation pipeline): 2-3 hours 🟡
• Phase 3 (CDN deployment): 1-2 hours 🟢

Total: 4-7 hours (Spread over weekends). This is just an estimation, not sure how it will take in reality.

The Learning Curve:

Look, I’m not gonna lie. Six months ago, I was still a non-tech guy. Now I’m talking about private CDNs and GitHub Actions like I’ve been doing DevOps for 5 years. It’s like when you watch one cooking show and suddenly you’re explaining the importance of mise en place to your friends. This is all thanks to Ai coders… without them I guess I would just being non-tech for the rest of my carreer I guess.

But here’s the thing: you don’t need to be a coding expert to build cool stuff. You just need to be willing to learn, ask good questions, and not be afraid to fail spectacularly in front of your computer screen at 2 AM.

This connects directly to my journey from Raspberry Pi scripts to AI agents, the willingness to experiment and learn iteratively is what transforms simple projects into comprehensive systems, whether it’s hardware tinkering or CSS architecture.

What This Means for My Future Projects

Before (The Pain):

# Starting new project
1. Copy CSS from old project, or letting the Ai agents make it up
2. Manually update colors to match
3. Fix broken components while burning tokens
4. Add missing styles
5. Repeat for every project 😭

After (The Magic), hopefully!:

<!-- Starting new project -->
<link rel="stylesheet" href="https://design.nlcuong85.com/sari-design-system.css?key=SECRET">

<!-- Done. Everything works. Latest design system. 🎉 -->

AI Agent Integration:

// AI agents can now ask:
const tokens = await fetch('https://design.nlcuong85.com/api/tokens.json?key=SECRET');

// Instead of struggling with 7,000-line files

This is like building your own personal Design System as a Service, but for một người thôi (just one person).

The AI Agent Benefit

The coolest part? My AI coding assistants will love this:

Before:

• 🤖: “Please simplify this 7,000-line file (MUST)”
• 😅: “But it’s all important!”
• 🤖: processing timeout or thinking the heck out of it while I stress-eat snacks

After:

• 🤖: “I’ll query your design system API” … Ah , I understand … Let me….
• ⚡: Gets exact colors/components needed
• 🚀: Generates code instantly

This turns my design system from an AI agent performance problem into an AI agent superpower, CONTEXT ENGINEERING and TOOL CALLING baby!!!

The Reality Check: Am I Overengineering This?

Okay, let me step back for a second. Am I building a rocket ship when I need a bicycle?

Projects I actually maintain:

1. SARI Master thesis survey app
2. Personal interview prep tools
3. Blog writing assistant
4. Personal Journal with Ai insights
5. Maybe 2-3 future projects

Do I need enterprise-level design system infrastructure for 5 projects?

…Probably not.

Am I gonna build it anyway?

Absolutely yes.

Why?

Because why not! This is my learning playground. Six months ago, I couldn’t center a div. Now I’m architecting private CDN infrastructure. I’m not learning just for practical reasons; I’m learning for fun. It’s like collecting Pokemon cards, but instead of Charizard, I’m collecting increasingly complex technical solutions to problems I created myself.

It’s similar to my 3D printing projects where you start with a simple print and end up designing custom lamp shades and learning about material science. The maker mindset applies whether you’re working with physical objects or digital architecture – both involve iterative improvement and learning through doing. IT’S the FUM of messing around with your own free time.

Plus, honestly, building this stuff teaches me so much about things that I never touched in my whole tech career. When I eventually join a team with actual design systems in the future, I’ll understand the problems they’re solving instead of nodding politely while secretly googling “what is a design token” under the table. I did work at Anduin Transaction before with the Design team – they had a very comprehensive Design System, but I was just a Product Manager focused on my product tasks, blissfully unaware of the CSS chaos happening behind the scenes.

Speaking of Anduin, the experience there taught me about managing complex tool transitions – and now I realize that design system migration follows similar patterns. You need buy-in, gradual rollout, and lots of documentation for successful adoption, whether it’s switching project management tools or CSS frameworks.

The Journey Ahead

This Week of 13th Oct 2025:

• Set up private Cloudflare account
• Create sari-design-system repository
• Move current styleguide.html as source of truth

This Weekend:

• Build CSS extraction scripts
• Set up GitHub Actions workflow
• Test deployment pipeline

Week After:

• Implement API key authentication
• Update SARI app to use CDN
• Write documentation for future self

PlantUML Diagram, The Timeline:

@startuml Implementation Timeline
skinparam backgroundColor #f8f9fa

concise "Development Phase" as dev
concise "Learning Curve" as learn
concise "Complexity Level" as complex

@0
dev is "Repository Setup"
learn is "Basic Git/GitHub"
complex is "Low"

@1  
dev is "Automation Scripts"
learn is "GitHub Actions"
complex is "Medium"

@2
dev is "CDN Deployment"  
learn is "Cloudflare Pages"
complex is "Low"

@3
dev is "Integration Testing"
learn is "API Authentication"
complex is "Medium"

@4
dev is "Documentation"
learn is "Writing Tutorials"
complex is "Low"

@dev
0 is #lightgreen
1 is #yellow  
2 is #lightgreen
3 is #yellow
4 is #lightgreen

@enduml

From Chaos to System

Looking back at this journey:

5 Days Ago: “I need consistent button colors”
3 Days Ago: “Maybe I should learn CSS properly”
1 Day Ago: “How did this become 7,000 lines?”
Today: “Let’s build a private CDN architecture”

Vietnamese Learning Philosophy: “Cứ làm rồi biết” (Do it, then you’ll know). OR fake it until you make it…

What I Wish I Knew A Week Ago

1. Start modular from day one – even if you think it’s simple
2. Design tokens are not just colors – they’re your entire design vocabulary
3. AI agents have file size limits – plan for this early
4. CDN approach exists – don’t assume npm packages are the only way
5. Solo developer solutions ≠ Enterprise solutions – different problems, different tools

But honestly? I’m glad I didn’t know all this upfront. The journey taught me more than any tutorial could, with the help of AI of course. Sometimes the best education is just throwing yourself into the deep end and hoping you figure out how to swim before you drown in CSS.

Sharing

This whole experience makes me want to help other Vietnamese developers who are going through similar journeys. Maybe I should start a “Vietnamese Solo Developer” community on Facebook or YouTube?

For those interested in the maker/builder mindset that drives these kinds of projects, check out my Raspberry Pi introduction for Vietnamese developers – it explores how hands-on learning with physical computing can build the same iterative problem-solving skills I’m applying to design systems.

Discussion Starters:

• How do you manage design consistency across multiple projects?
• Anyone else accidentally over-engineer simple problems?
• What’s your experience with CDN setup in Vietnam?

I’m also thinking about open-sourcing the automation scripts (not the design system itself, but the tooling). Because why should every solo developer have to figure out GitHub Actions for design systems from scratch?

Mong được nghe góp ý và trải nghiệm của các bạn! (Looking forward to hearing your thoughts and experiences!)

TL;DR for Busy People

• Started with: 500-line style guide for UI consistency
• Ended up with: 7,000+ line enterprise-level design system
• Problem: File too big for AI agents to process efficiently
• Solutions considered: npm packages, design tokens, Git submodules
• Final choice: Private Cloudflare CDN with API authentication
• Why: Single source of truth, instant updates, AI-friendly APIs
• Learning: From non-tech to private CDN architect in 5 days
• Next step: Implementation over the next 2-3 weeks

Bottom line: Sometimes you start trying to match button colors and end up building infrastructure. 🚀

---

Building a design system as a solo developer is like trying to organize your entire life – you start with “I’ll just clean my desk” and somehow end up with a complete productivity system with apps, automations, and backup strategies.

The best part? Six months ago, I had no idea any of this was possible. Now I’m planning private CDN architectures like it’s a normal Tuesday afternoon activity, right between checking emails and wondering what to have for lunch.

If you’re on a similar journey, don’t be afraid to experiment. The worst that happens is you learn something new and maybe break a few things along the way. The best that happens? You accidentally become competent at something you never thought you could do and get to sound really smart at dinner parties.

What’s your experience with design systems or over-engineering simple problems? Chia sẻ với mình ở comments nhé! 🎨✨

---

Follow along for the implementation journey – I’ll be documenting the GitHub Actions setup, Cloudflare deployment, and probably a few fails along the way. Because learning in public is more fun than learning alone!