Build log & learning notes

Day 47 shipped Card of First Food! This new tool lets you create and share a digital card celebrating your first memorable food or meal. Add a photo, description, and a fun story, then generate a shareable card to celebrate your culinary beginnings. Available now in the Links to Other Sites dropdown and on the projects page.

Day 46 shipped the Clause Generator—a tool for generating common legal clauses and contract language. Select clause types, customize parameters, and generate professional legal language in seconds. Perfect for contracts, agreements, and legal documents.

Day 45 focused on making the site more accessible. Ran a full audit on both personal and portfolio sites, improved color contrast, added ARIA labels, enhanced keyboard navigation, and ensured screen reader compatibility. Accessibility is a first-class feature, not an afterthought.

Day 44 shipped the SOW Generator—a tool to quickly create professional Statements of Work for projects. Saves hours on documentation and ensures consistency across proposals. Available in the Links to Other Sites dropdown.

Day 43 was a polish pass—refined project descriptions, improved image assets, and enhanced the visual presentation of all portfolio projects. Each project now has more detailed context and better visual hierarchy.

Day 42 expanded the portfolio with two new client projects: St. Patrick's Wolfhounds basketball team site and Howlett Law firm website. Also rebranded the Local Sausage project to Seasonal Sous Chef—better reflecting its focus on seasonal produce and recipe discovery.

Day 41 was a major infrastructure day. Split the site into two Vercel deployments: mikewilley.app (personal) and mikewilley-portfolio.vercel.app (portfolio). Redesigned the personal home page with sleek CTA cards, consolidated UVA sports into one card, moved calendars to the top, and added the family section. Navigation simplified with a single 'Links to Other Sites' dropdown.

Day 40 shipped Local Sausage—a fun side project to help sausage enthusiasts and foodies discover local butchers and specialty meat shops. Browse by location, find what makes each shop special, and explore local culinary gems. Added to projects, navigation, and the Other Sites dropdown.

Day 39 modernization pass: Added two new projects to the site and navigation. Enhanced pages with gradient backgrounds, staggered fade-in animations, improved hover effects on cards, and refined shadows.

Day 38 focused on mobile reliability. Switched to Vibration API for iOS haptic feedback. Updated 23 artists and 11 venues to use actual image files instead of placeholders.

Day 37 shipped a complete mobile experience. Built my-vibe-mobile as a responsive React + Vite app with: • **Workout Timer** — HIIT/EMOM timer ported from web • **Shows** — 21 artists + 12 regional venues from real data • **UVA Basketball** — Two-column layout with upcoming games and past results • **OHMS Basketball** — Full schedule with game details and directions Deployed to Vercel for instant mobile access. No React Native debugging nightmares — just a fast, clean web app that feels native. Sometimes the simpler path is the right one.

Day 36 was a small but important fix. The UVA page was only showing the next 10 games — an arbitrary limit left over from early design. Removed it so users see the full season schedule. Small changes like this compound. Every page just got more useful.

Day 35 was about user experience clarity. The original single-column list mixed upcoming and past games. The new two-column layout puts: • **Left**: Upcoming games (next game on top) • **Right**: Game results (most recent on top) Now users can see future plans and recent performance at a glance. The design feels intentional, not random. Sometimes the fix isn't more features — it's better organization of what's already there.

Today was momentum. I added three real, functional tools to the site: • **Workout Timer** — a clean HIIT/EMOM timer that feels fast and intentional. • **Poster Generator** — upload a photo, add filters, borders, titles, and clean exports. • **Auto Gallery** — a full masonry layout that pulls images straight from `/public/gallery`, no manual setup required. Each one started small but turned into a polished, usable feature — the kind of stuff that makes a personal site feel alive. This wasn’t just shipping pages. It was shipping capability. Message: keep building, keep adding, keep improving. Every tool expands what this project can be.

Today was about restraint. I recognized that the Shows page was technically impressive but operationally fragile — rate limits, API quirks, and data-shape uncertainty kept pulling me into long recovery loops. So I made a product call: simplify. Static cards, curated links, predictable UI. Fewer moving parts, fewer surprises. This wasn’t giving up — it was choosing reliability. The page is faster, clearer, and easier to reason about. That’s not less professional. It’s more.

Day 32 was a mindset shift with TypeScript. Instead of treating red squiggles as blockers, I traced them back to mismatched data shapes, missing exports, and assumptions I’d carried forward without checking. Fixing those issues clarified the entire system: props lined up, imports made sense, and components stopped being brittle. TypeScript wasn’t slowing me down — it was pointing out where my mental model didn’t match reality. That’s a tool you learn to trust.

Day 31 was about recognizing a pattern. Artists and venues didn’t need special snowflake components — they needed a shared abstraction. EntityCard became that: title, image, link, fallback behavior. Once that clicked, everything got easier. The UI stayed consistent, the code got simpler, and future changes feel obvious instead of risky. This is how systems form — not by planning them upfront, but by noticing what keeps repeating.

Day 30 was an important product realization. I’d been assuming that "real-time API" automatically meant "better." In practice, it meant fragility, noise, and time spent debugging things users don’t care about. For the Shows page, static links were enough — and better. They’re fast, accurate, and under my control. Good engineering isn’t about maximum complexity. It’s about the right amount of truth.

Day 29 was about seeing the whole pipeline. Instead of poking at UI symptoms, I traced issues from data source → transform → component → render. That changed everything. Once you understand the flow, debugging stops feeling random. You know where to look first — and where not to waste time. This felt like crossing a real threshold as a developer.

Day 28 reinforced something important: fear comes from uncertainty. Smaller commits, clearer intent, and knowing how to roll back made deploying feel routine instead of risky. Once shipping stops being scary, you move faster — not because you rush, but because you trust yourself. That’s real momentum.

Day 26 was about making the Shows page feel like a feature, not a demo. I tightened the scope: concerts only, predictable tabs, and a local-venues filter that actually helps. I leaned into defensive UI rendering so bad data doesn’t turn into broken cards. The big win was mindset: when results looked wrong, I stopped tweaking the UI and traced the data back through the API. Once the shape was right, the UI snapped into place. This is the kind of work that turns "cool idea" into "I’d actually use this."

Day 25 was a classic API lesson: the UI wasn’t the problem — the data shape was. I added focused debug output, inspected the raw Ticketmaster payload, and realized I was transforming events twice. That created empty fields like dateTime/venue/city and the UI fell back to TBD. Fixing the pipeline made everything cleaner: one transform, consistent Concert objects, predictable rendering. This was a confidence-builder: I can reason about systems now, not just components.

Day 24 was about turning sports pages into something that feels finished. I separated upcoming vs results, added record summaries, and got the layout consistent across football and basketball. The two-column split made the pages scanable, and the recap links made it useful. I also cleaned up the navbar dropdown behavior so it closes on route change and outside click — small detail, huge polish. This is the kind of feature that tells someone: this wasn’t copied from a tutorial.

Day 23 was pure debugging. ESPN’s data shape wasn’t consistent — sometimes scores were numbers, sometimes nested objects. I stopped assuming and wrote score pickers that could handle the messy reality. Once the parsing was solid, the UI stopped lying. Finals were finals. Scores were real. And the page became trustworthy. A good dev skill isn’t writing code fast — it’s making uncertain inputs predictable.

Day 22 was about building the habit of shipping. I focused on small, safe changes, committed more frequently, and kept the repo in a state where I could deploy without fear. The big lesson: speed comes from trust — trust in your checkpoints, trust in your rollback path, trust in your process. When shipping gets boring, that’s a sign the system is healthy.

Day 21 was about the glue — the stuff users feel immediately. I improved dropdown behavior, cleaned up routes, and made sure pages share consistent structure. When the nav behaves, the whole site feels more confident. It’s easy to chase flashy features. But navigation and structure are what make everything else feel intentional. This was a "quiet wow" day — and those are the ones that level up a project.

Day 20 was a good reminder: not every integration is worth saving. JamBase wasn’t giving me clean, reliable output for what I wanted, so I removed the dependency and pushed the Shows page toward a simpler, more stable plan. The project instantly felt lighter. Fewer moving parts. Fewer weird edge cases. More control. This was a product decision, not a coding decision — and that’s growth.

Day 19 was about designing the question before coding the answer. Instead of "show me stuff," I framed it as: what’s happening near me, what’s worth seeing, and how can I filter quickly? Radius and time windows became the core model. Once that model is right, every tab and filter becomes a simple expression of it. It’s not just data — it’s a map of my actual life.

Day 18 was about restraint. I kept improving the site, but I started protecting the parts that already work. Smaller edits, clearer checkpoints, and fewer "big bang" refactors. I’m learning that shipping isn’t just finishing — it’s maintaining a baseline of trust while you evolve the system. Momentum feels better when you’re not afraid of your own code.

Day 17 was a reminder that small decisions compound. I tightened spacing, trimmed visual noise, and made components feel like they belong to the same system. Nothing here is a headline feature — but everything adds up to "this feels good." I also paid attention to what I *don’t* want: clutter, inconsistent patterns, and UI that fights the user. These are the days that keep a project from turning into a pile of half-finished ideas. The code got cleaner, and the experience got calmer. Quiet progress is still progress — and it’s the kind that lasts.

Day 16 was about rhythm — the feeling that the site is current. I tuned the ScoresBanner behavior, made sure the refresh cycle is predictable, and kept the UI thin and readable so it doesn’t overpower the page. I like when features do one job well: show the important info, update reliably, and get out of the way. The Weather + Scores block now feels like a single "status bar" for my day, which is exactly what I wanted. This is the kind of feature that turns a site into a habit.

Day 15 was about stability. After moving fast for a few days, I hit the point where things started to drift — components living in the wrong place, imports getting messy, and changes piling up. I re-centered the project: verify what works, restore what broke, and commit in a way that keeps the repo safe. The biggest win wasn’t code — it was process. More frequent commits, smaller changes, and cleaner checkpoints. Now I can build faster *because* the foundation is stable.

Day 14 was less about features and more about *order*. I spent time understanding my folder structure, untangling components, and fixing things that had grown organically as I learned. Some pages weren’t using shared components yet, others had logic living where it didn’t belong. I restored files, compared versions, and made intentional decisions about what should be a reusable component versus what should stay page-specific. This day reminded me that architecture isn’t something you get right on day one — it’s something you earn by building, breaking, and then cleaning up after yourself. It wasn’t flashy, but the codebase feels calmer, clearer, and more maintainable now. That’s a win.

Day 13 felt different — calmer, more confident. Instead of adding new pages or APIs, I focused on refactoring what I’d already built. I broke large sections into reusable components, experimented with layout changes, and made judgment calls about what actually looked and felt right. Some ideas got rolled back. Others stuck. And that was the win. This was the first day I wasn’t just *learning how* to do something — I was deciding *whether* it should exist at all. That shift feels important.

Day 12 was one of those rare days where things just *worked*. I spent the day refactoring and building reusable components — sections, image layouts, badges, and shared patterns that I can now drop anywhere across the site. Instead of fighting layout or rewriting the same JSX, I was composing pages out of clean, intentional pieces. The code felt calmer. The UI felt more consistent. This was a big mindset shift: I’m no longer building pages — I’m building a system. And that made this one of the most satisfying days so far.

Day 11 felt like a grind. APIs didn’t return what I thought they would, fields were missing, and small changes broke things in ways I didn’t anticipate. I spent a lot of time stepping through responses, logging raw data, and figuring out where my assumptions were wrong. Some moments were frustrating — especially when things *almost* worked. But this was real learning. I stopped expecting APIs to be clean and started treating them as inputs that need to be inspected, validated, and adapted. By the end of the day, the code was better — but more importantly, my mindset was.

Day 10 was the point where tutorials stopped holding my hand. I worked with JamBase and TheSportsDB APIs, built and refactored Next.js route handlers, and dealt with endpoints that didn’t behave the way I expected. I ran into incomplete data, confusing parameters, environment variables that worked locally but failed on deploy, and APIs that only returned one game when I needed a full schedule. Instead of asking what the right code was, I started inspecting raw responses, logging keys, reshaping data, and adjusting assumptions. This was frustrating — and also the first time I really felt like a developer. I didn’t just use APIs. I learned what they actually are: inconsistent, opinionated, and something you have to adapt to.

Day 9 was about stepping back and cleaning things up. I focused on spacing, typography, navigation, and mobile layouts instead of adding new features. I rewrote copy, removed placeholders, simplified components, and made decisions about what actually mattered on each page. This day reinforced something important: good development isn’t just about writing code — it’s about making thoughtful decisions and knowing when to stop.

On Day 8, I replaced placeholder content with real writing and real stories. The Vibe Log became an actual developer journal instead of a list of test entries. Writing real content forced better layout decisions and made the site feel intentional. It stopped being "practice" and started feeling like my space. This was also when I realized how closely writing and development are connected — content drives structure, not the other way around.

Day 7 was about pulling everything together into a real homepage. I focused on hierarchy, messaging, and flow instead of just linking pages together. This was the first moment the project felt cohesive. The site stopped looking like a collection of experiments and started feeling like a product. Shipping this page gave me momentum and confidence heading into more complex work.

Day 6 introduced Framer Motion. I added fade-in animations to cards and sections, focusing on smoothness rather than flash. The biggest lesson wasn’t how to animate — it was when not to. Motion should support clarity, not distract from it. This day helped me think more about experience than features.

On Day 5, I leaned into reusable UI components using Tailwind and shadcn/ui. Cards, badges, and shared layouts replaced one-off styling. This was a shift from building pages to building systems. The codebase became easier to reason about and easier to extend. Once components clicked, everything else moved faster.

Day 4 was all about Next.js routing. I built dynamic routes like `/projects/[slug]` and `/vibes/[slug]` and learned how params and static generation work together. Once this clicked, content stopped being hardcoded and started being data-driven. This was a major unlock that shaped the rest of the project.

Day 3 focused on React fundamentals. Components, props, and state stopped feeling abstract and started to feel practical. I learned how small pieces combine to create real behavior and how thinking in components simplifies complexity. This day laid the mental groundwork for everything that followed.

Day 2 was about learning Tailwind CSS. At first it felt noisy, but once I understood utility-first thinking, styling became faster and more predictable. Instead of fighting CSS, I could focus on layout, spacing, and hierarchy. This day made design feel approachable instead of intimidating.

Day 1 was all about setup. Node.js, VS Code, GitHub, Vercel, and a fresh Next.js app. Nothing fancy — but getting everything running and deployed made the project feel real from the start. The most important thing on Day 1 wasn’t code. It was momentum.