I've built a registered business on Claude Code. Not one project — the entire operation. Client work, internal tools, products, documents, compliance, operations. This isn't a review from someone who tried it for a week. It's a perspective from someone who depends on it daily for their livelihood.
I'll be specific about what works, what doesn't, and what I've learned about getting the most out of it. Anthropic doesn't need a love letter. They need honest signal from power users.
The Context
Nimbus Forma Studio: a solo web development and systems business based in KL, Malaysia. SSM registered. Paying clients. Shipped products. 14+ repositories across client work, internal tools, and products. Every project built with Claude Code as the primary development tool alongside my own expertise.
My stack: Next.js, TypeScript, Tailwind CSS, Supabase, GSAP, Prisma, Vercel. I work in VS Code. Claude Code runs as my pair programmer throughout every session. I also use multiple Claude skills for different thinking modes — product management, architecture review, design thinking — and the MCP ecosystem for external tool integration.
What Works Brilliantly
Multi-file context awareness. Claude Code understands project structure. When I ask it to add a feature, it reads the existing codebase, identifies the patterns, and generates code that matches. Not just syntactically — architecturally. If my project uses a specific data fetching pattern, Claude follows it. If my components follow a specific naming convention, Claude continues it. This is the difference between AI that generates code and AI that contributes to a codebase.
Iterative refinement. The conversation model means I can say 'that's close but the error handling should use the pattern from the checkout flow' and Claude adjusts. It remembers context within the session. It builds on previous work. This conversational development is fundamentally different from prompt-and-pray. It's closer to pair programming than autocomplete.
Breadth of technical knowledge. In one session, I moved between TypeScript, CSS, SQL (Prisma schema), HTML templates, git operations, shell scripts, and Malaysian legal research (PDPA compliance). Claude handled all of them competently. Not every AI tool can context-switch between writing a PostgreSQL RLS policy and drafting a privacy policy in the same conversation.
The skills system. Claude Code supports specialized skill sets that change how it approaches problems. I use skills for different roles — when I'm thinking like a PM, I activate that context and Claude responds as a PM counterpart. When I'm debugging, it shifts to a diagnostic mindset. This isn't just prompt engineering — it's persistent role context that carries through an entire session and makes the back-and-forth more productive.
The MCP Ecosystem
The Model Context Protocol is what makes Claude Code extensible beyond its training data. MCP servers let Claude connect to external tools and services. I use them daily.
Context7 for documentation lookups — when I need the latest Next.js API or Supabase function signatures, Claude queries the actual current documentation instead of relying on training data that might be months old. This alone eliminates an entire class of bugs where AI generates code using deprecated APIs.
Web search and web fetch for research — when I needed to understand PDPA compliance requirements, Claude searched official Malaysian government sources, fetched the actual legislation text, and synthesised the relevant requirements. The output cited real sources with real URLs. I verified every claim against the source material, but the research acceleration was significant.
The MCP architecture is what makes Claude Code a platform rather than just a tool. Each server adds a capability without bloating the core model. I can add new MCPs as my workflow evolves without waiting for Anthropic to build every integration natively. This is good design — extensibility through a protocol rather than a monolith.
What I've Learned About Getting the Best Output
System-level context beats file-level prompts. When Claude has my project's architecture document, data models, and design specifications loaded as context, the code it generates is dramatically better. Not incrementally — dramatically. The same prompt produces a generic React component without context and a component that matches my design system, uses my data hooks, and follows my error handling patterns with context. This is the single biggest lesson I've learned.
Specific constraints produce better output than open-ended requests. 'Build a contact form' produces generic code. 'Build a contact form with name, email, project type (dropdown), budget (dropdown), and message fields. Validate email with regex. Rate limit to 5 submissions per hour. Post to this Formspree endpoint. Show success/error states. Match the existing form patterns in the codebase.' produces exactly what I need on the first pass.
Reviewing AI output like a PR, not like magic, is essential. When Claude generates 200 lines of code, I don't accept it. I read it like I'm reviewing a pull request from a colleague. Does it handle null cases? Does it clean up event listeners? Does it follow the project's error handling pattern? Are there any security implications? This review catches issues that a casual glance misses. The quality of AI-assisted development is directly proportional to the quality of the review.
Where It Struggles
Novel integrations with sparse documentation. When I integrated Revenue Monster — a Malaysian payment gateway — Claude's help was limited to general OAuth2 patterns. The specific implementation details (RSA signature format, webhook verification, sandbox URL structure) required reading Revenue Monster's actual docs and testing against their API. AI trained on public internet data is only as good as what's publicly documented, and niche regional services are underrepresented.
Business logic decisions. Claude will implement any business logic you describe. But it can't tell you what the right logic is. Should a cancelled order automatically restore stock? That depends on the client's inventory workflow. Should a stringing job be cancelled when its linked order is cancelled? That depends on whether the racket is physically in the shop. These decisions require domain knowledge that doesn't exist in training data — it exists in conversations with the client.
Long sessions with accumulated context. As a session grows long, Claude's ability to maintain consistency across earlier and later changes degrades. Patterns established early in the conversation sometimes get contradicted later. My workaround is to keep architecture decisions in explicit documents that Claude can re-read, rather than relying on conversational memory for structural consistency.
What Changed in My Workflow
Before Claude Code, I spent roughly 30% of my time on architecture and design, 60% on implementation, and 10% on review and documentation. Now it's closer to 40% architecture and design, 30% implementation (much of it AI-accelerated), and 30% review and documentation. The implementation phase compressed. The thinking phases expanded to fill the freed time — which means the thinking is better, not just faster.
I also write more documentation than I used to. Partly because I genuinely enjoy writing documentation — structuring knowledge, making complex systems legible, creating artifacts that make the next person's job easier. But Claude Code turned that preference into a superpower. The documentation I write isn't just for future maintainers anymore — it's a direct input to better AI output. An architecture document I'd have written anyway now also serves as context that makes Claude produce dramatically better code. The incentives aligned perfectly: good process produces good AI output produces good software. For developers who've always resisted documentation, Claude Code gives them a selfish reason to start. For me, it validated something I was already doing.
My debugging approach changed too. I used to spend time staring at code trying to spot the bug. Now I describe the symptom to Claude with the relevant code context, and it often identifies the issue faster than I would have. Not always — sometimes the bug is in my mental model of the system, not in the code. But for mechanical bugs (off-by-one errors, missing null checks, incorrect async handling), AI-assisted debugging is genuinely faster.
The Distinction That Matters
I didn't build my business on Claude Code. I built my business with Claude Code. The preposition matters.
'On' implies dependence. Remove the tool, the business collapses. That's not true. I'm a developer with years of production experience. I can build everything in my portfolio without AI assistance. It would take longer. The quality wouldn't be higher — because I'm already the quality gate. The throughput would drop significantly.
'With' implies partnership. The tool amplifies capability. It handles the mechanical work so I can focus on the thinking work. It's fast where speed matters (implementation) and I'm careful where care matters (architecture, security, business logic). The combination produces output that neither could achieve alone — not because the AI thinks better than me, but because it types faster while I think.
That's what Anthropic got right. Claude Code isn't trying to replace developers. It's trying to be the best tool a developer has ever used. And for this developer, building a business from scratch in Malaysia with no team and no funding — it is.
“I didn't build my business on Claude Code. I built my business with Claude Code. The preposition matters.”