My first professional engineering system
My final-year internship at Tribhuvan University placed me at SimplySoft Technology in Kathmandu. I joined as an Angular intern, worked with two senior developers, and met with my supervisor daily during a three-month placement.
The production Revenue Platform already existed. It supported tax-payment management for Nepal’s Financial Comptroller General Office. My assignment was not to build or replace that production system. I built an internal clone from scratch where the team could explore interface changes, evaluate technologies, and investigate vulnerabilities away from real transactions.
The result was a documented proof of concept using dummy payment records, not a government deployment.
Learning the stack through a real workflow
Angular was new to me. The first four weeks focused on components, data binding, dependency injection, services, routing, and forms. From week five onward, that learning moved into the Revenue Platform workflow.
The review cycle was consistent: build a version, demonstrate it, receive feedback on reuse or structure, and revise it. By the end of the internship, the clone connected an Angular front end to a MongoDB database and a small Node.js REST API.
Designing the receipt flow
I wireframed the home page, receipt-entry flow, and analysis dashboard before implementation. The receipt form needed to capture PAN details, payment information, fiscal year, and government-office context without inviting invalid combinations.
Cascading administrative choices narrowed the available district and office values as the user progressed. After submission, the system stored the voucher and generated a separate receipt preview so the entered values could be reviewed and printed.
Receipt entry · constrained selection
step 1
Pick province
Federal Government or one of the seven provinces
step 2
Pick district
From a searchable table for that province
step 3
Pick office
Dropdown scoped to the chosen district
step 4
Save, then print the receipt
The form saves the record, and its preview page prints the receipt
The prototype also included paid and unpaid voucher views, payment handling, and PAN search. Together, those screens represented the core path from data entry to a record that could be found and reviewed later.
Shaping the reporting view
The analysis dashboard began with questions rather than charts: how much was paid versus outstanding, which banks handled the most volume, and how collections changed across fiscal years.
I built an analysis response around those views, then used Chart.js for the reporting interface. Keeping a distinct reporting route made the contract between the API and the charts easier to understand than asking every chart to interpret the full payment-record shape.
Architecture · as consumed by the client
MongoDB
Receipts + location hierarchy
PAN, amount, bank, status, fiscal year · province → district → office, nested
endpoints called
/location · /getAll · /status/paid · /status/unpaid · /post · /analysis
The client's PAN search filters /getAll in the browser, rather than calling the /byPan route from my report
receipt form
Cascading selection → save → printable preview
ngx-print renders a printable receipt for saved records
Chart.js
Analysis dashboard
Line (per bank) · bar (paid vs unpaid) · doughnut (by bank) · pie (by fiscal year, BS 2073–79)
What the report proves
The internship report documents the implemented screens, MongoDB records, API requests, and focused unit tests for reading payment status, searching by PAN, and creating receipts. It also records the daily supervision and weekly progression from framework study to database-backed analysis.
The strongest outcome was not a production metric. It was completing an unfamiliar full-stack workflow under professional review and learning that a working first version is the beginning of the engineering conversation, not the end.
What it does not prove
The same report states the limitations plainly. The backend had no meaningful security mechanism, the REST API was basic, and richer analysis, trend prediction, and a more dynamic architecture remained future work.
The clone was not deployed for real payments and was not evaluated with district staff or taxpayers. It therefore demonstrates a functional internal prototype and my growth as an intern, not production security, reliability, or public-sector usability.
