The Hat Switch Protocol

You have learned the seven roles. Now the question is: how do you use this in practice?

This section gives you a concrete protocol — a decision tree, a sequencing rule, and a list of the most expensive mistakes that happen when the hats get mixed up. Read this before you start building any new feature.

The Fundamental Rule

You can only wear one hat at a time. Decide which one before you start.

This sounds obvious. It is violated constantly.

The most common violation: a developer is in the middle of building a screen (Frontend hat) and starts making decisions about what data to store (Data Architect hat) or whether this feature is even needed (Product Owner hat). These decisions get buried in code, undocumented, made quickly because you were "just trying to make it work." Three weeks later, no one remembers why the table has those columns.

The discipline of switching hats deliberately means: when you notice you need to make a decision from a different role, stop. Put on that hat explicitly. Make the decision. Document it briefly. Then go back to what you were doing.

The Correct Sequence for a New Feature

This is the order that produces the most stable result with the least rework.

This is not a waterfall. You will go back. The Data Architect step may reveal that the Product Owner's scope is impossible without a much larger database change — so you briefly re-enter Product Owner mode to adjust scope. That is fine. The point is to do each step deliberately, not to never revisit.

The Most Expensive Trap: Jumping From Product Owner to Frontend

Scenario: You have a client meeting. They describe what they want. You leave excited. You open your code editor and start building screens.

You skip Data Architect entirely. You build the UI based on assumptions about what the data looks like. When you get to the backend, you realize the data structure does not support what the UI expects. You redesign the database. The frontend breaks. You rebuild the frontend to match the new database. You have done twice the work.

This is the single most common cause of "starting over" in solo projects.

The fix: after every client meeting, the next thing you do is NOT open your code editor. The next thing you do is open a blank document and answer the three Product Owner questions. Then sketch the screens on paper. Then design the database. Only then open the code editor.

Rule: Never open the code editor without a stable answer to "what does the database look like?"

Which Claude Code Prompt Goes With Which Hat?

Each role has a different kind of question to ask Claude. Asking the wrong question for the current hat produces unhelpful or misleading output.

The "Which Hat Am I Wearing?" Decision Tree

When you sit down to work and are not sure what you should be doing, use this tree:

The Case Study: Udyogaseva Job Posting Feature

This is not a hypothetical. This is a real feature from a production application — and the sequence is exactly what happened.

Udyogaseva is a recruitment platform. One of its core features is the ability for recruiters to post job listings. Every role played a part in building it.

Product Owner role:

• Defined: What information does a job listing need? What can a recruiter do with it after posting (edit, close, republish)?
• Scope decision: v1 includes text-based job listings. Video job descriptions are v2.
• Done criteria: A recruiter can create a listing, it appears in candidate search results within 60 seconds, and the recruiter can close it at any time.

Designer role:

• Sketched: A multi-step form — basic info (title, company, location) → requirements (experience, skills, education) → description (full text) → preview → publish
• Defined all states: draft (unpublished), active (visible to candidates), closed (no longer accepting)
• Decided: Status badge colors. Draft = gray. Active = green. Closed = red.

Data Architect role:

• Designed the jobs table: id, recruiter_id, company_id, title, description, requirements, location, experience_min, experience_max, status, created_at, updated_at, deleted_at
• Designed the job_skills table: id, job_id, skill_id (many-to-many relationship — one job can require multiple skills)
• RLS: recruiters can only see and modify their own jobs. Candidates can see only active jobs. Admins see all.

Backend Developer role:

• Wrote the Supabase query for candidate job search (filtered by location, experience, skills)
• Wrote the edge function that sends a notification email to matching candidates when a relevant job is posted
• Wrote the auto-close function: jobs older than 90 days that have not been manually closed are automatically moved to "closed" status

Frontend Developer role:

• Built the multi-step job posting form with React Hook Form
• Built the job listing card (used in search results and in the recruiter's "my jobs" list)
• Built the job detail page (candidate view) with apply button
• Built the recruiter's job management dashboard

QA / Tester role:

• Tested: What happens if a recruiter posts a job with no skills selected?
• Tested: What happens if a candidate tries to apply to a closed job (e.g., by bookmarking the URL)?
• Tested: Can a recruiter see another recruiter's draft jobs? (They should not)
• Tested: What happens if the description is 50,000 characters?
• Tested: Double-clicking "Publish" — does it create two listings?

DevOps role:

• Database migration applied to staging first, tested, then pushed to production
• Environment variables for the notification email service confirmed in Vercel
• Sentry monitored for errors in the first 24 hours after deploy
• Feature flagged off for candidates until QA confirmed it was correct

Each role did different work, on different days, in the correct sequence. The feature shipped without a rebuild. This is what wearing the hats deliberately looks like in practice.

Quick Reference Card

Save this and use it before starting any new feature.

Print this. Tape it next to your monitor. Refer to it. The cost of skipping a step is always paid — it is just paid later, at a higher price.

Final Exercise: The Full Role Map

Pick any app on your phone that you use daily — banking, food delivery, ride-hailing, grocery.

Pick one feature (the enrollment flow, the fee payment flow, the result publication flow) and map it to all seven roles:

You will not be able to answer everything — you are looking at a black box. But the act of asking the questions in each role trains you to think in all seven hats. Once you can map someone else's feature to the seven roles, you can plan your own features the same way.