Building a Garment Cutting Floor Gatekeeper: Why Backend Validation Matters More Than UI Restrictions

When building business applications, it's easy to spend most of the time thinking about dashboards, charts, and user interfaces.

But in real-world manufacturing environments, some of the most important problems happen outside the screen.

Recently, I worked on a project called ApparelFlow ERP, focusing on a specific operational area in garment manufacturing: the Cutting Operations and Gatekeeper process.

I wanted to explore how software engineering could help prevent operational mistakes before they affect the next stage of production.

Here's what I built and some of the engineering decisions behind it.

The Problem: What Happens When a Bundle Has Missing Pieces?

In garment manufacturing, the cutting department prepares fabric pieces according to production requirements. These pieces are grouped into bundles and transferred to the sewing department.

But what happens if a bundle reaches the sewing floor with missing components?

It can interrupt production, waste resources, and affect delivery schedules.

The idea behind the Gatekeeper Terminal was simple:

A batch should not move to the next production stage until it passes the required verification checks.

Rather than attempting to build a complete ERP suite with many unrelated features, I decided to focus on this particular workflow.

1. Backend Validation: Never Trust the Frontend

One of the main decisions I made was to treat the backend as the actual security boundary.

Disabling an approval button when a batch has missing pieces might look like a reasonable solution. However, frontend restrictions alone cannot protect business operations.

A user can modify frontend behavior or send requests directly to an API endpoint.

So, I implemented the validation rules on the backend.

Before approving a batch, the server checks whether the required component quantities are available.

If even one required component is missing,

the approval request is rejected with:

422 – Unprocessable Entity

This ensures that the business rule is enforced regardless of what happens on the frontend.

2. Role-Based Access Control (RBAC)

Not every employee should have permission to perform every operation.

For this workflow, I separated responsibilities between:

• Cutting Supervisors: Responsible for creating and managing cutting orders.
• Cutting Verifiers: Authorized to verify and approve completed batches.

The backend checks user permissions before allowing an approval operation.

If an unauthorized user attempts to approve a batch, the server responds with:

403 – Forbidden

This keeps the approval process separate from order creation and helps maintain clear responsibilities.

3. Audit Logging and Traceability

In manufacturing systems, knowing the current status of a batch isn't always enough.

It's also important to understand what happened before it reached that status.

I implemented audit logging to capture important verification information, including:

• Verifier identity.
• Verified component quantities.
• Fabric wastage information.
• Verification activities.

This provides a history of important operations and makes it easier to trace how a batch was processed.

4. Testing the Business Rules

Another important part of this project was testing the logic behind the workflow.

I used Jest to write automated tests covering important business rules, authorization checks, and edge cases.

For example:

• What happens when a batch has missing components?
• Can a user without verifier permissions approve a batch?
• Does the system reject invalid approval attempts?

I wanted to make sure that these rules were not just working in the expected scenario but also behaving correctly when something went wrong.

Technology Stack

The project was developed using:

• Next.js (App Router) – Application framework.
• TypeScript – Type safety.
• PostgreSQL – Relational database.
• Supabase – Database and backend services.
• Tailwind CSS – UI styling.
• Jest – Automated testing.

What I Learned

One of the biggest takeaways from this project was that building business software requires more than implementing features.

Understanding the workflow, identifying possible failure points, enforcing business rules, and controlling access are equally important.

I also realized that sometimes building one focused module properly can be more valuable than creating a large application filled with features that don't solve a specific problem well.

ApparelFlow ERP was a good opportunity to explore these engineering concepts in a practical manufacturing scenario.

Try It Yourself

GitHub Repository:
https://github.com/NimeshDilhara96/apparel-flow-erp

I'd love to hear from other developers:

How do you approach enforcing business rules that must never be bypassed, especially in systems where one incorrect approval can affect an entire operational workflow?

Thanks for reading!