01 / Overview
One application, one relational source
The platform brings business records, time, scheduling, administration, and reporting into one application instead of recreating the same information across separate files.
It's built around the work people actually do — responsive screens wired to an API and relational data, not isolated forms — so an interface, rule, or data change is one delivery decision.
system coverage
- InterfaceResponsive React workflows
- ApplicationNode.js and Express API
- DataConnected SQL Server records
- DeliveryReleases, maintenance, and support
02 / What changed
From disconnected tools to shared work
The replacement needed to support concurrent use without losing control of data or permissions.
Before
Disconnected tools
- Legacy systemNot shared
- SpreadsheetsRecords maintained separately
- Paper stepsManual hand-offs
Business platform
Connected application
- Shared recordsOne relational source
- Web accessConcurrent use across teams
- PermissionsRole-based modules and actions
03 / System model
Access, application logic, and data work together.
Authenticated requests pass through role checks before the application reads or changes shared records.
Requests
The interface reflects the user’s role.
React screens expose the modules and actions relevant to the authenticated user.
Application logic
The API validates access and input.
Node.js and Express apply business rules before reading or writing data.
Relational data
Connected records are maintained once.
SQL Server relationships support the application and its reporting needs.
Maintenance
Delivery continues after release.
I reproduce issues with users, trace the affected logic and data, deploy the fix, and verify the result.
04 / Responsibility
Primary development across the full stack
Requirements come directly from internal users. My work covers interface and API features, relational design, permissions, releases, maintenance, and support.
I clarify the user’s goal, trace the records and roles involved, implement the smallest coherent change across the stack, and review the result with the people who requested it. That feedback loop is especially important when a screen change affects existing data or access rules.
- Interface
- React and Material UI
- API
- Node.js and Express
- Access
- Authentication and roles
- Data
- SQL Server relationships
- Delivery
- Release preparation
- Support
- Defects and user feedback
05 / Architecture and access
Role checks stay beside application logic
decision 01
Authorize modules and actions by authenticated role
Different responsibilities need different access, so I keep authorization on the server: a user's role decides which modules and actions they can reach, and the React interface only mirrors what the API already enforces. The cost is that every new feature has to carry its own permission rule.
06 / Quality and maintenance
A change is not finished at deployment
Input validation, relevant Jest regression checks, manual verification, and direct user feedback protect important behavior. Test counts and coverage are not published.
For defects, I first reproduce the same conditions reported by the user. I then check whether the cause sits in interface state, API logic, permission handling, or stored data before changing code.
maintenance loop
- 01ReproduceUnderstand the reported issue
- 02ChangeUpdate logic and tests
- 03ReleaseDeploy and verify
- 04SupportConfirm the result with users
07 / Outcome
Shared software with continuing ownership
result
The platform replaced disconnected legacy tools and brought previously separate records into one application.
lesson
Production work requires careful data changes, clear permissions, release discipline, and support after delivery.