Implemented in the prototype
Workflow transitions, permission checks, validation, audit entries, task queues, search, and reporting used functioning application logic.
Document Management
System case study.
A working prototype for document digitisation
A document-digitisation prototype that let stakeholders explore scanning, quality control, permissions, and approvals before the production system was built.
12Workflow stages
10User roles
6Exception & rework states
Agree on the process
before building the system.
A records-digitisation programme needed its scanning, quality-control, and approval processes agreed before development began. Business rules were spread across a requirements spreadsheet and a workflow diagram.
The challenge was to make those rules tangible: what each role could see, which actions were permitted, when a document had to be held, and how exceptions should return through the process.
A prototype people
could actually use.
Dhruv built a functioning browser prototype in HTML, CSS, and JavaScript. Every screen used shared application state, so an action performed by one role appeared in the next role’s queue.
Stakeholders could sign in as different roles, move a document through the complete workflow, and try the edge cases. Their feedback became specific because they could experience the business rules in action.
From requirements to behavior
Each business rule was traced to the code that implemented it and a step that demonstrated it working.
One guarded path.
Clear routes for rework.
Documents moved through twelve workflow stages, with six additional exception and rework states. A guarded state machine controlled every transition: the role allowed to act, the prerequisites, and the business rule that could block the move.
- CAPTUREIntake & scanning
Receive files, select an available scanner, and capture pages.
- PREPAREProcessing & quality
AI-processing stage, QC review, final master, and compression.
- REVIEWReview & approval
Supervisor, manager, and department review and approval.
- SUBMITeGov submission
The manager submits the precise version approved by the department.
The four phases above group the twelve stages. Exception and rework routes preserve the document’s history.
Disabled actions explained why they were unavailable in the language of the business rule. Task queues, service-level deadlines, search, and reporting followed the same application logic.
Role-based permissions
and department access.
The prototype supported ten roles, from Super Admin to Scanning Operator, including a read-only Auditor. Access checks governed actions, data scope, and the file versions a user could open.
| Layer | What it controls |
|---|---|
| Actions | The workflow transitions and operations permitted for each role. |
| Data scope | Access across the organisation, selected departments, or a user’s own files. |
| File versions | Which raw, master, or compressed document versions a user may open. |
Opening a route that a role could not use displayed an access-denied page and created an audit entry. The prototype checked access throughout the experience.
Administration that reflected the organisation
The Super Admin console managed administrators, a three-level department hierarchy, a central permission matrix, and custom roles. Administrators could be scoped to one department tree, several departments, or the whole organisation, with specific cross-department rights where needed.
Activity reports supported trends and drill-down by administrator, department, and manager.
Scanning and document
quality control.
- Device-aware scanning. A scan could start only when a scanner was available. Supported paper sizes came from the selected device, and unrecognised sizes were held for operator review.
- Recoverable capture. Captured pages survived a failed save, so the operator could recover the work.
- Page-level quality control. QC staff reviewed six quality parameters on a page grid, requested rescans for individual pages, and held files when the page count did not match.
- Connected review. Reviewers could compare the raw scan, final master, and QC report side by side. Selecting an issue moved both document views to the relevant page.
Approval tied to
the exact document version.
Department approval pinned the precise compressed file. Only the Manager could perform the eGov-submission step, and only with that approved copy. Documents returned for rework retained their history.
The audit trail was append-only, with no edit or delete action in the prototype interface. Permission changes recorded their before-and-after values, supporting review of what changed and how the workflow was used.
A decision stays attached to its evidence
The approval chain connected the reviewer’s decision to a specific file version, with history carried forward through rework.
Business-rule validation
across roles and routes.
Four headless Node.js harnesses ran against the same modules used by the browser. Validation covered the requirements, screen rendering, and route behavior across roles.
640Business-rule assertions
414Screen renders
941Route renders across roles
The requirements-to-code mapping gave stakeholders and developers a concrete way to review the intended behavior.
A browser prototype
with real application logic.
HTML5CSS3JavaScript ES moduleslocalStorageNode.js test harnessesNo frameworkNo build step
The prototype comprised approximately 32,000 lines of HTML, CSS, and JavaScript and ran by serving the project folder. It used browser-local storage and had no backend.
Simulated integrations
Scanner hardware, AI results, email, and the eGov upload were simulated deterministically and labeled in the interface.
The permission model and integration simulations describe the browser prototype. Production authentication and external services require their own server-side implementation.
A shared reference
for the production DMS.
The prototype was presented to stakeholders and the team, then refined through their feedback. It was signed off as the final reference, and the production DMS was subsequently built on it.
This founder project demonstrates the connection between business analysis and engineering: clarify the rules, express them as working behavior, and give everyone involved a shared basis for implementation.
Read the original founder case studyYOUR WORKFLOW, MADE PRACTICALHave a process
Discuss your projectHave a process
that needs better software?
Let’s map the requirements, test the important scenarios, and shape the right product.