When I registered Nimbus Forma Studio in April 2026, I had zero clients and zero revenue. What I did have was a fully functioning business operating system that tracked clients, generated documents, managed projects, and had an AI assistant that could answer questions about my own business data.
Everyone told me to just use Notion. Or Trello plus Google Sheets plus Calendly plus Wave plus five other tools that sort of integrate if you pay for the right plan and squint hard enough. I'm a developer. I knew exactly what I needed. So I built it.
The Problem with Duct Tape
The typical freelancer tech stack looks like this: Notion for project management, Google Sheets for finances, Calendly for booking, Wave for invoicing, WhatsApp for client communication, a folder of Word documents for quotes and contracts. Six tools. None of them talk to each other. You're the integration layer — copying data between tabs, reformatting the same information five times, and praying you didn't miss an update somewhere.
I've worked in agencies. I've seen this stack fail at scale. A client's payment status changes in one place but not another. A project milestone gets hit but nobody updates the tracker. An invoice goes out with last month's numbers because someone copy-pasted from the wrong sheet. These aren't edge cases. This is every Tuesday.
I wanted one system. One source of truth. One place where a client moves from lead to active to completed, and everything downstream — documents, invoices, project status — updates automatically.
Designing the Architecture First
Before I wrote a single line of code, I spent three days on architecture. Not because I enjoy architecture diagrams — because I've shipped enough projects to know that the most expensive bugs live in bad architecture, not bad code.
I mapped every data flow. Client comes in as a lead. Lead converts to active project. Active project has line items, milestones, payment schedules. Each milestone triggers a status update. Each payment triggers a financial record. A completed project moves to the archive but stays queryable. I drew this on paper first. No code. No AI. Just thinking about how a business actually runs.
Then I chose the stack. Next.js because it's what I know deeply and what I ship client projects on — dogfooding my own tools. Supabase for the database because PostgreSQL is battle-tested, row-level security means I can enforce data access at the database layer, and the real-time subscriptions let me build a dashboard that updates live. React Flow for the visual workspace because I wanted to see project dependencies as a graph, not a list.
The architecture decision I'm most proud of: the document engine. Instead of generating PDFs programmatically — which always look terrible — I designed 27 HTML templates with a placeholder token system. Every template uses {{CLIENT_NAME}}, {{PROJECT_TOTAL}}, {{LINE_ITEMS}} tokens that get replaced at generation time. The output is a styled HTML document that I export to PDF through the browser's print engine. The documents look designed because they are designed — they're HTML and CSS, the same tools I use to build websites.
The Document Engine
27 templates covering the entire client lifecycle. Pre-sale: capability deck, proposal, quote. Onboarding: welcome email, scope document, timeline. During the project: progress report, change request, milestone approval. Delivery: handoff checklist, documentation guide, training notes. Post-project: feedback form, testimonial request, maintenance proposal. Each one follows the Nimbus V6 design system — same fonts, same colors, same spacing. When a client receives a document from me, it looks like it came from a studio with a design team. It came from one developer with a system.
The key insight: I don't decide what to send when. The system decides. A project hits the 'design approved' milestone? The scope confirmation document generates. A payment comes in? The receipt generates and the project tracker updates the financial summary. I'm not managing documents. I'm managing a business, and the documents happen as a side effect.
The AI Layer
Forge has an AI chat panel powered by Google's Gemini API on the free tier. But it's not a generic chatbot. It has context about my actual business data — active clients, project statuses, revenue figures, upcoming deadlines. I can ask it 'which projects are behind schedule?' or 'what's my outstanding receivables total?' and it queries my data and responds with real numbers.
The implementation is straightforward: I inject a system prompt with serialised business context from the database, then let Gemini handle the natural language interface. The free tier gives me 15 requests per minute and a million tokens per day. For a solo business owner checking in on their data a few times a day, that's unlimited for practical purposes.
The cost of running AI in my business OS: zero ringgit per month. The value: I can get a business health check in 10 seconds instead of opening three tabs and doing mental arithmetic.
What Claude Code Actually Did
Here's where I want to be precise, because the narrative around AI-assisted development is usually either 'AI wrote everything' or 'AI is useless.' Neither is true.
Claude Code built the implementation. The 27 HTML templates — I designed the first three, established the design system tokens, defined the placeholder convention. Then Claude generated the remaining 24 following the patterns I'd set. Each one needed review. About half needed tweaks to spacing or content flow. But the generation-to-review workflow was dramatically faster than writing each template from scratch.
The webhook notification system — I described the architecture: when a status changes in the database, fire a POST to a local endpoint that triggers a UI update via server-sent events. Claude implemented the entire pipeline. The webhook handler, the event emitter, the client-side listener, the reconnection logic. I reviewed the code, tested the edge cases, caught one race condition where rapid status changes could fire duplicate events. Fixed that. Shipped it.
The Supabase schema with row-level security policies — I defined which roles can access which data. Claude translated those rules into PostgreSQL RLS policies. This is exactly the kind of work where AI excels: translating a clear specification into correct syntax. The specification was mine. The syntax was Claude's.
What I Had to Do Myself
Architecture. Every decision about what data lives where, what connects to what, what triggers what — that was me. Claude doesn't know how my business runs. It doesn't know that a Malaysian freelancer needs 50/25/25 payment milestones or that SSM registration numbers follow a specific format. It doesn't know that my clients communicate primarily through WhatsApp and expect responses within hours. These domain decisions shaped the entire system.
Prioritisation. Forge could have a hundred features. I built the ones that matter for a solo operation in its first year. Client pipeline. Document generation. Project tracking. Financial overview. That's it. No team management module. No resource allocation. No Gantt charts. A product manager makes these scoping decisions by understanding the user — and in this case, the user is me. Claude can build anything you ask it to. Knowing what not to ask it to build is the actual skill.
Quality assurance. Every component Claude generated, I tested. Not just 'does it render' — does it handle the edge case where a client has no projects yet? Does the financial summary show the right numbers when a payment is partially refunded? Does the document template break when the project has 15 line items instead of 5? These aren't things you can delegate. They require understanding the business logic at a level that only comes from having designed it.
Why This Matters
I built Forge before taking my first client because I believe you should use what you sell. When I tell a client 'I'll build you a custom system that replaces your spreadsheets,' I'm not theorising. I'm describing my daily experience. Every feature in Forge has been tested by daily use. Every workflow has been refined by actual business operations.
And when I build their system, the architecture decisions come from the same thinking. What data flows where. What triggers what. What the user actually needs versus what sounds impressive in a proposal. That thinking isn't something I learned from a tutorial. It's something I learned by building a system I depend on every single day.
“The tool doesn't make you a builder. Being a builder makes the tool useful.”