FORMA: Building a Full-Stack Business Operations Management System

Introduction

FORMA is a full-stack Business Operations Management System that I developed as part of my MCA coursework. It brings customer records, products, inventory, sales orders, payments, and reports into a single application.

I wanted this project to go beyond creating forms and performing basic CRUD operations. In a business application, changing one record can affect several others. Confirming an order, for example, may require checking stock, updating inventory, recording the order changes, and maintaining an audit trail.

While developing FORMA, I worked on connecting these operations while keeping the underlying data consistent and the application secure.

This article covers the system's architecture, implementation decisions, business workflows, testing approach, and areas that still need improvement.

Figure 1: FORMA Business Overview Dashboard

1. Understanding the Problem

Business operations involve several connected processes. A customer places a sales order for products or services. Sales of stocked products affect inventory, while recorded payments reduce the outstanding balance. These processes, among others, require accurate records and consistent data management.

When these activities are maintained separately, tracking a transaction becomes more difficult. Information may need to be updated in several places, increasing the possibility of inconsistencies.

FORMA was designed to manage these operations within one system.

The application supports three user roles: Administrator, Manager, and Staff. Its main modules include customer management, a product and service catalog, inventory adjustments, sales orders, manual payment recording, operational reports, and audit history.

Figure 2: Customer Management in FORMA

Beyond implementing these features, I needed to account for situations such as insufficient inventory, duplicate requests, invalid input, and conflicting updates.

These are important because an application should not only work when everything goes as expected. It also needs to handle errors without leaving business records in an inconsistent state.

2. Planning the Application

I began by setting up the Node.js backend and establishing the MongoDB connection. From there, the work progressed into database models, API routes, business rules, frontend integration, and testing.

I divided development into manageable stages:

• Defining functional requirements and user permissions

• Planning the backend structure and database models

• Implementing APIs and business rules

• Connecting the frontend to the backend

• Adding authentication, authorization, and request validation

• Testing business workflows and error scenarios

• Reviewing performance and resource usage

• Preparing documentation and deployment requirements

Breaking the application into smaller responsibilities made it easier to work on individual modules while keeping their dependencies in mind.

I also avoided introducing architectural components without a clear need. FORMA is a single-business application, so a modular backend was a more appropriate starting point than a distributed system with multiple services.

The priority was to make the application understandable, maintainable, and reliable within its intended scope.

3. Technology Stack

FORMA uses JavaScript across the frontend and backend, with MongoDB for data storage.

For the frontend, I used HTML, CSS, and browser JavaScript modules rather than adding a framework such as React.

This kept the interface relatively lightweight and allowed the project to focus on its business workflows and backend behavior.

The frontend and backend are served from the same origin, which also simplifies local setup and session handling.

These choices were based on the application's requirements rather than the number of technologies I could include.

4. Designing the Architecture

FORMA follows a modular application architecture, with the browser communicating with an Express backend that handles business logic and database operations.

Figure 3: High-level architecture of FORMA, showing the browser interface, Express backend, business modules, and MongoDB database.

When the browser sends an HTTP request, the backend processes it through the appropriate middleware and route handlers.

Protected operations require session verification, authorization, CSRF protection, and request validation before the requested business action can proceed.

The backend organizes functionality around areas such as authentication, customers, products, orders, payments, reporting, and audit history.

MongoDB stores the application records, while Mongoose provides the models used to interact with those records.

One of the main considerations was keeping responsibilities separated without creating unnecessary abstraction layers. A modular structure makes it easier to locate business logic, investigate errors, and modify individual features.

5. Database Design and Data Integrity

Database consistency is particularly important in FORMA because several business operations affect more than one collection.

The application maintains records for users, sessions, customers, products, orders, stock movements, payments, audit events, and operation tracking.

Consider what happens when a sales order is confirmed.

The system needs to verify the customer and products, check stock availability, update inventory, record stock movements, change the order status, and maintain an audit record.

These changes belong to the same business operation. If only some of them succeed, the stored data may no longer represent what actually happened.

FORMA uses MongoDB transactions for critical operations involving multiple records.

A database transaction groups related changes into a single unit of work. If an operation fails before the transaction is committed, the transaction can be rolled back, preventing partial updates.

For order confirmation, this helps prevent a situation where the order is marked as confirmed but the required inventory changes are missing.

Implementation Example: Transactional Order Confirmation

The order-confirmation workflow uses a shared mutate() wrapper that manages MongoDB transactions.

The following excerpt comes from server/routes/orders.js:

if (status === 'confirmed') {
  const customer = await Customer.findOne({
    _id: order.customer,
    archived: false
  }).session(session);

  if (!customer) fail(409, 'Customer is archived');

  await Customer.updateOne(
    { _id: customer._id },
    { $inc: { version: 1 } },
    { session }
  );
}

This is a small part of the complete order-confirmation implementation.

First, the code checks whether the customer associated with the order is still active. If the customer has been archived, the operation fails.

It then updates the customer's version within the transaction. This participates in the application's approach to handling concurrent modifications.

The remaining confirmation logic performs conditional inventory updates, creates stock movement records, updates the order, and records the audit event using the same database session.

The transaction is managed through session.withTransaction() in server/core.js.

Keeping these changes within a transaction reduces the risk of partial updates when an operation encounters an error.

Source: server/routes/orders.js and server/core.js.

6. Handling Duplicate Requests and Concurrent Updates

A request may reach the backend more than once.

This can happen when someone clicks a button repeatedly, retries an operation after a network problem, or submits the same action because the previous response was unclear.

For operations that change business records, repeating a request can have unintended consequences.

FORMA uses idempotency keys for supported operations. These keys help the backend recognize repeated submissions and avoid performing the same operation unintentionally.

Concurrency introduces another challenge.

Suppose two users open the same customer record. One user saves an update, while the other continues working with the older version.

Without conflict handling, the second update could overwrite the first user's changes.

FORMA uses version checks to identify stale customer updates and reject conflicting edits rather than silently replacing newer data.

These checks help prevent duplicate operations and protect existing data when multiple users interact with the application.

7. Authentication and Security

FORMA uses server-side sessions to manage authentication.

After a user signs in, the application uses a session associated with a protected browser cookie. Passwords are hashed using Argon2 rather than stored as plain text.

The system also implements role-based authorization.

An Administrator, Manager, and Staff member may have different permissions, and those restrictions must be enforced by the backend.

For example, hiding a button from a user does not prevent that user from attempting to call the corresponding API directly.

The server must check whether the authenticated user is authorized to perform the requested action.

Other protections include request validation, origin and CSRF checks, and security middleware.

These measures address different concerns. Authentication identifies the user, authorization controls access, and validation checks whether the submitted data meets the application's requirements.

Security is not handled by one feature. It depends on several controls working together.

8. Implementing the Business Workflows

One of the main goals of FORMA was connecting its modules into complete business workflows.

A typical workflow begins with creating a customer and adding products or services to the catalog.

A user can then record inventory, create a sales order, and manage that order through its supported stages.

Figure 4: Sales Orders in FORMA

Products and services are managed through the catalog, with inventory-related operations available for stocked products.

Figure 5: Products and Services in FORMA

Creating a draft order does not immediately deduct stock.

When the order is confirmed, the backend checks whether the required inventory is available and applies the related changes.

The application also supports manual payment records and order fulfillment.

An important distinction is that FORMA records payments as business transactions. It does not connect to a payment gateway or process money directly.

This keeps the payment functionality within the project's defined scope.

Reporting connects these operations by providing information such as sales summaries, outstanding balances, and inventory data.

The application also supports CSV export.

Figure 6: Operational Reports in FORMA

Building these workflows required considering how a change in one module affects the information displayed in another.

9. Testing and Debugging

I used automated testing to verify both backend behavior and browser-based workflows.

The latest recorded local verification run on October 10, 2026, reported the following results:

• 25 backend tests passed

• 16 Chrome browser tests passed

• No failed or skipped tests in those recorded runs

The backend tests covered areas including authentication, permissions, validation, business workflows, transactions, duplicate requests, concurrency, payment reversals, and session behavior.

Browser tests covered end-to-end workflows, forms, responsive layouts, conflict handling, and session recovery.

These tests used isolated synthetic databases rather than actual business records.

Testing also involved troubleshooting environment-related problems, including browser installation and process-launch permissions.

An environment failure does not necessarily mean the application logic is incorrect. It is important to identify whether a failure comes from the code, the test setup, or the surrounding environment before making changes.

The recorded results provide evidence for the tested behavior in the local environment. They do not establish that every possible scenario or production configuration has been verified.

10. Performance and Efficiency

I also considered how FORMA retrieves and processes data.

The backend uses bounded pagination, database indexes, projected reads, and aggregation queries where appropriate.

These techniques help avoid retrieving unnecessary data and reduce the amount of work performed for certain database operations.

For example, order construction uses a grouped product lookup instead of performing a separate database query for every product.

This reduces unnecessary repeated queries when processing an order containing multiple items.

The project's documentation also identifies areas that may require additional optimization as data volumes increase, including substring searches, deep pagination, and large reporting aggregations.

A local benchmark was recorded using synthetic customer, product, and order data.

However, local measurements should not be treated as proof of production performance.

Performance improvements need to be evaluated alongside correctness, maintainability, and the actual workload the application is expected to handle.

11. Using AI During Development

I used AI-assisted tools during FORMA's development, mainly to support learning, requirements analysis, implementation planning, and debugging.

ChatGPT helped me explore technical concepts and work through development questions.

However, AI-generated suggestions still need to be reviewed. A solution can appear reasonable while overlooking an important business rule, security requirement, or edge case.

I therefore treated AI output as something to evaluate against the project's requirements, implementation, and test results rather than accepting it automatically.

I also worked on making development prompts more specific and limiting changes to the relevant parts of the application.

For me, the value of AI-assisted development is not simply producing code faster. It is using the tools while continuing to develop the ability to understand, test, modify, and explain the resulting implementation.

12. Version Control and Documentation

The FORMA source code is maintained using Git and GitHub.

The repository also includes documentation covering requirements, architecture, API contracts, security assumptions, verification results, and local demonstrations.

I wanted the project to be understandable beyond the application interface.

Documentation provides context for why a feature exists, how a workflow operates, and what assumptions or limitations need to be considered.

It also makes it easier to revisit technical decisions and continue development without relying entirely on memory.

13. Deployment Status and Limitations

FORMA has been developed and tested locally, but its production deployment has not yet been validated.

Several deployment-related areas still require evaluation, including external database connectivity, HTTPS and reverse-proxy configuration, backups, monitoring, production capacity, and broader browser compatibility.

The application also has defined functional boundaries.

It is designed for a single business and does not include payment-gateway processing, a tax engine, or a complete accounting system.

These limitations are important to document.

A locally verified academic application can demonstrate meaningful engineering work without being presented as a production-proven commercial product.

14. Lessons Learned

Working on FORMA helped me understand how much happens behind the interface of a business application.

Initially, it is easy to think of features as separate pages: customers, products, orders, and payments. But once those features are connected, the more difficult questions involve what happens to the data when an operation fails or two actions occur at the same time.

Database transactions, concurrency checks, and idempotency became important because they address those situations.

The project also made backend security more concrete. User permissions need to be enforced where requests are processed, not only through the controls visible in the browser.

Testing was another important part of the work. Checking successful workflows is necessary, but failures, duplicate submissions, conflicting updates, and session behavior also need attention.

I also learned to be more careful about adding complexity. More technologies or abstraction layers do not automatically make an application better. Each decision should have a purpose that can be explained and evaluated.

There is still work to do, particularly around deployment validation and performance under larger workloads. Those are areas I intend to explore as I continue improving FORMA.

Conclusion

FORMA gave me practical experience building a full-stack application where multiple business operations depend on shared data and consistent backend behavior.

The project helped me understand why database transactions, access controls, and proper testing matter when building applications that manage connected business data.

The application is locally verified, with production deployment still pending. I plan to continue refining it and documenting the technical work as the project progresses.

GitHub Repository: https://github.com/varshavarada/forma-business-operations-management-system

Project: FORMA — Business Operations Management System

Category: MCA Mini Project | Full-Stack Web Development

Status: Locally verified; production deployment pending