Building products using Augmented Intelligence
Since launching domainion.app, several people have asked about the process behind building it. Here’s a quick look under the hood. Local models, intentional preparation and some old-fashioned craftsmanship.
domainion.app dashboard
Models Won’t Build Your App for You
Before I started building the MVP, I tried describing the entire project to a model. The results were disastrous, to say the least. My prompts were (likely) too broad or I perhaps expected too much. Regardless, they failed, miserably.
What I quickly learned was that models need an incredible amount of direction. One wrong turn sends you down a rabbit hole, and the only way out is to stop and restart. The bigger issue was missing t-shaped context to solve smaller problems, one at a time. Like a true vibe-coding bro, I was trying to do everything all at once.
The Augmented Intelligence Shift
After more research, I found a better way. I experimented with tools like nwave.ai, Claude’s skills, and obra/superpowers. By the end of that process, my local models had developed a deep understanding of Domain-Driven Design. They had access to books by Eric Evans and Vaughn Vernon, grasped multi-tenancy architecture, and understood design patterns from multiple apps that implemented multi-tenancy in different ways. They held memory banks of my research, notes, and architectural deep dives, all before I wrote my first MVP user story.
Planning > Coding
Not a surprise but a learning opportunity. What I ended up with were specialised local agents ready to pair-program. Almost like onboarding new engineers, letting them explore the requirements and codebase before committing a single line to production.
I had created specialised agents that worked exactly like onboarding new engineers and letting them explore the requirements and codebase before asking them to start committing code to production.
Planning was more than half the work required to deliver the final outcome. It all started with a couple of goals, 3 epics, and 4–6 user stories (which grew over time).
Sprint timeline across 20 epics
This is what I call sharpening the axe. Do the hard work upfront, and cutting down the tree becomes effortless.
Some of you might wonder: why waste all that time? Simple: I am the customer. The first proof-of-concept lived as a spreadsheet. I solved a problem for myself; if others find it useful, that’s a great bonus.
Once I grouped cross-cutting concerns into clear features, I delivered everything in sprint cycles. More than half the work was done using local models like Qwen3.6 and DeepSeek. The rest — mostly reviews and refactoring suggestions to keep token costs low — were handled by Claude and Codex, all within my monthly subscriptions and occasional top-ups. Never was code written without tests and never ready for review without tests passing.
For the curious, here are some of the cross-cutting concerns that were developed together from the release sprint: security, marketing, legal, dashboard, billing, docs, devops and infrastructure. At launch I had delivered almost 100 user stories across 20 epics.
Completed user stories at launch
The Real Challenges (And the Takeaway)
The biggest hurdles? Not providing the correct context, missing direction, and ambiguous requirements. Without clear specs, no model could have built what I envisioned.
This brings me to an important point. We cannot call these models intelligent — especially with a human-in-the-loop approach. It’s better to call them Augmented Intelligence: tools that require our authenticity and direction to generate something useful.
We cannot keep calling this intelligence artificial if we have a Human-in-the-loop (HITL) approach. It’s best we label these systems as Augmented Intelligence that requires our authenticity and direction to generate something useful.
What was delivered was an early access product that has a full end-to-end SDLC, ready to be tested against a potential market.
Why Local Models Matter Now More Than Ever
Given recent news about Amazon and Uber using token usage as a performance metric (and later backtracking due to costs), local development becomes even more relevant. A full-stack app built with local models means you don’t have to:
- Trade off velocity against token costs
- Share your data with state-of-the-art models
- Depend on third parties that can raise prices on a whim
Intentional upfront thinking + a lightweight process + local models = a fast, solid, and sustainable development workflow.
Originally published on Medium.
Hero image by Lorenzo Herrera on Unsplash.