In law enforcement, every administrative violation case must follow the right legal basis, signing authority, and deadline. A mistake can affect citizens’ rights and expose the authority to legal and reputational risk.
Before this project, that risk was real for our client, a national police agency. Officers across the country were writing violation reports by hand, filling out decisions in Word, and passing paper files through multiple levels for signatures, for over a dozen different types of legal measures, each with its own rules.
Synodus was brought in to help transform this process into one connected digital system for nationwide use.
Project goal: Build a centralized digital platform for administrative violation case management, standardize the workflow and legal documents, and give leadership real-time operational visibility.
About our client
Our client is a national police authority responsible for administrative order and public safety. For this project, they led the business scope, workflows, and approved forms for a component of the national administrative violation database.
The new system had to serve police units across the country, while also connecting local government bodies and courts that share authority over these cases.
It also had to connect to all 3 existing platforms: one for case numbering and shared reference data, one for user identity and role-based permissions, and one for digital signatures.
| Industry | Government / Public Sector |
| Country | Vietnam |
| Service | Software Delivery (Website development, Data solutions) |
Business context & challenges
Before we joined, the process was almost entirely paper-based. An officer wrote a report, passed it through 3-4 levels for signatures, and stored the final file locally.
Each type of measure including detaining a person, searching a vehicle, sending someone to a rehabilitation center, and more, had its own forms and legal rules, spread across several government decrees.
This created 6 major problems:
| Problems | What it means for our client |
|---|---|
| Slow and hard to track | Once a file entered approval, no one could see where it was or who was holding it up. |
| Fragmented data | Local units kept separate records, making cross-region violation history difficult to check. |
| High risk of form errors | 48 forms across 13 modules had to follow different legal rules and deadlines. |
| Duplicate case numbers | Local logbooks could not guarantee unique numbering nationwide. |
| No live data for leadership | Leadership relied on manually compiled reports to understand case volume and progress. |
| Limited cross-agency coordination | Police, local government, and courts did not work on one shared platform. |
If left unresolved, these gaps would make it difficult to scale administrative violation management nationwide, increase the risk of legal and procedural errors, and limit progress toward a national database for administrative violations.
The project therefore needed to move the core workflow from paper to a controlled digital environment, while improving traceability, data consistency, and operational visibility at national scale.
Project workflow
To build the system, the project ran for about 5 straight months, with no buffer sprints and fixed release deadlines. It moved through 7 phases:
| Phase | Focus | Timeframe |
|---|---|---|
| 1. Business research | Legal research, field visits, and workflow mapping | April – September 2026 |
| 2. SRS + Prototype | Defined requirements and validated key workflows | April – June 2026 |
| 3. Technical foundation | Core services, database, workflow, signing, and document generation | April – May 2026 |
| 4. Feature development | Built shared police functions, followed by external agency modules | May – September 2026 |
| 5. Testing & release | Fixed release milestones and functional validation | July – September 2026 |
| 6. Security review | Penetration testing and code scanning | By release cycle |
| 7. Handover | Delivered the backend, frontend, SRS/prototype, and test cases | September 15, 2026 |
Our solution
Instead of building 13 separate modules as 13 separate mini-apps, we broke the business logic into 4 shared mechanisms that every module could reuse:
- A workflow engine to manage each case from report to decision and signing.
- Template-based forms to generate all 48 forms from approved legal templates.
- Role-based access and signing to control who can view, approve, and sign each document.
- Centralized case numbering to prevent duplicate case numbers across regions.
Why this approach? Because the legal and administrative rules were guaranteed to change, and they did, mid-project, when the country shifted to a new local government model and redefined which agencies had which authority. With shared mechanisms, the system did not need to be rebuilt. We could update the rules and configurations instead.
This approach also went straight at the problems our client faced on paper: approvals no one could track, wrong legal citations, unclear signing authority, and duplicate case numbers.
The platform ran on .NET, Oracle, React, and a dedicated workflow engine, supported by CI/CD for regular releases.
How the team got it done
First, we built the prototype before the code. The legal rules had too many edge cases to trust a written spec alone. So our BAs built a working prototype next to the SRS, and it became the “spec”.
Backend, frontend, and QC all built and tested against it, and anything that behaved differently was a bug. This let our client confirm the right behavior before we spent time coding it.
Next, we set the technical ground rules. The backend was split into separate services and built around Clean Architecture, CQRS, and domain-driven design. Automated architecture tests made sure business logic stayed independent from the database and framework. We also required a short design document before any new feature could be merged. With hundreds of handlers and many developers working in parallel, these rules kept the codebase consistent.
Then, we made AI an official part of the development workflow. About two months in, we introduced Claude Code into the workflow on all three repositories. Each role (BA, Dev, QC) got its own AI agents and skills. Each workspace could only reach the repository that role needed, and a guard blocked writes to the wrong one. AI supported the engineering process, not the product itself. The delivered system did not use AI for citizen-facing features or administrative decision-making.
Our biggest challenge was a large, cross-unit team changing the same database at the same time. The main risk was changes colliding, especially in database migrations (405 by the end of the project), where a manual merge had already broken a schema before. So before the team grew further, we changed the rules: one merge branch, no manual migration merges, and 10 automated checks for every merge request.
| What the gate checks |
| 1. Build and unit tests |
| 2. Merge conflicts |
| 3. Duplicate cherry-picked changes |
| 4. Migrations that write to share reference data |
| 5. Baseline of the main branch |
| 6. Reverted or deleted existing files |
| 7. Commits that exits only on the dev branch |
| 8. Database changes (wait for the owner’s approval) |
| 9. Design document for every new feature |
| 10. AI review verdict: pass or fail |
Then we worked around what we couldn’t control. The 3 partner platforms had their own release schedules, and their API contracts changed during development. We documented each contract and built mock services so backend and frontend could keep moving. Security testing followed the same planned approach, with dedicated penetration testing and code scanning built into the release schedule.
Finally, we handed over the full package. The backend, frontend, prototype/SRS, and test cases were delivered as 4 structured packages, supported by handover records, a checklist, and an overall plan.
The outcomes
The delivered platform moves core paper-based violation workflows into one connected digital system. Here’s what changed:
| Before | After |
|---|---|
| Paper signing, Word drafting, and hand-kept numbering | Digital signing, decisions generated from legal templates, and one central numbering system |
| Files with no clear location, and reports compiled by hand | Every file tracked with a full history, and a dashboard for leadership |
| Files stalled when a leader was away | Delegation of authority keeps files moving within legal deadlines |
| Only police units worked on these cases | The platform extends the workflow to local government bodies and courts that share authority over administrative violations. |
The scale of the delivery is reflected in the numbers:
- 48 forms across 13 modules
- 100% of the common functions delivered, and 45% of the functions for outside agencies (119 functions across 21 modules), with the rest still in progress
- About 19,800 commits in 5 months
- Four deliverables handed over in full: backend, frontend, prototype/SRS, and test cases
Together, these controls are designed to reduce the risk of legal and procedural errors that can affect citizens’ rights and the authority’s reputation, while giving the client a foundation for the continued development of a national administrative violation database.
Our road ahead
The September handover marked the next stage of the project, not the end of the roadmap. The remaining 55% of external-agency functions are planned for continued development, alongside broader test coverage and work on identified technical debt.
Looking ahead, this system is part of a larger digital platform. Together with its sister system for handling violation penalties, it will support administrative violation handling across police units and other authorized agencies nationwide.
If you’re dealing with complex workflows or strict regulations, we can help.
