Aldin Trans Corp Website
Following graduation, I identified an opportunity with Aldin Trans Corp, a local school transportation company operating without any web presence, and approached them directly with a proposal. This led to a contract engagement in which I serve as their primary developer under an ongoing monthly retainer. Working alongside one collaborator, I was responsible for the full development lifecycle including client communication, requirements gathering, system design, implementation, deployment, and continued support.
Through a series of discovery sessions with office administrators, we identified three pain points within their operation:
Inquiry Volume. Without a website, parents and schools relied entirely on phone calls for general inquiries, feedback, and transportation quotes. This created a significant and constant administrative burden on staff.
Inclement Weather Communication. When schools announced weather-related delays, administrators had to manually contact each driver individually with schedule changes. There was no centralized or scalable way to distribute time-sensitive updates.
Deadline Tracking. Administrators had no reliable system to track expiring credentials and certifications across hundreds of drivers and buses including license renewals, vehicle inspections, and software license expirations. This left the company exposed to compliance risk.
Stack: React · Vite · Tailwind CSS · Node.js · Express · MySQL · Netlify · Railway · Gmail API
Each layer of the stack was selected to balance technical fit, maintainability, and cost-effectiveness for a small business client.
Frontend. React was chosen for its component-based architecture and industry prevalence, which supports long-term maintainability. Vite replaced the deprecated Create React App as a more modern and actively maintained build tool. Tailwind CSS enabled rapid, utility-driven styling with consistent design constraints across the application.
Backend. Node.js and Express were selected to maintain a unified JavaScript environment across the full stack, reducing context-switching and enabling consistent patterns between layers. MySQL was chosen over a NoSQL alternative because the application's data is inherently structured and relational. The form submissions are uniform, and the announcement system required a one-to-many schema mapping schools to a shared announcement record.
Deployment. Netlify handles frontend hosting with automatic TLS provisioning via Let's Encrypt. Railway hosts both the backend API and the MySQL database within a single project, providing a straightforward and affordable alternative to provisioning cloud infrastructure independently. We found this appropriate for the scale and budget of this project.
The visual direction prioritized clarity, approachability, and professionalism which is appropriate for a local service business communicating with parents, schools, and drivers. I presented wireframes to stakeholders for feedback before moving into implementation. The design avoids decorative excess in favor of strong information hierarchy and brand consistency.
I also built a brand identity from scratch, including a custom logo designed in Figma. The logo uses the two O's in "TRANSPORTATION" as the wheels of a bus silhouette. This was a simple device that reads clearly at small sizes and ties the mark directly to the company's function. Inclusive Sans was selected as the primary typeface for its readability and accessible character. All text across the site was written to reflect the company's core values of dependability and reliability.
Public-Facing Pages. The public site includes a Contact form and a Quote Request form, both of which route submissions directly to the company's inbox via the Gmail API, eliminating the need for phone-based inquiries. An announcement banner on the home page surfaces real-time updates published by administrators, giving drivers and parents a single source of truth during weather events or schedule changes. Announcements are automatically purged at 3:00 AM the day following their set date to prevent stale information from surfacing.
Authentication. I led the design and implementation of the authentication system. After conducting in-depth research on JWT security best practices, I built a dual-token architecture using short-lived access tokens for API authorization and refresh tokens stored in HttpOnly cookies to maintain sessions without exposing credentials to the client. Role-based access control (RBAC) was layered on top to restrict sensitive administrative routes within the employee portal.
Announcement System. The announcement schema uses a one-to-many relational structure, associating a single announcement record with multiple schools and their individual status updates. The admin interface uses controlled state to toggle between a read view and an editable form, with conditional field logic to enforce valid input. For example, a delayed opening status requires a specified time, while a closure does not. Administrators can create, update, and delete announcements from the portal, and the home page banner renders schools in alphabetical order for quick scanning. I wanted the system to be generalized enough to support any type of announcement, not only weather events.
Reminders System. Administrators input important dates like license renewals, inspections, certification expirations across a fleet of approximately 160 buses through a form in the employee portal. Automated reminder emails are dispatched to the company inbox 30 days before each deadline via the Gmail API. A dashboard displays all reminders with their current status.
Message Dashboard. All Contact and Quote form submissions routed to the company email are also surfaced within the employee portal in a paginated message dashboard, giving administrators in-app visibility without relying solely on their inbox. Submissions are fetched in paginated batches to keep load times fast as the dataset grows.
User Management. Administrators can create accounts for employees and assign either user or admin roles. Admin-level users share access to the full administrative dashboard. User-level accounts are provisioned with private dashboards, which will serve as the foundation for the planned driver portal.
Backend Architecture. The backend follows MVC conventions where controllers encapsulate business logic, models handle SQL queries, and middleware (auth verification, input validation, rate limiting) is applied at the route level. All data is exchanged in JSON format for consistency with the frontend rendering layer.
The next planned phase is a driver-facing portal that allows employees to complete paperwork and submit forms digitally. As user volume and sensitive data scale, the authentication system will be migrated from the current JWT implementation to an OAuth-based solution. In the interim, ongoing work focuses on iterative UI and UX improvements across the existing portal.
