ImmiCase
Own productA case management system for Canadian immigration practice, where programme rules live as data so a regulatory change is a configuration edit rather than a release.
- Tracks every file through its lifecycle with guarded state transitions
- Derives the required document set from programme and applicant circumstances
- Flags missing or expiring evidence before a deadline, not after
- Full audit trail on every state change and document action
- Retention rules enforced by the system rather than by memory
| File | Stage | Evidence |
|---|---|---|
| ITA-2291 · Principal applicant | Documents submitted | Complete |
| ITA-2288 · Spousal sponsorship | Awaiting biometrics | 2 missing |
| ITA-2274 · Work permit renewal | Under review | Complete |
| ITA-2265 · PR card renewal | Evidence gathering | 5 missing |
- Domain
- Regulated case management
- Hard part
- Rules as data — programme changes without a code deploy
- Integrations
- Document store, deadline and notification services
- Constraint
- Audit and retention obligations designed in, not retrofitted
- Built with
- Case management platform · Document store
- Specified first
- Case lifecycle model · Document requirement matrix · Data model · Audit and retention rules
- Engagement
- Analysis, then build · Canadian immigration practitioners
Why it holds up
The problem
Immigration case management is not a workflow somebody gets to design. The stages, the required documents, the deadlines and the evidentiary standards are set outside the software, and they change. A system that hard-codes today’s programme rules is wrong the first time a rule moves — and in this domain being wrong has consequences for someone’s file, not just for a sprint.
What the analysis produced
The central artifact was a case lifecycle model: every state a file can occupy, what moves it between states, and what has to be true before each move is allowed. Alongside it, a document requirement matrix mapped programme and applicant circumstances to required documents, so the requirement set could be data rather than code.
Two constraints came out of discovery and shaped the whole build:
- Rules change, so rules are data. Programme requirements live in a maintainable structure, not in conditionals scattered through the application.
- Everything is evidence. Retention and audit requirements were specified up front rather than added later, because retrofitting an audit trail onto a system that did not plan for one means rebuilding it.
Outcome
The specification is the part worth showing: separating regulatory rules from application logic is a decision that is cheap to make during requirements and expensive to make during build.
Building something like this?
30 minutes, free. Bring a problem or bring a spec.