코드를 한 줄도 쓰기 전에 — 내 Gym App 계획하기🏋️

발행: (2026년 3월 28일 PM 03:27 GMT+9)
3 분 소요
원문: Dev.to

Source: Dev.to

Cover image for Before Writing a Single Line of Code — Planning My Gym App🏋️

Hey fellow devs, 👋

Moving on from AI chaos, this time it’s all about learning something new.

💡 What I’m Building

I’m building a simple gym schedule app — entirely with the help of Claude.

The app lets users set a weekly schedule from Monday to Sunday, with their gym timings, workout split, exercises, reps and sets. Nothing fancy — this is purely a practice project. But the plan is to build it right, not just fast.

Since vibe coding is clearly the future, getting comfortable with it early felt like a smart move. 🚀

📊 Sequence Diagrams — What Even Are They?

A sequence diagram maps out how different parts of a system interact with each other in a specific order over time.

Think of it like a WhatsApp conversation — you can see exactly who said what, to whom, and in what order.

Here’s the sequence diagram I made for my app:

Gym schedule sequence diagram

🧠 How I Actually Built It

The first step is identifying your actors — the objects that interact with the system. For my app this was straightforward:

  • User — inputs the schedule
  • UI — handles what the user sees and does
  • Database — saves and retrieves the data

Good developers don’t just map out the ideal scenario. They think about everything that could go wrong because it’s an imperfect world.

For example — what happens if the user tries to save a workout day without filling in all the fields? No exercises, no reps, just an empty entry hitting the database. The diagram needs to account for that validation step, otherwise that’s a bug waiting to happen from day one.

Thinking about failure early is what separates planned apps from messy ones.

🗺️ Why Planning Actually Matters

Jumping straight into code is tempting. I get it.

But mapping the flow first forces you to ask questions you’d otherwise miss — Is this feature actually necessary? What happens if this step fails? Does this even make sense?

In a small project like this it keeps things clean. In larger projects, it can save weeks of rework. The planning stage is unglamorous but genuinely important.

🤖 Claude’s Role — Plan Mode

Claude is brilliant at building apps, but even Claude isn’t perfect — and usually when something goes wrong, it’s because the prompt wasn’t clear enough. That’s on the user, not Claude.

So before touching any code, I sent Claude my sequence diagram and we brainstormed the entire app structure together in plan mode — no building, just thinking. Getting Claude to deeply understand what I want before it starts writing anything makes the whole process cleaner and faster.

Context first, code later. ✨

Next up — enough planning, time to actually build something. See you there. 👀

0 조회
Back to Blog

관련 글

더 보기 »

문제 이해부터 시스템 구축까지

Phase 1 – Clarity 초기 단계에서는 문제를 근본부터 이해하는 데 시간을 투자했습니다 — 사용자, 그들의 제약 조건, 그리고 실제로 중요한 것이 무엇인지…

계획의 요점

계획의 목적 소프트웨어 개발에서는 계획을 세우는 것을 좋아합니다. 우리는 2‑week sprints부터 5‑year roadmaps까지 모든 것을 계획합니다. 계획을 갖는 이유는…