SemaKazi 구축 2부: 프론트엔드 시작, 프레임워크 필요 없음

Phase 1 of SemaKazi (a verified reputation platform for Kenya’s informal-sector workers — electricians, carpenters, mechanics, tailors) shipped a working backend: auth, profiles, proof-of-work, reviews, badges, all tested end-to-end. Today I started Phase 2 — the frontend.

Keeping it deliberately simple

No React, no build step, no bundler. Just HTML, CSS, and vanilla JavaScript talking to the API with fetch. For a project this size, reaching for a framework would’ve added ceremony without adding value — the goal is working software, not a tech showcase.

What went in today

The skeleton first. Before any actual pages, I built the shared pieces every page would need:

• api.js — one object (api.register, api.login, api.searchProfiles, etc.) wrapping every backend call, so no page has to write raw fetch logic or handle auth headers manually
• nav.js — a nav bar that swaps its links depending on whether you’re logged in
• style.css — shared design tokens (cards, buttons, forms) so every page that comes later looks consistent without repeating CSS

Building this first meant every page after it could focus purely on its own logic instead of re-solving “how do I call the API” five separate times.

Then the actual auth pages — registration (with a role picker that shows trade/location fields only if you’re signing up as a fundi) and login. Both store the JWT and redirect to a dashboard that… doesn’t exist yet. That’s fine — it’s the next branch, and I’d rather see an honest 404 now than pretend the flow is finished.

The part that actually tripped me up

Folder structure. register.html and login.html needed to sit in a pages/ subfolder, which meant every relative path inside them (../css/style.css, ../js/api.js) had to account for being one level deeper than index.html. Small thing, easy to get backwards, and a good reminder that “confusing” doesn’t mean “hard” — sometimes it’s just unfamiliar, and the fix is five minutes of careful checking, not a rabbit hole.

Workflow, still

Same discipline as Phase 1: one feature branch per unit of work, each file its own commit, PR descriptions with a summary/why/testing/notes section, merged into main only after local testing against the live backend.

What’s next

Search page, then the fundi profile view, then the dashboard those auth pages are currently redirecting to.

Repo’s public if you want to follow the commit history as it grows.