Domain Immersion: The Non-Negotiable First Skill in AI Product Building
2026-03-08 · 5 min read · Janaina Maia
Before Urbix was a product, it was a problem I didn't fully understand.
I knew the shape of it. Planners and engineers spent hours hunting through development codes, zoning rules, and council policies to answer questions that should take minutes. They needed faster access to reliable information. AI could help.
But could I build it? Not yet. Because I didn't know the domain.
Urban development and planning has its own language. Setbacks, overlays, DAs, LEPs, planning schemes, complying development pathways. I had heard some of these terms before. I had no idea how they fit together, what made one council's rules different from another's, or what questions a planner actually asks at 4pm on a Wednesday under deadline pressure.
That gap matters more than most people building AI products want to admit.
The AI Doesn't Know What It Doesn't Know. But You Do.
This is the core problem with domain-naive AI development. A language model trained on the internet can tell you a lot. It can produce confident, fluent text about zoning regulations in a Queensland council that it has never actually ingested. It can blend general planning principles with outdated rules and present the mix as current fact.
The model doesn't flag this. It doesn't know it's wrong. It just answers.
If I didn't know the domain, I wouldn't catch these failures either. I'd test the AI on the questions I thought planners asked, get plausible-sounding answers, and ship a product that was dangerously wrong in ways neither the AI nor I could see.
Domain immersion is what lets you catch what the AI can't.
What 20 Hours Actually Gets You
I set a personal rule before starting Urbix: 20 hours minimum in the domain before writing any system prompts or making technical decisions. Here is what I did with those hours:
- Read actual planning scheme documents. Not summaries. The real ones.
- Sat in on council pre-lodgement meetings where planners explained requirements to property developers.
- Talked to a town planner and a civil engineer with 15 years of experience each. Asked them to walk me through a real project from start to finish.
- Looked at real development applications that were rejected. Studied the rejection reasons.
- Tried to answer planning questions myself, using the documents, before testing any AI on them.
That last one was the most valuable. When I tried to answer questions from the actual documents, I discovered they were nearly impossible to navigate without training. The information was buried, cross-referenced, ambiguous. I understood exactly why planners struggled. I also understood what a correct answer looked like. And what a confidently wrong answer looked like.
The SME Problem
You need a subject matter expert. Period.
You can be the SME yourself if you invest the time. Or you can work with one. But there is no third option where you skip this step and build something that works in production.
The mistake I see constantly is treating SME access as a validation step. Teams show the expert the demo after it is built. That is backwards. The SME should be shaping what you build before you build it.
For Urbix, my SME relationships were the most important early decisions I made. Not the tech stack. Not the vector database. Not the embedding model. The planners and engineers who were willing to sit with me, break down their real workflows, and tell me when the AI was wrong. They saved us from at least a dozen catastrophic design decisions: things that would have felt right to me, felt plausible in a demo, and been completely wrong in daily professional use.
Domain Immersion Changes How You Prompt
Once I understood the domain, my system prompts changed completely.
Early prompts were generic: you are a helpful planning assistant, answer questions about development codes. After domain immersion, they became specific. I knew what questions to expect. I knew which council policies were commonly confused with each other. I knew what a planner needed to know versus what would waste their time.
I could write prompts that anticipated real scenarios, set appropriate scope limits, and defined what correct looked like in practice. Without the immersion, I would have been writing prompts in the dark. The AI would have been operating without meaningful constraints because I wouldn't have known what constraints mattered.
The Minimum Viable Version
Not everyone has 20 hours to spend reading planning schemes. Here is the minimum viable version if you are working with an SME rather than being one yourself:
- Do three deep-dive interviews with a genuine expert. Not demos. Interviews about their actual workflow.
- Shadow someone doing the job for one day.
- Attempt to do the job yourself for two hours. Even if you fail, you will understand the difficulty.
- Build a known-answers test set from real professional output before you write a single prompt.
The test set matters most. If you have 50 real questions with answers verified by an SME, you have something to measure against. Without that, you are building blind and calling the results a product.
The Uncomfortable Truth
Building AI products in unfamiliar domains without domain immersion is not bold. It is lazy. And the people it hurts most are the domain professionals who trust the product when it counts.
Planners using Urbix are making recommendations that affect real development projects. Engineers are answering technical questions that go into reports. If the AI confidently gives them wrong information, the consequences are not theoretical.
Domain immersion is what makes the difference between AI that professionals can rely on and AI that sounds good until it doesn't. Invest the time. It is not optional.