Ship One Populated Example, Document the Structure, Let Others Fork
A framework with no populated examples is a README. A framework with four populated examples is a working pattern nobody can copy without redoing the work.
The reflex of the solo practitioner who builds something useful is to keep the populated version private. The fear is obvious: if the populated version is the product, publishing it gives the product away. The reflex is wrong, and Realtor Copilot v2 is what publishing it the other way looks like.
The framework is MIT-licensed and on GitHub. Four populated case studies ship in the repo. Other practitioners are explicitly invited to add their own market as a new example. The first author owns the canonical examples. The template becomes the category standard. Every fork is inbound.
What is in the repo
Sanitized case-studies surface — if the structure works across these four, the structure works.
| Market | Notable traits |
|---|---|
| Jerusalem, Israel | Multi-language (Hebrew + English), strong international diaspora flow, complex title types (Tabu vs. Khevra Meshakenet). |
| Novato / Marin County, CA | English-monolingual U.S. suburban market — proves the architecture works without any foreign-buyer dependency. |
| Khao Lak, Thailand | Coastal resort, foreign-buyer-dominant, leasehold/freehold structure, multi-language (English / German / Russian / Mandarin). |
| Lisbon, Portugal | Mainstream urban European international-buyer market, post-Golden-Visa context, multilingual, Roman-law title system. |
Four markets, three of them deliberately nothing alike. The point of shipping four is not coverage; it is proof that the architecture survives wildly different market structures. A diaspora-driven city, a monolingual U.S. suburb, a foreign-dominant resort, and a mainstream European capital. If the structure works across those four, the structure works.
Why the case studies are the moat
A framework with no populated examples is a README. Anyone can fork a README. A framework with four populated examples is a working pattern, and the four examples are the part nobody can copy without redoing the work. The populated regions encode local market data, vendor list shape, regulation-surfacing language, and tone choices that a forker has to replicate from scratch for their own market.
The first author of any of these case studies owns the canonical version. Every later fork in that geography is downstream of the canonical. The populated Khao Lak pack is more than a Khao Lak install; it is the reference template every other Thai-coastal-resort agent works from when they build their own.
The fork invitation as a moat-builder
The README ends with an invitation: “Adding your market as a new example.” Other practitioners are encouraged to populate the framework for their own market and submit it back. Counterintuitive on the surface — invite competitors? In practice, every accepted contribution does three things at once.
It expands the proof set, which makes the framework harder to dismiss. It produces a new canonical example whose author is now a peer of the original, but whose example sits inside the original’s repo. It generates inbound from every later practitioner in that geography who finds the case study and wants the populated install for their own block, their own client list, their own languages.
The first-mover does not lose by inviting forks. The first-mover sets the pattern that every fork extends.
The reader’s possibility
There is a category, geography, or client niche in your domain where no specialist exists yet. Not no software — no opinionated, refusal-bearing, populated specialist. The first practitioner to ship one in that slot owns the canonical examples for the next decade.
The barrier is not technical. The framework is markdown files in folders, MIT-licensed, free to fork. The barrier is the deep domain knowledge required to populate the first one well. That part is the work that does not transfer.
What this is not
This is not open-sourcing a product to harvest community contributions and call it a moat. The contributions are real and welcome, but they are not the moat. The moat is being the practitioner whose name is on the original four case studies, whose architectural decisions every fork inherits, and whose contact line every populated install eventually points back to.
This is also not the platform play of building a marketplace and waiting for sellers to show up. There is no marketplace. There is one repo, four canonical case studies, and a contributor file inviting the next agent in the next geography to add a fifth. The architecture stays singular. The forks compound around it.
Why the timing window closes
Every category gets one canonical specialist of this shape. The second specialist in the same category, with a similar surface and a similar refusal list, has to argue its way past the first. The first did not have to argue. The first defined the surface, and every later entrant is positioned relative to that surface whether they meant to be or not.
The window is open in most domains right now because most practitioners with the deep domain knowledge to populate one have not built the framework, and most builders with the framework instinct do not have the deep domain knowledge. The cross-section is rare, the lift is small, and the window closes for a category the moment the first one ships.
Companions in this series: The orchestrator is not the worker · Five locked rules of daily dispatch · Three categories of external workers · The software is free. The fill-in is the product. · The “it won’t” list is the moat.