I went looking for registry software for a gecko breeding community. What I found was a spreadsheet someone shared in a Facebook group, a desktop app last updated during the Obama administration, and a lot of clubs making do with Google Forms.
The tools that exist were built for AKC-style dog kennel clubs decades ago. Nothing was built for the way modern breeders actually work. So I built one.
What a Registry Actually Does (and Why Most People Get It Wrong)
A registry is not a database of animals. It is a chain of verified claims. This animal descends from these parents. This breeder produced it. These show results were judged by these people under these rules. Every link in that chain has to hold up.
Most breed clubs treat registration as a form you fill out. Someone submits a name, a date of birth, maybe a photo. A volunteer reviews it and clicks approve. That works fine until it doesn't. Until someone disputes a pairing. Until a title gets attached to the wrong animal. Until you realize your "registry" is actually a spreadsheet with no referential integrity.
Real registry infrastructure requires the data model to enforce lineage verification at the schema level. Not as a manual review step. Not as a note someone leaves in a cell. At the schema level, where bad data gets rejected before it ever enters the system.
If you want to see what that gap looks like in practice, compare what AKC runs to what a typical exotic animal club runs. AKC has decades of engineering behind verified pedigrees, title tracking, and ownership transfers. Most exotic clubs have a Facebook group and good intentions. That is not a criticism. It is the opportunity.
The Four Problems No One Wants to Talk About
Lineage verification
Parent-offspring linking that can't be faked or hand-waved. The record either traces back through verified parents or it doesn't. There is no "trust me, the sire was my holdback from 2019." The system confirms it or rejects it.
This is the foundation everything else depends on. If your lineage data is unreliable, every pedigree you generate and every breeding decision you make from that data inherits the same uncertainty.
In ReptiDex, lineage is enforced at the database level using self-referential foreign keys. A sire_id that points to a non-existent animal gets rejected by Postgres before any application code runs. The reverse traversal works too. Given any parent, you can enumerate every recorded offspring directly.
# app/models/gecko.py — self-referential lineage on the Gecko model
sire_id: Mapped[Optional[str]] = mapped_column(
String, ForeignKey("geckos.gecko_id"), nullable=True
)
dam_id: Mapped[Optional[str]] = mapped_column(
String, ForeignKey("geckos.gecko_id"), nullable=True
)
sire = relationship(
"Gecko",
remote_side=[gecko_id],
backref="offspring_from_sire",
foreign_keys=[sire_id],
lazy="selectin",
)
dam = relationship(
"Gecko",
remote_side=[gecko_id],
backref="offspring_from_dam",
foreign_keys=[dam_id],
lazy="selectin",
)
This is the canonical SQL pattern for directed parent-child graphs within a single table. The remote_side argument tells the ORM that the relationship points back to the same table, but treats the other end as the parent. It is simple, composable, and it means lineage integrity is a database constraint. Not a policy. Not a hope.
Show result integrity
If a registry tracks titles and championships, those results need to be tied to verified animals. Not display names someone typed into a form. Not a screenshot posted in a group chat. A show result should reference a registered animal by its unique identifier, recorded by a verified judge, at a verified event.
Without this, titles are just text. Any club that wants long-term credibility needs show results to be auditable, not anecdotal.
Pedigree depth and inbreeding risk
This is where most "registry" tools fall apart entirely. Calculating a coefficient of inbreeding (COI) requires multi-generation pedigree depth. You need to walk the tree, find common ancestors, and run Wright's path coefficient method against the results.
Most platforms never get there because they never build the foundation. They store parents. Maybe grandparents. But they do not build a traversable pedigree graph that can scale to the depth COI calculation demands.
ReptiDex builds that foundation. When a hatchling is created, the system recursively traverses the lineage graph and caches a multi-generation pedigree tree directly on the record.
# app/services/breeding_service.py — recursive pedigree builder, depth-limited
async def build_pedigree_tree(
gecko: Optional[Gecko],
db: AsyncSession,
depth: int = 1,
max_depth: int = 3,
) -> Optional[Dict[str, Any]]:
if gecko is None or depth > max_depth:
return None
sire = None
if gecko.sire_id:
result = await db.execute(
select(Gecko)
.filter(Gecko.gecko_id == gecko.sire_id)
.options(selectinload(Gecko.sire), selectinload(Gecko.dam))
)
sire = result.scalars().first()
dam = None
if gecko.dam_id:
result = await db.execute(
select(Gecko)
.filter(Gecko.gecko_id == gecko.dam_id)
.options(selectinload(Gecko.sire), selectinload(Gecko.dam))
)
dam = result.scalars().first()
return {
"id": gecko.gecko_id,
"name": gecko.name,
"morph": gecko.morph,
"image": gecko.profile_image,
"sire": await build_pedigree_tree(sire, db, depth + 1, max_depth),
"dam": await build_pedigree_tree(dam, db, depth + 1, max_depth),
}
The max_depth parameter doubles as a recursion guard and a circular reference safeguard. The cached tree is a deliberate denormalization. Instead of traversing the graph live on every request, the pedigree is computed once at creation and stored as JSON on the record. That trade-off holds up well until parent records are updated retroactively, which is a solvable edge case.
COI calculation is the next layer on top of this. The traversal infrastructure is already in production. The math is on the roadmap. But the point stands: if your platform cannot even walk the tree, it will never answer the question breeders actually care about. "Is this pairing safe?"
Breeder identity and ownership transfer
An animal changes hands. The registry needs to know who produced it, who owns it now, and how that transfer happened. This sounds simple until you realize most clubs track ownership with screenshots of PayPal receipts or a DM that says "sold."
A real ownership transfer is a first-class event in the system. It has a timestamp, a sender, a receiver, and it updates the canonical record. The animal's history stays intact. The breeder's production record stays intact. Nothing gets lost in a group chat.
Why Off-the-Shelf Doesn't Work
Existing tools fall into two buckets. Generic database platforms like Airtable and Notion have no concept of lineage. You can build a table of animals, but you cannot express "this animal's sire is that animal, and here are four generations of ancestors, and here is the inbreeding coefficient for a proposed pairing." That is not a feature gap. It is a category gap.
The other bucket is legacy kennel software. Applications built for dog clubs in the early 2000s that assume a single-breed, single-club model with a desktop-only workflow. They work for the community they were built for. They do not translate to the exotic animal world, where breeders work across species, collections change hands frequently, and nobody is running a Windows desktop app in 2026.
The real problem is not features. It is domain modeling. A registry is a directed graph of relationships with trust constraints at every edge. An animal node connects to parent nodes, breeder nodes, owner nodes, and event nodes. Each connection has rules about what makes it valid. You cannot bolt that onto a spreadsheet and call it infrastructure.
I know this because I built it. ReptiDex launched on the App Store in early 2025 and hit 50 paid subscribers within 9 days. It already has parent-offspring linking, a multi-generation pedigree tree, and QR-code-to-live-record functionality. It is not a concept. It is in production, tracking real animals for real breeders, right now.
What I'd Tell a Club That's Thinking About This
Start with your data model, not your feature list. If your schema can't answer "show me every descendant of this animal and their health outcomes," you don't have a registry. You have a contact list with extra steps.
Ownership transfer is the hard part. Not technically. Politically. Every club has to decide what "verified" means for their community. Does a transfer require both parties to confirm? Is there a fee? Can it be reversed? The software should enforce whatever the club decides. It should not make the decision for them.
Think in generations. A registry that only tracks one generation deep is a baby book. The real value compounds over time as pedigree depth grows. Five generations of clean data lets you make breeding decisions that one generation never could. Build for the breeders who will use this platform in ten years, not just the ones signing up today.
You do not need to build this from scratch. But you do need someone who understands the domain. A generic dev shop will build you a CRUD app and call it a registry. It will have forms and tables and a login screen. It will not have lineage verification, pedigree traversal, or the domain logic that separates a real registry from a database with a nice UI.
I am a breeder who also happens to be a senior software engineer. I have been in the animal world since I was five years old. I showed American Bullies under ABKC and UKC. I breed crested geckos. I built ReptiDex because I needed it to exist, and it did not. That is a different starting point than "we found this niche on a market research call."
If you run a breed club or registry organization and any of this sounded familiar, I would like to hear what you are dealing with. The infrastructure gap is real, and it is solvable.
Top comments (0)