GLOPPAP is a software builder. We engineer the platform behind regulated Canadian immigration work — evaluation engines, a governed case spine, document, contract, fee and communication machinery, and the compliance rails that keep every file defensible from first enquiry to final decision.
Regulated practice on this platform is conducted under Joy Stephen, Regulated Canadian Immigration Consultant (CICC R419719).
What we build
Immigration software fails in predictable ways: rules live in someone’s head, a file lands in a state nobody owns, and a number on a client’s screen disagrees with the number on staff’s. We build against exactly those three failures.
Scoring and eligibility as a single, testable core — so the answer a person sees for free is the same answer the practice works from.
Every file rides one governed workflow from intake to decision — visible to the client, owned by a named representative, and never in an undefined state.
The part most builds skip. Field-level governance, fail-closed releases and a complete audit trail — the machinery that makes a file defensible.
The build
Each module owns its domain and writes to the same governed record. Nothing is copied between systems, because there is only one system.
CRS, EE67, CLB, education, NOC and settlement funds — one scoring core, six surfaces.
Every file rides one governed workflow; no file can sit in an undefined state.
A single identity across evaluators, services, portal and workbench.
Per-program document sets, vetting, submission timing and reschedules.
Retainers compiled from reusable, plain-English segments — never re-typed.
Fee schedules as data: milestones, instalments, tiering, waivers, tax and caps.
Milestone charges and settlement reconciled straight back onto the file.
Composed, not hand-written — delivered in the client’s mother tongue.
Representative reports assembled from the file itself, as HTML, never re-keyed.
Program rules held as governed data so eligibility follows policy, not memory.
Detectors watch for stranded files and surface them before a client notices.
Every visible field has one governed terminal state. No orphan questions.
How a file moves
Pick a stage. This is the actual shape of the software, not a marketing diagram.
The first answer a person gives is already a governed fact. Intake writes into the same field bank the staff workbench reads, so nothing is re-keyed and nothing is assumed — a field is either answered, deliberately not applicable, or still open.
Evaluators are forward-looking: they report not only today’s standing but what would change it. The same engine that scores a free public evaluation scores the file inside the practice — one implementation, no drift.
Retainers are compiled from reusable plain-English segments, priced by a fee engine that treats the schedule as data — milestones, instalments, waivers, tax and caps — then opens the charges the mandate actually calls for.
A per-program checklist drives collection, vetting and submission timing. Delivery dates and reschedules are held on the file, so the client and the representative are reading the same calendar.
Release is fail-closed. If a prerequisite is missing the platform refuses to advance and says exactly why, rather than letting a file slip into a state nobody owns.
The decision lands on the same spine that carried the file, closing the record and — where a next step exists — opening it, with the whole history intact and reportable.
How we build
These are not values on a wall. Each one is a rule the codebase tests for, and a build that violates one does not ship.
No assumptive logic anywhere. Every mandatory field is resolvable, and “not applicable” is a governed value — not a blank we quietly guess at.
When a prerequisite is missing the platform stops and names it. Silent success on incomplete data is treated as a defect, not an edge case.
The public evaluator and the internal file are scored by the same engine. Two code paths for one rule is how practices end up contradicting themselves.
Fee schedules, thresholds, notification cadences, checklists and stage windows are admin-editable data — changing policy must not require a release.
Where we replace older systems, the old build is a benchmark to beat. We carry the capability forward and leave the defect behind.
Canadian hosting, Canadian regulatory context, and an audit trail that a regulator or a client can actually be shown.
Running live
These are not demos or mock-ups — they are the production engines, open to anyone. Free evaluators, instant, no obligation: see exactly what you would qualify for and what would strengthen your profile.
Live services on the platform
Consultation
Temporary visas
Permanent residence — preparedness
Strategy & job search
Who we are
The crest carries a train for a reason. An immigration file is a journey with named stations, and a passenger who is entitled to know which one they are standing in. That idea is not decoration here — it is the architecture: one spine, six stages, every file on the rails and none of them lost between them.
GLOPPAP builds and operates that platform. We are software engineers working inside a regulated profession, which means our correctness bar is not “it looked right in a demo” — it is whether a representative could defend the file to a regulator, and whether a client could read their own record and understand it.
We replace older systems by benchmark, never by transcription. Where a legacy build did something well, we carry the capability forward and improve it. Where it was faulty, that fault stops with us.
Talk to the people who wrote the spine. Whether you want to run a file on the platform or discuss what we engineer, the door is the same one.
