I've been building software for over a decade.
Laravel trainer. Package author. Solution architect. Juggling multiple products at once — G8Stack, G8ID, Nadi, GatherHub, Warung POS, and more.
And for a long time, I had the same problem every developer has.
I'd jump into code before the thinking was done.
Half-built features. Scope creep. Vague requirements that sounded clear in my head but turned into a mess the moment I opened my editor. I wasn't building products — I was chasing ideas.
Something had to change.
The Shift: Blueprint Before Code
The turning point wasn't a new framework or a new tool. It was a mindset shift.
Build the blueprint first. Code later.
Sounds obvious. But most of us don't actually do it. We treat planning as a formality — something we rush through so we can get to the "real" work.
I stopped doing that. And everything changed.
Here's the workflow I landed on.
Phase 1 — Idea to Clear Direction
Every product starts with a brainstorm. No filters. No structure. Just dumping everything out of my head.
But I don't do this alone.
I bring Claude into the conversation early — not to generate ideas, but to stress-test them. I'll describe what I'm thinking and let Claude push back: Who exactly is this for? What happens if the user does X? Have you considered this edge case?
It's like having a thinking partner available at 2am who never gets tired of your half-formed ideas and isn't afraid to point out the holes.
By the end of this phase I can answer clearly: what exactly am I building, for who, and why does it matter? And more importantly — what are the constraints, the risks, and the things I hadn't thought of yet.
Only then do I move forward.
This phase sounds simple. But skipping it — or rushing through it alone — is the number one reason products stall. You can't build what you haven't clearly thought through.
Phase 2 — Name It. Own the Domain.
Before any file is created, before any command is run — I name the project.
This sounds like a small thing. It isn't.
The name shapes everything: the repo, the folder structure, the domain, the brand, the way you talk about it to clients. Getting it wrong early means renaming things later, and renaming things is painful.
So I take the time. I discuss naming options with Claude — checking for clarity, memorability, and whether it communicates what the product actually does. Then I check domain availability immediately. If the domain isn't available, I keep going until I find a name where both the name and the domain work together.
Only when the name is locked and the domain is secured do I move to the next step.
Phase 3 — Kickoff
With a name in hand, I scaffold the project using kickoff.my — my own tool for getting Laravel projects started with the right foundation.
The project name drives everything here: folder name, repo name, namespace, environment config. It all flows from that one decision made in Phase 2.
Phase 4 — The CLAUDE.md (The Blueprint)
Now I write the CLAUDE.md — inside the project that was just created.
Think of it as a structured brief — not for a client, but for Claude Code (my AI coding assistant). It covers what I'm building, the tech stack, the architecture decisions, naming conventions, and phase-by-phase plan.
Hard cap: 40KB. That constraint keeps me honest. If I can't describe the product in 40KB of structured markdown, I probably don't understand it well enough yet.
Everything that doesn't fit goes into a REFERENCE.md — detailed data models, edge cases, compliance requirements, anything I need visible but not in the main file.
Between the two files, Claude Code has everything it needs to understand the project cold — without me explaining context every single session.
From there, Claude Code reads the blueprint and fills in the docs/ folder — expanding on specs, documenting the data model, breaking down each phase in detail. Full visibility. Nothing hidden.
Phase 5 — GitHub Setup (Before a Single Line of App Code)
This is the part most developers skip entirely.
Before I write any application code, Claude Code creates the GitHub repo and auto-generates Issues based on the phases in my plan. Milestones. Labels. Everything organised.
Now I have a project board that reflects the actual plan — not something I backfilled after the fact.
This alone has saved me hours of context-switching and "wait, what was I building next?"
Phase 6 — Build Phase by Phase
Only now do I start coding.
Each phase has defined deliverables. Each GitHub Issue maps to a real milestone. Claude Code works within the documented context — so there's no guesswork, no AI hallucinations about what I "probably meant", and far fewer errors.
When I finish a phase, I close the issues, review what changed, and update the docs before moving to the next one.
It feels slow at first. It isn't. It's the fastest way I've ever shipped a product that actually works the way I intended.
Bonus: Agent Skills
On top of all this, I maintain a personal library of Claude Code skills — reusable patterns that encode my way of doing things.
Pest testing. Livewire/Flux patterns. API lifecycle. CI/CD pipelines. Package development. Each skill is a structured file that tells Claude Code exactly how I want a thing done.
If you're curious: github.com/nasrulhazim/agent-skills
The Real Lesson
The reason this workflow works isn't Claude. It's not the tools. It's the constraint of having to think clearly before building.
When you write a proper blueprint, you catch the problems that would have killed your project at phase 3. You make architecture decisions consciously instead of by accident. You know — before you write a line of code — what done looks like.
AI just makes the execution faster. The clarity still has to come from you.
Want to Learn This or Work With Me?
If you're a developer or founder who wants to build smarter — not just faster — here's how we can work together:
→ Learn: I run Laravel training sessions covering architecture, clean code patterns, and production-grade development. Reach out to me and ask about upcoming sessions or custom workshops for your team.
→ Hire: Need a solution architect who can take your idea from zero to structured, shippable product? That's exactly what I do. See what I've built at nasrulhazim.com/projects and reach out at nasrulhazim.com.
→ Follow along: I document the journey — products, patterns, and lessons learned — right here on dev.to. Hit follow so you don't miss the next post.
Blueprint first, code later. Build the map before you start the journey.
Top comments (0)