Design system for building consistent experiences on lukestahl.io
Introduction
This design system documents the visual language, components, and patterns used across lukestahl.io.
It's built with modern web standards, prioritizes accessibility, and supports both dark and light themes.
Design Philosophy
Developer-focused aesthetic with clean typography
High contrast for accessibility (WCAG AA compliant)
A high-contrast, accessible color system that adapts between dark and light themes.
Primary Colors
Blue Primary (Dark)#60a5fa
Blue Primary (Light)#2563eb
Accent Colors
Indigo#818cf8
Purple#a855f7
Green#34d399
Yellow#fbbf24
Pink#ec4899
Orange#fb923c
Background Colors (Dark Mode)
Primary Background#0a1128
Secondary Background#0f1a35
Tertiary Background#162544
Background Colors (Light Mode)
Primary Background#ffffff
Secondary Background#f8fafc
Tertiary Background#f1f5f9
Text Colors
Primary Text (Dark)#e4e4e7
Secondary Text (Dark)#a1a1aa
Primary Text (Light)#0f172a
Secondary Text (Light)#475569
Code Syntax Highlighting (Dark Mode)
Keywords#c792ea
Strings#c3e88d
Properties#82aaff
Comments#697098
Code Syntax Highlighting (Light Mode)
Keywords#9333ea
Strings#16a34a
Properties#0284c7
Comments#64748b
Typography
Two primary typefaces: Fira Code for code and monospace elements, Inter for body text and UI.
Fira Code
Monospace · Code blocks · Technical elements
Regular 400
const greeting = "Hello, World!";
Medium 500
const greeting = "Hello, World!";
Semibold 600
const greeting = "Hello, World!";
Inter
Sans-serif · Body text · UI elements
Regular 400
The quick brown fox jumps over the lazy dog
Medium 500
The quick brown fox jumps over the lazy dog
Semibold 600
The quick brown fox jumps over the lazy dog
Bold 700
The quick brown fox jumps over the lazy dog
Common Heading Classes
.blog-hero-title (3rem / 48px)
.section-title (2rem / 32px)
.subsection-title (1.25rem / 20px)
.feed-title (1.125rem / 18px)
.blog-title (1rem / 16px)
Icons
Font Awesome 6 provides the icon set used throughout the site. Icons are used for visual hierarchy and quick recognition.
Common Icons
fa-code
fa-pen-nib
fa-bullhorn
fa-chart-line
fa-arrow-right
fa-arrow-up-right-from-square
fa-circle-check
fa-moon
fa-sun
fa-display
fa-magnifying-glass
fa-bars
Icon Guidelines
Use solid style for primary actions and filled states
Maintain consistent sizing (1rem for inline, 1.5rem for standalone)
Apply accent colors for interactive or highlighted icons
Ensure sufficient contrast against backgrounds
Spacing
Based on an 8px (0.5rem) base unit with flexibility for in-between values when needed. Common increments include 0.5rem, 1rem, 1.5rem, 2rem, 3rem, and 4rem, with occasional use of 0.75rem, 1.25rem, and 0.875rem for fine-tuning.
Developer marketing builds trust first, pipeline second.
The work connects your product to how developers actually build and helps that credibility translate into adoption and revenue.
A great developer experience is the foundation. It starts with discoverability, continues through docs, and carries into the product itself. Good documentation shortens time to value and builds confidence that your product can scale with real teams. Developers trust what they can inspect, so show how the product works and let the system speak for itself.
Success isn't clicks or vanity metrics. It's measurable engagement that creates product-qualified leads, builds influence across teams, and contributes to both product-led and sales-led growth.
When developers use your product by choice and advocate for it inside their company, you've done the job right.
Strategy
Start with reality, not aspiration.
Map where your product fits in the developer workflow, then help them do that job faster or with less friction.
Lead with clarity. Explain what it is, what it does, and why it matters.
Show the system behind the product. Architecture, examples, and tradeoffs explain more than positioning ever will.
If you can do it in a clever or playful way that still feels authentic, that's bonus points.
The best developer marketing respects time, delivers value, and makes something complex feel obvious.
Journey
Awareness → Evaluation → Adoption → Advocacy.
Each stage should connect clearly to the next.
Awareness happens in places developers already spend time: GitHub, Reddit, newsletters, blogs. Evaluation happens in your docs, demos, and sandboxes.
For most developers, the docs are the real homepage, so accuracy and structure matter more than polish.
Adoption depends on how fast they reach first success. Advocacy is when they start teaching others what they learned from you.
Personas
Create personas based on who buys the product and who actually uses it. For example:
Each persona has different pain points and goals.
CTOs and Engineering Leaders care about governance and ROI.
Senior Engineers look for performance, flexibility, and code quality.
Implementation Architects focus on how well a tool integrates and scales.
Write for what each person owns, not what you wish they cared about.
Messaging
Be clear first. Be clever only if it helps.
Make every message easy to scan. Lead with the point before expanding on it.
Good developer messaging is specific, practical, and rooted in how people actually build.
Clarity earns trust, but a bit of personality makes it stick.
The goal isn't to sound like marketing. It's to communicate something real that developers recognize and care about.
Build around three pillars:
Speed: faster builds, fewer tickets
Efficiency: consolidated stack, lower maintenance
Control: safe scale, long-term confidence
If you can back it with code, data, or proof, keep it.
If it only sounds good, cut it.
Campaigns
Treat campaigns like product launches.
Plan, ship, measure, repeat.
Each campaign should answer three questions:
What developer problem are we solving?
What proof are we showing?
What happens next?
Treat developer feedback like bug reports and close the loop quickly when something needs to be corrected or clarified.
Make it easy for developers to try, test, or share.
Run retros on every launch and capture what worked, what didn't, and what to change next time. Always learn from what you launch.
Content
Write with clarity and intention. Every piece should help developers build faster, learn something new, or solve a real problem.
Strong content earns attention because it's useful.
Lead with the outcome or insight, then show how to get there. Make it easy to skim from top to bottom.
Show working examples, explain tradeoffs, and include visuals or code where it helps understanding. If it doesn't teach or demonstrate something real, it doesn't belong.
Core content types
Blog posts: tutorials, technical breakdowns, or opinionated takes grounded in experience.
Guides and tutorials: step-by-step instructions that lead to a working result.
Integration or workflow content: explain how tools connect and where they fit in a developer's process.
Technical guides and code examples: deeper material for experienced readers who want implementation detail.
Explainer or glossary content: clear, factual definitions written to answer specific questions directly.
Video or live sessions: demos, interviews, or walkthroughs that show real workflows.
Research and surveys: reports or insights that help developers understand the state of their field.
Content strategy buckets
Awareness — generate buzz and discussion. Hot takes, thought leadership, or topics that invite conversation.
Acquisition — bring new developers in through problem-solving content. Tutorials, guides, and explainers that answer real questions.
Enablement — help existing users succeed. Deep tutorials, documentation extensions, and practical how-to content with long-term value.
Convert Paid — drive upgrades or signups. Feature-specific walkthroughs or advanced use cases that show value worth paying for.
Each piece should fit into one of these buckets and serve a clear purpose. Awareness earns attention. Acquisition builds trust. Enablement drives success. Convert Paid turns success into growth.
Clarity is the standard. Use it to earn credibility.
Community
Reddit. GitHub. Discord. Slack. YouTube and other social platforms.
Join conversations, don't start pitches.
Be helpful. Add context. Share working examples.
When your content becomes the answer people link to, you've earned credibility.
Metrics
Measure adoption and revenue, not reach.
Awareness is useful, but only if it drives activation or expansion.
Focus on signals that show impact:
Product or API usage
Time to first success
Product-qualified leads
Developer-influenced revenue
Retention and repeat engagement
The goal is to prove that trust earned from developers shows up later in product usage and revenue.
Use it to stress-test messaging, review technical content, plan developer campaigns, or get feedback on positioning. It applies a "trust first, pipeline second" philosophy with an emphasis on clarity, technical credibility, and measurable engagement.
Need more resources?
Check out my curated collection of developer marketing tools, newsletters, and resources.
