School Choice and Unified Enrollment Software: Why the Match, the Waitlist and the Appeal All Break in Public

Why unified enrollment is unlike any other application system a city runs

The results go out on a Friday in March. Within an hour, a parent whose child was placed at their sixth choice will call a board member. By Monday a reporter will ask how the algorithm works. Within a month someone will file a records request for the seed and the run log, and if your answer is that the vendor ran it, you have a political problem that no amount of software features will solve.

That is the structural difference. An enrollment lottery is not an application system with a random number generator at the end. It is a public decision procedure that allocates scarce seats and, with them, per pupil funding, and it has to be explainable, reproducible and defensible to people who are angry and entitled to an answer. Most software categories fail quietly. This one fails on the local news.

The tooling is uneven for a reason. SchoolMint is strong on the family-facing side, application capture, communication and registration, and it is a reasonable choice where the matching logic is simple. Avela was built specifically for unified enrollment and matching and is the most credible packaged option if your rules fit its model. PowerSchool Enrollment is genuinely good at registration forms and the handoff into the student information system, and is not a matching engine. Where all three strain is the same place: the part of your process that exists because your board, your state, or a consent decree said so, and which nobody else in the country implements the same way.

Problem 1: priority tiers are local policy, and policy changes in March

Write out your actual rules and they are never as clean as a settings page. Sibling priority, but does a sibling in a feeder school count, and what happens when the sibling's own placement is not yet decided in the same run. Geographic priority, but by walk zone polygon, attendance boundary, or the neighbourhood definition the board adopted last year that does not match either. Socioeconomic priority through a weighted lottery, which federal Charter Schools Program rules permit charters to run for educationally disadvantaged students but which has to be implemented exactly as adopted. Continuing student rights. Staff children. Programme specific eligibility for dual language or gifted seats.

Then the board amends one tier in February, six weeks before the run, because a council member heard from constituents. A configured product means a vendor ticket, a release window and a hope. That timing is the single most common reason cities we work with move to a build: the policy owner and the implementation have to be in the same building.

A custom build represents priorities as ordered, composable rules with an effective date, so this year's run uses this year's policy and last year's run can still be reproduced exactly as it happened. Every applicant's tier assignment is stored with the reason, which is what lets a staff member answer a parent's call in one minute instead of escalating it.

Problem 2: the match is an algorithm you will have to explain in public

Most unified enrollment systems use a student proposing deferred acceptance match, the Gale-Shapley family of algorithms, because it has a property parents deserve: listing your true preference order cannot hurt you. That property is worth defending in plain language at a community meeting, and it is the reason cities moved away from first-choice-first schemes that punished families for ambition.

The details are where implementations differ and where public trust is won or lost. A single tiebreak number per student, used at every school, produces different outcomes and different waitlist behaviour than a separate random number per school. Neither is wrong. Your board has to choose, and your system has to do what was chosen and say so.

The requirement that packaged tools most often underserve is verifiability. The right pattern is to publish a commitment to the random seed before the run, for instance by publishing a hash of the seed and the input file, then release the seed and the anonymised input after results so that anyone can rerun the match and reproduce the assignment. That turns a trust problem into an arithmetic problem. It also protects your staff, because the accusation that someone put a thumb on the scale becomes checkable rather than deniable. If your current vendor cannot produce a rerunnable record, you do not have an audit trail, you have an assurance.

Capacity is the other detail that breaks generic implementations. Seats are not one number per school. They are per grade, per programme, per seat type, with special education programme capacity, bilingual programme capacity and general capacity interacting, and with a kindergarten class size limit that is a state rule rather than a preference. The match must respect all of them simultaneously, which is why a spreadsheet based process quietly overfills programmes every year.

Problem 3: the waitlist is a six month operation, not a list

The match is one day. The waitlist is March through October, and it is where families actually experience your system. A seat opens because a family moved. Everyone below moves up. Someone accepts, which vacates their held seat somewhere else, which cascades. Meanwhile schools want to plan staffing, and a principal who watches a roster move daily starts calling families directly, which is how a parallel unofficial process gets started and how equity guarantees get lost.

What packaged tools typically provide is a static ordered list and a manual offer function. What the operation needs is automatic cascading with rules: offer windows with a defined expiry, automatic decline after the window, position preserved or forfeited according to policy, and a hard stop on manual overrides without a recorded reason and an authorised user. Every offer, response and movement belongs in an append-only log, because the question you will be asked in September is why a specific child at position four did not get a seat that a child at position nine received, and the answer must be a record rather than a recollection.

The family side deserves the same attention. Waitlist position should be visible, honestly, including the fact that position twelve at a school that never moves is not hope. Text and email in the family's language, with a one tap accept or decline, will do more for your yield accuracy than any amount of internal tooling, because the alternative is a phone call to a working parent during school hours.

Problem 4: addresses, boundaries and residency verification

Every geographic priority depends on turning what a parent typed into a verified point inside a polygon. Your city's geographic information system holds the parcel data, your district holds the attendance boundaries, and the two disagree in enough cases to matter.

Packaged systems geocode with a general purpose service, which is fine until it silently places a family on the wrong side of a line and the appeal arrives with a lease attached. A build should use the authoritative local parcel layer, resolve to a parcel rather than a street interpolation, record confidence, and route ambiguous cases to a human queue before the match rather than after it.

Two obligations sit on top of this and are routinely bolted on late. Students experiencing homelessness have rights under McKinney-Vento that make an address requirement inappropriate as a hard gate, so the system needs a path that does not force a family to produce documents they do not have. And foster and military family provisions in your state may add their own priority and timing rules. Design these in at the start; they are painful to retrofit into a matching pipeline.

Problem 5: everything after the match, which nobody budgets for

Appeals need a workflow with a stated basis, a reviewer, a deadline and a recorded outcome. Late applicants keep arriving all summer and need a defined position rule so that lateness does not become an advantage or a random penalty. Mid-year transfers run against live capacity. Every placement has to land in the receiving school's student information system, and if you have charters in the run, that is several different systems with several different identifier schemes, which means you need a stable student identifier across sectors or you will be reconciling duplicates by hand in September.

This tail is where staff time goes and it is the most common thing a city discovers it did not scope.

What this costs and how long it takes

From Digital Heroes delivery experience, a first release covering the common application in multiple languages, priority rules with effective dates, the deferred acceptance match with published verifiable seeds, and results release runs $80,000 to $180,000 in 14 to 20 weeks. The full platform adding cascading waitlists with offer windows, parcel level address validation, residency and document review, appeals, late applicant handling, mid-year transfers and student information system integration across sectors runs $200,000 to $450,000 phased over 6 to 12 months.

What drives the number: how many sectors participate, because district plus charter plus a private or state voucher programme means several governance bodies and several student information systems. The number of languages, since translation of a legally consequential application is professional work and not a plug-in. Programme seat complexity, because dual language and special education seat interactions multiply the constraint model. And the immovable deadline, since an enrollment season does not slip, which means schedule risk has to be bought down with a narrow first release rather than argued away.

Build versus buy, and when buying is right

Buy if you are a single district running magnet or transfer lotteries with straightforward sibling and boundary priorities, no charter participation and no unusual seat types. SchoolMint or PowerSchool Enrollment will handle the application and registration, and the match at that scale is not the hard part. Look seriously at Avela before you commission anything, because if your rules fit its model you will save a year and considerable money, and we would rather tell you that than sell you a build you do not need.

Build when two or more of these are true. Charters and district schools must be matched together under a governance agreement. Your priority rules come from board policy or a court order and change on a political calendar rather than a release calendar. You need to publish a seed and let a third party reproduce your match. You have programme seat types that interact. Your waitlist operation runs for six months and currently depends on principals making phone calls. The test is simple: if a reporter asked you to prove the draw was fair, could you, today, without asking a vendor. If not, that is the gap you are buying.

How to choose a developer for enrollment lottery software

Ask them to explain student proposing deferred acceptance in plain language, then ask what changes when you use a single tiebreak instead of one per school. If they cannot do both, they will implement a lottery, not a match, and you will find out in March.

Ask how they make a run reproducible. The answer should involve committing to a seed before the run, versioning the input snapshot and the rule set, and being able to rerun and get an identical assignment. Anything less is not auditable.

Ask how they will handle a board amendment six weeks before the run. Effective dated rules plus a harness that replays last year's applicants against the new policy is the answer you want.

Ask about student identifiers across sectors and about McKinney-Vento, unprompted preferably. Then ask who owns the code and get it in writing before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit, which for a public body is not just commercial hygiene, it is what lets you answer a records request without a vendor's permission.