Craft is live. What started as a prompt about non-billable time and designer growth ended up as a fully functional, deployed web app – built in a single HTML file with no framework, no dependencies, and no backend.
Craft is a single-file HTML/CSS/JS application. Everything – structure, styles, and behavior – lives in one file. There’s no login required for end users browsing the learning buckets, but a password-protected admin panel is accessible via the ?admin route for anyone managing content. It’s the kind of architecture that’s easy to dismiss until you ship something with it, and then it makes a lot of sense.
The CMS is backed by localStorage – full CRUD on buckets and resources, plus JSON export and import for portability. If the browser goes away, the data can travel. The deploy pipeline runs through GitHub and Vercel: push to main, live in 20 seconds.
Visual language first. The app was styled to match Midwestern’s internal brand from the start – light mode, DM Sans, lime accent color, hairline grid dividers. It doesn’t feel like a side project. It feels like it belongs.
No dependencies. Vanilla JS, no build step, no package manager. The constraint forced clarity. Every interaction had to be written deliberately rather than abstracted away by a library.
Admin without a backend. The ?admin route pattern is a clean solution for low-stakes content management. It keeps the file portable while still giving a non-technical user a surface to work with.
The shipped version went through several meaningful passes before it felt right:
clamp() to prevent overflow at narrow viewports without breaking the layout at wider sizesspace-between with the logo as a direct flex child, fixing an alignment issue at certain breakpointsHTML · CSS · Vanilla JS · localStorage · GitHub · Vercel
Constraints are a feature. Deciding early that this would be a single file with no dependencies removed entire categories of decisions – no framework debates, no build configuration, no dependency management. The work stayed focused on the product. There’s a version of design tooling that lives entirely in that space, and it’s more capable than it looks.
]]>Two separate threads today – one about building a tool, one about building a career.
Started with a context dump on Midwestern’s internal design process: the 5-phase design thinking framework, AI-augmented tooling across Zoom, Claude, Figma, Notion, Cursor, and GitHub. The problem to solve: build an internal alternative to PIPs and growth plans – something positive, self-directed, and useful during non-billable time.
The output is Craft – a single HTML file. No login, no tracking, no dependencies. Seven pre-populated learning buckets:
Each bucket contains curated resources, time estimates, and editorial notes on why the material matters. A ghost card holds space for team-defined buckets down the road.
Went through two rounds of iteration after the initial build:
Round 1 – standardized typography to DM Sans, tightened border radii, opened up spacing.
Round 2 – full light-mode restyle to match midwestern.com. Cool lavender-gray background, white card surfaces, lime highlight treatment, hairline grid dividers, and a dark “Why it matters” panel pulled from their site’s callout section pattern.
In a separate conversation, built out a full FY 26-27 professional development plan: phased quarterly timeline, SMART goals, free learning resources, and a weekly time budget. After seeing the first draft, pulled it back intentionally – less ambition on the code side, more tinkering than building.
From there, expanded into two additional Leapsome goal tracks:
The final pass tightened everything into Leapsome-ready language: summary statements, key results, and a reusable context block for future AI chats.
Writing goals for a platform like Leapsome forces a useful constraint – vague intentions don’t survive the format. The elicitation round before writing made a significant difference in output quality. Getting the right inputs before generating anything is a pattern worth repeating.
]]>Good design is rarely a straight line. It’s a series of small bets, course corrections, and occasional breakthroughs. This log is an attempt to document that process honestly – not just the wins, but the reasoning behind every turn.
Completed the GitHub Pages course on skills.github.com and used it as the foundation for a personal design log. The goal is to document design decisions, iterations, and lessons learned across projects.
index.md) with:
.md files without issueobject-fit: cover is the right tool for forcing an image into a fixed box without distortionalt text on a profile photo should describe the person, not just say “profile photo”Set up _config.yml with title, author, description, and theme. Iterated through Hacker and Midnight themes
before settling on a fully custom CSS override for precise control over the palette and typography.
Chose DM Sans from Google Fonts as a clean, warm alternative to Proxima Nova. Built a custom stylesheet
at assets/css/style.scss using a warm dark palette:
rgb(26, 26, 26)rgb(255, 236, 222)rgb(255, 184, 133)Jekyll compiles _posts/YYYY-MM-DD-title.md into /YYYY/MM/DD/title.html, preserving filename casing.
The GitHub Pages build action hardcodes future: false regardless of _config.yml, so posts must use
a current or past date to build.
Links in index.md must use relative paths without a leading slash to resolve correctly against the
repo base path rather than the domain root.
index.md – home page and entry index_posts/2024-01-01-Welcome.md – this post_config.yml – Jekyll configurationassets/css/style.scss – custom stylesheet