A licence, a permit, a grant or a scheme enrolment often asks people for documents, sends the file across several desks and returns it when something is missing. This page sets out how we would think about software for that kind of work; whether we suit a given project depends on its procurement and delivery conditions.
Take an application to a local body for a trade licence. The applicant fills in a form, uploads identity and premises documents and pays a fee. A clerk checks completeness, an inspector may visit, and an officer approves or rejects. If a document is unclear the file goes back, and too often the applicant only finds out by visiting the office.
Most of the friction sits in those handoffs: what exactly is missing, who holds the file now, and what happens after a resubmission. Software can make those points visible to both sides without changing who has the authority to decide.
The conditions around such work matter as much as the software. Procurement eligibility, hosting location, accessibility standards, language requirements and any mandated security review differ by department and by country. We would establish those for the specific project before discussing a build, and we make no assumption that we qualify for any particular tender.
The form asks only what that service needs, explains each document in plain words, and checks file types and completeness before submission. Each application gets a reference the applicant can quote.
The case moves through agreed stages, each with a responsible role and a target time. Supervisors see queues by stage and age, and reassign files when someone is away.
A reviewer selects the missing or unclear item and adds a note. The applicant sees that request, uploads against the same case, and the file goes back to the reviewer who asked.
Approval or rejection records who decided, on what basis and when. An audit trail keeps every stage change, so a later query can be answered from the record itself.
The applicant sees the stage, any request for information and the decision with its reason. Messages use plain language, and the portal can be offered in the languages the service works in.
Staff see the full file, internal notes, inspection reports and the case history. Access follows each officer's role and jurisdiction, and internal notes never reach the applicant.
Yes, if the design expects it. We would keep stages and document lists as configuration that authorised staff can update, with every change recorded, instead of hard-coding a process that may be revised.
Yes. Universities, cooperatives, trade associations and grant-making foundations run similar application and review flows. Our page on customer portals covers the general pattern.
Tell us what the application involves and the rules around the project, and we will say honestly whether we are a fit.