Front-End Foundations

#DevBlog · Oct 11, 2025

This is the build log for how I took the idea from Part 1 and turned it into a working front end. Simple stack. Clean structure. No fluff. The goal is a site that looks good now and upgrades cleanly to full stack later.

1) Outcomes first

  • Hero banner with split tone. Brand + tagline.
  • Sticky navbar with categories that feel obvious.
  • Category pages with clickable post cards.
  • Individual post pages that read well on phone and desktop.
  • Footer that actually stays at the bottom.

2) Folder structure

/coffee-kids-code
  /css/styles.css
  /js/quotes.js
  /images/{coffee.jpg,kids.jpg,code.jpg}
  /posts/{building-with-purpose.html, front-end-foundations.html, dailyStart.html}
  index.html
  devblog.html
  singledadlife.html
  politics.html
  general.html

3) Base HTML scaffold

Each page shares the same head block for fonts and styles. The body is split into <header>, <nav>, <main>, and a sticky footer. Reuse wins.

4) Design system in CSS (variables + spacing)

I set color tokens and spacing in :root and kept components small and reusable.

:root{
  --bg-light:#F4EDE4; --bg-dark:#1E1E1E;
  --text:#2B2B2B; --mint:#A6E3A1; --amber:#D8A35D;
  --radius:16px; --space:clamp(12px,2vw,20px);
}

Cards, grid, navbar, and the split hero sit on top of this. It keeps the look consistent and makes theming easy later.

5) Components I shipped

  • Hero: split light/dark background, brand text, tagline “Debugging life, one coffee at a time.”
  • Navbar: rounded pills, active state, sticky.
  • About + Visual Trio: short bio plus three cards for Coffee, Kids, Code.
  • Quote block: centered card that now rotates with JS.
  • Post cards: title, date, blurb, full-card link.
  • Post page: readable line length, tags, back links.

6) Light JavaScript to keep it interesting

The site is still static, but a tiny script rotates quotes on load. Later I’ll let JS auto-render the latest posts from JSON.

document.addEventListener("DOMContentLoaded", () => {
  const quotes = [
    { text: "Integrity is doing the right thing, even when no one is watching.", author: "C.S. Lewis" },
    { text: "The function of good software is to make the complex appear simple.", author: "Grady Booch" }
  ];
  const q = quotes[Math.floor(Math.random()*quotes.length)];
  document.getElementById("quote-text").textContent = `“${q.text}”`;
  document.getElementById("quote-author").textContent = `— ${q.author}`;
});

7) Accessibility and performance checks

  • Semantic tags: header, nav, main, footer, article, section.
  • Alt text for images. Good contrast on dark side of hero.
  • Mobile first CSS. No layout shifts on load.
  • One font request. No heavy frameworks.

8) Deploy path today

Dev in GitHub. Auto-deploy on Vercel. Zero build step for now. When I push, the site goes live. Done.

Upgrade plan: to full stack without burning cash

A) Dynamic content without a backend (bridge step)

Quick context: JSON (JavaScript Object Notation) is a simple text format used to store and share data — basically, a lightweight database in a single file. It’s perfect for early projects because the front end can read it directly with JavaScript, no server required. Think of it as a dry run for when the API comes online later.

  1. Create posts.json with title, date, category, slug.
    → Why: This acts like a lightweight database before we introduce a real one. It lets us test dynamic loading and card rendering logic without needing a backend or deployment changes.
  2. Use a small JS loader on category pages to render cards from JSON.
    → Why: By reading from a static JSON file, we simulate an API call and structure our pages the same way we will later when the backend exists. It’s practice for fetch-based rendering, error handling, and modular JS organization.
  3. Keep writing posts as HTML while I test the flow.
    → Why: Staying with static HTML means I can keep the site visually active while I experiment with structure. The user experience doesn’t break even while the architecture evolves underneath.

B) Real API

Quick context: An API (Application Programming Interface) is what lets the front end and back end talk to each other. Instead of hardcoding content, the site will make requests (like “get all posts” or “fetch one post by ID”) and get structured data back in JSON format. That data powers what users see — same logic, just delivered dynamically.

  1. API stack: Node + Express (or Fastify) with a simple posts router.
    → Why: Express is lightweight, predictable, and well-documented. It’s ideal for small personal APIs. If traffic grows, we can switch to Fastify later for performance.
  2. Data: start with a JSON file, move to Postgres when ready.
    → Why: JSON keeps iteration fast and error-free early on. When we add features like search or filtering, Postgres gives better querying and reliability without major code rewrites.
  3. Auth (admin only): sessions or JWT, rate limit, CORS locked down.
    → Why: Even a personal project needs guardrails. Using JWTs or sessions keeps the admin routes secure and prepares the code for future scaling or public APIs.
  4. Admin UI: a basic form to create/edit posts in Markdown.
    → Why: Markdown provides simple formatting without needing a WYSIWYG editor. It’s faster to store, safer, and easy to convert to HTML on render.

C) AWS on a budget

Quick context: AWS is overkill for hobby projects if you use it wrong—but a superpower if you plan it right. The goal here isn’t to build an enterprise setup; it’s to learn real cloud workflows without blowing up a credit card. Each service choice below balances control, scalability, and cost so I can deploy a full-stack app that looks professional, runs reliably, and still fits a single-dev budget.

  • Front end: stay on Vercel or move to S3 + CloudFront later.
    → Why: Vercel handles static front ends perfectly for free, but S3 + CloudFront gives full control and scales better when tied to other AWS resources.
  • API hosting: AWS Lightsail instance (small plan), or a tiny Fargate service if I want containers.
    → Why: Lightsail is predictable pricing—$5/month for a small VM—and includes SSH, monitoring, and snapshots. Fargate is great for scaling but only worth it when traffic demands containers.
  • Database: Lightsail Managed Database or RDS Postgres (use free tier sensibly). For super cheap, start with a single-node Lightsail DB.
    → Why: Both are fully managed, saving maintenance time. Starting small means I can scale up when traffic or data actually requires it instead of paying for idle capacity.
  • Secrets: AWS Secrets Manager for DB creds and JWT secret.
    → Why: Never hardcode credentials. Secrets Manager handles rotation and encryption automatically, keeping deployments secure without cluttering .env files.
  • Domain: Route 53, A/AAAA records to Vercel or CloudFront; CNAME for api. to the backend.
    → Why: This makes your setup professional and scalable. Separating front-end and API subdomains lets us swap or upgrade services independently later.

D) CI/CD

Quick context: CI/CD stands for Continuous Integration and Continuous Deployment. It’s the process of automatically testing, building, and deploying code every time you push changes. For solo developers, it’s less about fancy pipelines and more about consistency—removing human error and making sure new code goes live cleanly every single time. Think of it as version control with a motor attached.

  • GitHub Actions builds and deploys API to Lightsail on push to main.
    → Why: It automates deployments and removes human error. One push, one deploy. No manual SSH or FTP ever again.
  • Front end stays auto-deployed by Vercel on push.
    → Why: Vercel’s continuous deployment keeps the site live and synced with every GitHub change. It’s zero-configuration CI/CD, which saves time for actual development.

E) Rough monthly cost

Quick context: One of the main goals here is proving you can run a legit full-stack setup without enterprise pricing. A lot of devs think cloud hosting automatically means expensive bills—but if you choose intentionally and scale gradually, you can stay under $20 a month while running a production-ready system. Here’s the breakdown of what that looks like for Coffee + Kids + Code:

  • Vercel free for front end.
  • Lightsail instance for API: ~$5.
  • Lightsail Postgres small: ~$15 (or start with file store and upgrade later).
  • Route 53 domain: ~$12/yr.
  • Total starting point: about $5 to $20 per month depending on DB choice.

Checklist to ship the upgrade

Quick context: This isn’t a wish list—it’s the execution roadmap. Everything up to this point has been planning and architecture. This list is where concept meets code: the small, focused steps that turn a static site into a living full-stack system. No shortcuts, no frameworks doing the heavy lifting—just deliberate progress.

  • [ ] Create posts.json and a JS loader for category pages.
  • [ ] Stand up a minimal Express API with a /posts route.
  • [ ] Move post content to Markdown; render on the server.
  • [ ] Add admin auth and a basic post editor.
  • [ ] Provision Lightsail, point api.yourdomain, add HTTPS.
  • [ ] Wire GitHub Actions for push-to-deploy.

I could have pulled in a framework and called it a day, but that’s not the point. I know I can build it. The exercise here is discipline and clarity. Start simple. Make it clean. Scale when it earns it.