Building Forge IT Systems: A Dev Diary
By COO, Forge IT Systems & Claude
Every consultancy needs a web presence. Most settle for a template, a few stock photos, and a contact form. We wanted something different: a site that actually demonstrates what we do.
The brief was straightforward. Build a modern, production-grade website that showcases our ML/AI and systems consulting services. Make it fast, accessible, and maintainable. Ship it in a week.
The catch? We'd build it using the same human-AI collaboration workflow we use on client projects.
The Stack
We chose Next.js with the App Router — not because it's trendy, but because server components genuinely solve the right problems for a content-heavy site with an admin backend. The full stack:
- Next.js 16 with Turbopack for development
- React 19 with Server and Client Components
- Prisma with SQLite (Turso for production)
- NextAuth.js for admin authentication
- Tailwind CSS v4 with CSS custom properties for theming
- Playwright for end-to-end testing
No component library. Every UI primitive — Button, Card, Input, Tabs, Modal, Sheet — was built from scratch. Not because we enjoy reinventing wheels, but because we wanted full control over accessibility, animation, and the design system.
How the Collaboration Actually Works
The COO drove product decisions: what pages exist, what content says, what the brand feels like. Claude handled implementation: writing components, debugging edge cases, structuring the codebase.
It's not "AI writes code, human approves." It's closer to pair programming where one person has strong opinions about architecture and the other has an encyclopaedic knowledge of React patterns. The human catches when the AI is over-engineering. The AI catches when the human is cutting corners.
Some real examples from the build:
Human direction: "The FAQ page doesn't need to be a client component. The Tabs and Accordion are already client components — the page itself can be a server component."
AI implementation: Removed the "use client" directive, added static metadata for SEO, generated JSON-LD structured data — things the human might not have thought to add unprompted.
Human direction: "The sidebar opens from the right but the toggle button is on the left. That feels wrong on mobile."
AI implementation: Added left as a valid Sheet direction, updated the sidebar, tested the animation. The whole change took about 30 seconds.
This back-and-forth is fast because both sides have context. The AI sees the entire codebase. The human sees the product from a user's perspective. Neither alone would be as effective.
The Unexpected Challenges
Dark Mode That Actually Works
CSS custom properties made theming clean, but getting dark mode right required more thought than expected. Every surface, border, shadow, and text colour needed to work in both modes without looking washed out. We ended up with a three-tier system: --background, --surface, and --elevated — each with carefully chosen values for light and dark themes.
Mobile at 320px
Responsive design is easy to claim, hard to deliver. We tested at 320px viewport width — the smallest common screen size — and found issues everywhere. Email addresses overflowing containers. Navigation breaking. Cards not stacking properly. Each fix was small, but there were dozens of them.
An Admin That Doesn't Break
The admin dashboard needs to work even when the database is down. We added error boundaries at every level: dashboard stats, recent activity, blog editor, contact management. If one section fails, the rest keep working. Try/catch isn't glamorous, but it's the difference between "the admin is down" and "analytics isn't loading, everything else is fine."
E2E Testing Across Browsers
Writing tests that pass on Chromium is one thing. Making them pass on Firefox, WebKit, and mobile viewports — while handling race conditions, network timing, and CSS rendering differences — is a different challenge entirely. We learned to avoid waitForTimeout (always flaky) and instead wait for specific DOM conditions.
What We'd Do Differently
Start with the design tokens. We defined our colour palette early, but the spacing and typography scale evolved organically. Starting with a complete token system would have saved refactoring time.
Write E2E tests earlier. We wrote them toward the end, which meant some tests caught bugs that had been sitting there for days. Testing alongside feature development would have been faster overall.
Skip the blog editor markdown preview initially. We built a full split-pane markdown editor with live preview. It's nice, but a simple textarea would have shipped the blog faster. The preview could have come later.
The Result
A fully custom site with:
- 12+ public pages, each with metadata and structured data
- A complete admin dashboard with blog CMS, contact management, analytics, and settings
- Full dark mode support
- Accessible UI components (keyboard navigation, ARIA labels, screen reader support)
- API rate limiting, input validation, and error handling on every endpoint
- End-to-end tests covering navigation, forms, accessibility, SEO, and API behaviour
Built in about a week of focused collaboration.
The Takeaway
Human-AI pair programming isn't magic. It's a workflow. The human brings taste, product sense, and the ability to say "no, that's not right." The AI brings speed, consistency, and the ability to hold an entire codebase in context.
Neither replaces the other. Together, they ship faster than either could alone.
This post was co-authored by the COO of Forge IT Systems and Claude, the AI that helped build this site. Yes, that's a bit meta. We're comfortable with that.