LessonsfrombuildingMERNERPs

The ERP projects in my portfolio are at different stages. Next Web Business is deployed, actively maintained, and used by one production customer account with more than 50 sub-users. Next Web Campus remains under development with zero production institutions. Next Web Agency is partially developed and deployed, but production customer adoption has not been established.

A JavaScript application can have a separate document service

Business uses a React/Vite frontend, an Express REST API, and MongoDB with Mongoose. I worked on the ERP and personally developed its external PDF generation API using ASP.NET Core and QuestPDF. My responsibilities included authentication, request and response formats, error handling, deployment, and integration into the ERP workflow.

Instead of generating invoice PDFs directly inside the Node.js backend, I implemented a separate document-rendering service. The ERP calls it through an API. This establishes a clear boundary between the primary backend and document generation. I am not attaching an unmeasured scalability or performance benefit to that decision.

Business includes inventory management, GST invoice generation, recurring payments, manual GST/payment reconciliation, and multi-user workflows. GST reconciliation was an important challenge, but the confirmed implementation is manual. Automated matching algorithms and reconciliation formulas are not part of this account.

File organization and access control are different concerns

For Campus, I worked on academic workflows and user-based asset organization. Implemented features include student, attendance, fee and examination management, reporting, role-based access control, multi-institution functionality, and Amazon S3 storage. The platform uses React/Vite, Express, MongoDB/Mongoose, and tenant-scoped operations.

I organized uploaded files using an S3 object-key prefix based on each user’s unique ID. This gives assets a consistent user-based structure. It does not, by itself, prove that one user cannot access another user’s files. Authentication, authorization, signed URLs, and storage policies need separate verification. An organizational convention should not be presented as a security audit.

Extend the product direction without inventing shared internals

Agency extends the broader Next Web ERP ecosystem with CRM, task management, project management, and billing. I worked on its agency management functionality for internal operations and potential external customers. The exact code, models, services, and infrastructure shared with the other ERP products still need verification. I cannot infer shared authentication or a microservices architecture from a shared product direction.

Use status and evidence precisely

One customer account with more than 50 sub-users is not 50 paying customers. A deployed application is not necessarily an adopted product, and implemented features in a development project are not evidence of production use. Keeping these distinctions explicit makes the work easier to evaluate. The same rule applies to private repositories, screenshots, and production URLs: I will only publish material approved for public use.