Tribal Government Services Software Problems: The 7 That Put the Roll at Risk, and How to Avoid Them

Why does the build get scoped as a membership list instead of a genealogy engine?

A membership list answers who is a citizen today. That is the question everybody asks in a scoping meeting, so that is what gets specified: a searchable register, addresses, contact details, a status field, letters. All useful, all cheap, and all of it misses the actual requirement.

A tribal enrollment system has to answer why somebody is a citizen, and be able to prove it decades later. That means the model underneath is a family graph, not a table of people. Every enrolled citizen connects through documented parentage to ancestors on a base roll, and the enrollment decision is a computation over that graph against criteria set by your constitution. Blood quantum where it applies is computed from the graph. Dual enrollment checks with other tribes run against it at application time. None of this is visible in a demonstration, so it gets cut, and what arrives is a prettier version of the Access database the office already has.

Write the acceptance test as a lineage question. Take a contested line that your enrollment officer can currently trace only from memory and the index cards, and require the system to produce the descent chain with a source document attached to every relationship. Then require that applying a correction three generations up recomputes downstream and reports exactly which determinations were affected. If a developer cannot describe how that works, they have not built this before.

What goes wrong when you convert index cards and the Access database?

The records conversion is the dominant cost variable in this category and it is not software work. Your history is a base roll photocopy in a binder, a drawer of index cards recording family lines in a predecessor's careful handwriting, family charts in a different drawer, and a database somebody built years ago that holds current members but not the descent chain connecting them.

What goes wrong is scope. A tribe decides that the entire archive must be converted before go live, and the project stretches by a year for data about lines nobody is currently deciding anything on. The second failure is treating conversion as data entry to be outsourced. It is not. Reading a hand written card and deciding whether two entries refer to the same ancestor is judgement work that only your enrollment staff can do, and it has to happen alongside their live caseload.

Sequence it: currently enrolled citizens and their immediate ancestors first, then work outward as capacity allows. Everything else stays as scanned images attached to the closest known record until somebody needs it. Scan and preserve the originals regardless of the conversion schedule, because the paper archive is irreplaceable and a fire or a flood ends the conversation about verification entirely. Budget the conversion in enrollment staff days on the plan, visible to council, because it is the line that gets absorbed and then blows the timeline.

Why do the programme and payment integrations break after launch?

The pattern that fails is one department at a time. Enrollment goes live and works. Then housing gets connected, and it turns out housing maintained its own list of the same citizens with different household compositions, because a household to housing is not a household to elder services. Then education connects with a different definition again. Each integration works on the day it is tested and drifts within a quarter, because each department kept editing its own copy.

Distribution integrations break differently and more publicly. A per capita run executed against a live register rather than a frozen snapshot will shift under you: an enrollment approved mid run, an address updated, a guardianship changed. Payment file rejections come back from the bank for stale addresses and closed accounts, and if there is no reconciliation step the rejections sit unresolved while citizens call the office.

Two rules prevent both. Enrollment is the identity spine and every programme reads from it rather than copying it, with household composition maintained once and effective dated because households change. And eligibility for a distribution period is a snapshot taken and frozen at a defined date, never a live query, with the ability to regenerate exactly what the register looked like on that date. That regeneration is what you need when a citizen disputes a payment two years later, and it is the feature that gets skipped.

What happens when data sovereignty is treated as policy rather than architecture?

This is the gap most vendors leave and it deserves stating plainly. Tribal data sovereignty means your nation determines who holds, accesses and governs data about its citizens. Written as a paragraph in a contract, that commitment is worth very little. It has concrete technical consequences and each one is a decision somebody makes during the build, usually without asking.

Where does the data physically sit. Whose cloud account owns it. Who holds administrative credentials. Can a subcontractor see production data. What happens to backups and who can restore them. What does the exit process produce if the relationship ends. And what, exactly, is the developer permitted to do with the data, including whether it may be used to train models or build products. A standard commercial agreement answers most of those in the vendor's favour by default.

Settle every one of them before kickoff, in writing. Infrastructure in accounts owned by the tribe. Credentials held by tribal staff. Data residency decided by the tribe. Role based access reflecting your own governance, including the reality that some records are restricted to the enrollment committee and are not visible to general administration. A full export path producing usable data rather than a proprietary file. An explicit prohibition on any other use of tribal data. If a vendor's standard contract cannot accommodate that list, the contract is telling you what they think of your sovereignty.

Should you build custom or configure what you already own?

Here the honest answer is unusual: there is no meaningful commercial category to buy. What gets sold to tribes is general purpose membership or customer relationship management (CRM) software, county style benefits systems, or genealogy tools. None models citizenship under a tribal constitution, per capita distribution or minors trust accounts. Fitting one of them to your rules means encoding your constitution inside a customisation layer owned by somebody else, which is the worst version of every available option.

So the real comparison is build against continue. Continue with the Access database you already have, for now, if your nation has a stable roll of a few hundred citizens, no per capita distribution, and an enrollment officer who is not close to retiring. That is a defensible position and we say it to nations regularly. Spend the money instead on digitising the paper, backing it up off site, and documenting how the current database is structured so it is not one person's private knowledge.

Build when any of these are true, and most nations find several are. Your enrollment register determines money, whether per capita, housing or scholarships. Only one person can trace a contested line. You field regular verification requests by hand from courts and agencies. Your programmes each maintain their own list of the same citizens. Or the person who built your current database no longer works for the tribe.

How do hidden costs get into the quote?

Records conversion is first and it is usually understated by a wide margin, because it looks like data entry and is actually adjudication by your own staff. Ask for it to be quoted as a separate phase in enrollment staff days, with an agreed stopping point, rather than folded into a fixed price where a developer has guessed at how legible your cards are.

Distribution complexity is second. Minors trust accounts are a per person ledger held across fifteen or eighteen years with interest allocation, guardianship changes and release conditions requiring document verification. Add garnishment orders, rules for incarcerated citizens, deceased member distributions to estates and address hygiene for citizens spread across the country, and the run becomes the most operationally dangerous thing the administration does. Third is programme breadth: housing, education, assistance and elder services each carry their own eligibility rules and their own reporting obligations tied to their funding source, so each is a phase rather than a checkbox.

Keep the first release to enrollment, workflow and verification at $70,000 to $150,000 over 14 to 20 weeks, and phase distributions and programmes after it. The full platform at $180,000 to $420,000 across 8 to 14 months assumes that sequence, and reversing it produces a distribution system sitting on a register nobody has validated.

What separates a build that works from one that fails here?

Ask who will own the infrastructure accounts. If the answer is anything other than the tribe, stop the conversation there. Everything else is negotiable and this is not, and a developer who hesitates on it has told you how the rest of the relationship will go.

Ask them to model lineal descent with a blood quantum computation and a correction applied three generations up. A developer who understands the problem immediately asks about recomputation, stored historical determinations and audit. A developer who draws a members table with a quantum column will build you a prettier version of what you already have. Ask how rules that only your nation uses are handled, and require configuration with effective dates and stored determinations, so an amendment passed by referendum does not retroactively rewrite a determination made under the previous rule. Any answer involving hard coding your constitution means a change request every time your council acts.

Ask how a verification request is logged, because the log matters as much as the letter: the office should be able to show every disclosure it has ever made, to whom, and on what authority. Then start with the exercise that writes the specification for you: take three contested lineages your enrollment officer can currently trace only from memory, and document them end to end with sources. Whatever makes that hard is what the system has to solve, and if only one person in the building can complete the exercise, you have also just measured your real risk.