FRAMELINE • DESIGN SYSTEM • 2025
Taste that ships as installable code

- Role
- Product Designer + Engineer
- Timeline
- 2024 – present
- Team
- Solo (DUDESIGN)
- Skills
- Systems thinking and design systems, Prototyping in code, Developer tools aesthetic
Proof
Live prototype
Website
Problem
Teams that care how their product looks must ship that look in code. Every existing path forces a compromise: shadcn/Tailwind is structurally sound but visually anonymous; viral effect libraries look identical across thousands of sites; Figma Community files never ship; building in-house costs engineer-days nobody authorizes for 'the background.'
The gap isn't a shortage of images. Taste does not currently ship as code.
Process
I defined Frameline as a commercial surface & materials system: typed React components, token-bound, production-safe, with a live configurator and plain-language licensing.
Discovery Phase 01 focused on Gate 01 evidence — waitlist, willingness-to-pay, and install intent — before locking commerce architecture.
The catalog includes screen templates (e.g. Softwave hero and feature cards) that demonstrate how materials compose into real product surfaces, not isolated demos.
Built with Next.js App Router, WebGL shaders, and a solo-operable publishing pipeline so each new material ships in hours, not days.
Outcome
Live product at frameline.ai with a growing material catalog, configurator, and discovery instrumentation in place.
Frameline doubles as portfolio proof: I own the full narrative from problem definition through shipped code.
What I'd do differently
Publish fewer materials earlier with stronger before/after case studies — buyers need to see transformation on a real app shell, not just the material in isolation.
My role
Owned
- Product definition, discovery, and positioning
- Visual language and material catalog curation
- Live configurator UX and licensing clarity
- Full-stack implementation (Next.js, shaders, commerce flow)
Did not own
- Third-party payment processor internals
- Community moderation at scale (pre-PMF)
Collaborators: DUDESIGN (solo operator), Early design-engineer advisors
Key decisions
Decision 1
PNG handoff vs. installable surface
Chose: Typed React components with token binding, SSR-safe fallbacks, and `prefers-reduced-motion` support — materials you install, not PNGs you hope scale.
Rejected: Static export only. Faster to ship, but it doesn't solve the engineer's real job: production-safe code in their repo.
Decision 2
Generic AI aesthetic vs. opinionated craft
Chose: Curated materials with a clear visual signature — fewer items at a higher bar, each with measured performance budget.
Rejected: Volume catalog of anonymous effects (the Aceternity problem). High demo impact, zero differentiation.
Decision 3
Research theater vs. shipped signals
Chose: Fake-door pricing, waitlist, and install-intent logging to validate demand before heavy commerce build-out.
Rejected: Months of user interviews before a single material ships. Speed to PMF over research theater.