Trabaja - Operations, Scheduling & Billing Platform by Adnan AslamTrabaja - Operations, Scheduling & Billing Platform by Adnan Aslam

Trabaja - Operations, Scheduling & Billing Platform

Adnan Aslam

Adnan Aslam

Trabaja — A Production Operations Platform for Baja Carports

Trabaja is a private business operations platform built for Baja Carports, a US-based construction company.
The platform brings job tracking, project ownership, billing schedules, documents, operational notes, scheduling, and reporting into one structured system. It supports the people responsible for moving a job from its initial contracting stage through active planning, construction, billing, and completion.
I worked across the full application, including frontend workflows, backend APIs, database-backed business logic, access behavior, exports, production fixes, and ongoing feature development.
Portfolio visualization based on the production platform. All displayed names, projects, dates, and financial values are synthetic.

The challenge

A construction job is not represented by a single status or form.
Each project accumulates interconnected operational information:
Customer and job details
Contract and cost information
Project manager assignments
Pre-lien and compliance status
Proposal and agreement conditions
Billing schedules
Material and labor billing
Change orders
Documents and custom folders
Construction scheduling
Notes, updates, and follow-up dates
Regional, state, and project-status reporting
Different employees also need different views of the same operation. Administrators require broad visibility, while project managers and project manager assistants need access to the jobs assigned to them. Schedulers need operational information without unrestricted control over unrelated financial fields.
The challenge was therefore not simply to build forms. It was to create a reliable operational model in which each part of a job remained connected, editable, reportable, and usable by the correct people.

What I built

I developed and expanded Trabaja as a centralized system for managing the company's active job pipeline.

Project dashboard

The dashboard organizes jobs into operational stages including:
Contracting
Backlog
JIP
On Hold
Completed
Canceled
Repairs
Users can filter operational data by project manager, state, region, and other job attributes. Important notes and aging dates are surfaced directly in the table so teams can identify projects requiring attention without opening every record.
The dashboard also supports dedicated exports for job information, schedules, and notes.
Role-aware project dashboard organizing jobs by operational stage, ownership, geography, notes, and completion status.
Role-aware project dashboard organizing jobs by operational stage, ownership, geography, notes, and completion status.
Role-aware project dashboard organizing jobs by operational stage, ownership, geography, notes, and completion status.

Comprehensive job workspace

Each job has a detailed workspace containing:
Job and proposal information
Customer, city, state, and region
As-bid and as-built specifications
Contract amount and cost estimate
Estimated and confirmed dates
Project manager and assistant assignments
Sales and customer contacts
Pre-lien tracking
Agreement and prevailing-wage information
Operational notes and lien-risk indicators
Billing schedules
Change orders
Documents
Construction scheduling
Scheduling notes
This gives the team one structured record for understanding both the commercial and operational state of a project.
Centralized job information covering project specifications, customer details, assignments, estimates, dates, and operational status.
Centralized job information covering project specifications, customer details, assignments, estimates, dates, and operational status.
Centralized job information covering project specifications, customer details, assignments, estimates, dates, and operational status.
Connected billing workflows for contract, material, labor, change orders, instructions, and invoice status.
Connected billing workflows for contract, material, labor, change orders, instructions, and invoice status.
Connected billing workflows for contract, material, labor, change orders, instructions, and invoice status.
Document, scheduling, notes, and job-compliance management within the same production record.
Document, scheduling, notes, and job-compliance management within the same production record.
Document, scheduling, notes, and job-compliance management within the same production record.

Billing and financial workflows

Trabaja supports multiple connected billing areas:
Contract billing schedules
Material billing schedules
Labor billing schedules
Change-order billing
Retention-related calculations
Billing instructions
Billing terms, platform, and billing day
Invoice and lock states
The implementation manages contract, labor, material, and change-order rows as related business data rather than treating billing as a simple free-form note.
Billing operations dashboard showing contract, material, labor, and change-order billing workflows.
Billing operations dashboard showing contract, material, labor, and change-order billing workflows.

Document management

Documents are organized into operational categories such as accounting, change orders, correspondence, engineering and site information, field purchase orders, permits, safety, timesheets, vendor releases, and other job-specific groups.
The system also supports nested or custom document folders where the fixed categories are not sufficient. The implementation maintains these document collections as structured job data.

Roles and assignment-based workflows

Trabaja supports different operational roles, including project managers and project manager assistants.
PM and PMA records are retrieved and managed independently, allowing assistants to be assigned to jobs alongside the primary project manager. The platform also retrieves user information for note attribution and related operational activity.
This required more than hiding buttons. Job visibility, editable fields, contact details, dashboard filtering, and workflow behavior had to remain consistent with the user's role and assignment.
User role management interface for managing operational roles and permissions.
User role management interface for managing operational roles and permissions.

Operational exports

I developed and refined Excel-based exports for real business use, including:
Job and project data
Combined new-construction and repair schedules
Operational notes
Delivery and worker scheduling information
Consolidated one-tab exports
Correct column formatting and ordering
Business-friendly filenames and date handling
The goal was not merely to download database rows. Each export needed to match how the company actually reviews, shares, and acts on operational data.

Crew and job scheduling

Crew and job scheduling interface for coordinating delivery, installation, and worker assignments.
Crew and job scheduling interface for coordinating delivery, installation, and worker assignments.

Collections and reporting

Collections and reporting dashboard for tracking billing status and payment activity.
Collections and reporting dashboard for tracking billing status and payment activity.

My process

1. Understand the real workflow

I began with the company's existing terminology, job stages, forms, and operational responsibilities.
Rather than replacing the workflow with a generic project-management model, I mapped the software to the way Baja Carports already operated:
Contracting → Backlog → JIP → active scheduling and billing → completion
This reduced the learning burden for internal users and kept the product aligned with established business processes.

2. Break the system into operational domains

The application contains a large amount of connected information. I separated that complexity into clear domains:
Jobs
Users and assignments
Billing
Scheduling
Notes
Documents
Change orders
Exports
This made it possible to improve one business area without destabilizing unrelated workflows.

3. Deliver production-safe improvements

Trabaja was already a working production system, so a high-risk rewrite would have been inappropriate.
I developed it incrementally:
Trace the existing data path.
Identify the business rule behind the requested change.
Update the relevant frontend, API, and database mappings.
Preserve compatibility with existing records.
Validate the workflow against related roles and screens.
Check exports and downstream calculations for regressions.
This was especially important for billing, job assignments, scheduling, and exports, where a seemingly small field change could affect several parts of the system.

4. Handle edge cases explicitly

Operational software accumulates exceptions that do not appear in a simple prototype.
Examples included:
Unassigned PM or PMA records
Duplicate user codes
Missing or partially completed job data
Different behavior for repairs and new construction
Locked billing rows
Positive and negative change orders
Dates that had to remain consistent across exports
Multi-day scheduling interactions
Notes written by different operational roles
Documents outside the standard folder taxonomy
I treated these as core product behavior rather than optional polish.

5. Optimize around actual usage

The visual interface was intentionally practical rather than marketing-oriented. The company prioritized data density, operational visibility, and speed over decorative UI.
My work therefore focused on:
Making large job records manageable
Reducing repeated data entry
Keeping filters and exports predictable
Improving multi-selection and scheduling behavior
Preserving familiar workflows
Preventing changes from breaking production data

Architecture decisions

Full-stack Next.js application

Trabaja uses Next.js as the primary application layer.
This provides one codebase for:
User interfaces
Server-side application logic
API routes
Authentication-aware workflows
Export generation
Database-backed operations
For an internal business platform, this kept deployment and ongoing maintenance simpler than introducing unnecessary independent services.

Relational database as the source of truth

The application uses MariaDB/MySQL because the core domain is strongly relational.
Jobs connect to:
Customers
PM and PMA users
Notes
Contacts
Billing rows
Change orders
Documents
Schedule information
A relational model is a natural fit for maintaining these connections and supporting deterministic reporting.

API-backed data access

The frontend does not treat job data as an isolated page-level object. It retrieves related information through focused application endpoints, including job identifiers, PM/PMA records, note-author users, change orders, and other job dependencies.
This created a practical boundary between interface state and persistent business data.

Explicit database-to-UI mapping

Legacy business databases often contain naming and formatting conventions that should not leak throughout the frontend.
I used mapping and normalization layers to translate database records into consistent application models. This was particularly important for:
PM and PMA assignments
Dates
Currency values
Boolean and status fields
Contact information
Billing rows
Existing incomplete records

Role-aware application behavior

The system distinguishes between users who:
Manage all jobs
Own assigned projects
Assist project managers
Work with schedules
Maintain administrative data
This affects dashboard visibility, field editability, assignments, and available actions.

Deterministic exports

Exports were implemented as product features, not incidental table downloads.
Formatting, column order, combined schedule behavior, date handling, job-number alignment, file naming, and sheet structure were controlled deliberately so exported files remained usable outside the application.

Incremental modernization

I chose not to rewrite the entire product simply to modernize its appearance.
The higher-value architecture decision was to preserve the company's operational knowledge while gradually improving:
Data consistency
Component structure
API behavior
Role handling
Performance
Export quality
Maintainability
This lowered deployment risk and allowed the platform to continue supporting daily work while it evolved.

Results

Trabaja now provides a connected operational workspace in which Baja Carports can:
Track jobs across their real business lifecycle
Give PMs and PMAs assignment-relevant visibility
Maintain job, customer, billing, schedule, and document data together
Track important notes and follow-up dates
Manage multiple forms of billing within the job record
Generate consistent operational exports
Organize documents around construction workflows
Extend the platform as new operational requirements emerge
The most important result is not a cosmetic redesign.
It is that complex company-specific processes have been converted into repeatable software workflows that can be maintained, expanded, and used as part of daily operations.
Results summary
Results summary

My role

I worked as the full-stack engineer responsible for understanding operational requirements and implementing them across the user interface, backend APIs, database mappings, role behavior, business calculations, exports, and production workflows. I also maintained and extended the existing system incrementally, protecting live operations while improving its functionality and maintainability.

Technology

Next.js
React
TypeScript
Node.js
MariaDB / MySQL
REST-style API routes
Excel export generation
Role-aware application state
Server-side business logic
Like this project

Posted Jul 14, 2026

Built and maintained an operations platform for managing scheduling, billing, notes, exports, and role-based workflows across day-to-day business operations.