Build log & learning notes

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.