adnane.
Back to blog
Week one of building in public cover
building in public
indie dev
nuxt

Week one of building in public

What I shipped, what broke, and why sharing early beats waiting for perfect.

4 min read

I started sharing progress on elbakkali.me before the landing page felt "done." That was intentional.

Why share early

Building in public is not a marketing stunt. It is a feedback loop. When you post what you shipped — even a rough v0 — you learn what resonates, what confuses people, and what you should cut.

Three things happened in week one:

  1. Scope got smaller. Comment threads pushed me to ship the portfolio core before chasing visual polish.
  2. Content became the product. Moving copy into site.json and Markdown made iteration faster than hard-coding Vue templates.
  3. Momentum compounded. Small public wins made the next task feel lighter.

What actually shipped

  • Docker-first Nuxt app with typed @nuxt/content collections
  • Landing sections driven by content, not props scattered across pages
  • Lenis smooth scroll with reduced-motion respect
  • A blog scaffold — because writing is part of the studio, not an afterthought

What broke (and what I learned)

The first deploy attempt failed because I treated content warmup as optional. Nuxt Content v3 needs its SQLite tables ready before queries run in CI. I added a small readiness check instead of guessing at race conditions.

Perfect is the enemy of shipped. Public accountability makes "good enough to learn" the default.

Next up

Blog list and detail pages, then back to landing polish — but only after the writing workflow feels good. If you are building solo, share one concrete update this week. A screenshot, a PR link, or a short note on what you cut.

That is enough.