From data model to deployment.
A two-semester capstone where I owned the backend and cloud engineering for a real business.
4 user roles
Distinct permissions and data access
Backend + cloud
My areas of ownership
Scripted deployment
Documented for the company
The system we were asked to build
For my senior capstone at Sacramento State, my team and I created an end-to-end project management system for ATM Electric INC. It covered project views, user management, payments, documents, and contracts. We had two semesters to complete and deploy it.
My role was backend engineer and cloud engineer. That meant making architectural decisions early and then carrying those decisions through implementation and deployment.
Why I chose Django
I chose Django primarily because of its built-in ORM and admin panel. Those tools gave us a practical foundation for a system with several kinds of business records, users, and management workflows.
I was responsible for the backend architecture and data model, as well as the logic that determined which users could access each part of the system.
Four roles, enforced at the backend
One of the most complex parts was the role-based access control system. We had four user types: Admin, Employee, Contractor, and Client. Each needed different views, permissions, and access to data.
I used Django Groups and Permissions and extended authentication with django-allauth for email verification and session management. I had to think carefully about every endpoint. A Contractor should not see financial data meant for Admins, and a Client should not have access to User Management.
Getting this right meant enforcing access in the backend. Hiding a page or button would not be enough if the underlying endpoint still returned information it should not.
Taking it to production
As the cloud engineer, I provisioned the Ubuntu server, configured Nginx as the reverse proxy, and set up Gunicorn to serve the Django application. I secured it with a Let’s Encrypt certificate and routed traffic through Cloudflare.
Deployment involved pulling code, activating the virtual environment, installing dependencies, running database migrations, collecting static files, and restarting services. I automated those steps into a setup script and documented the process for the company.
The part I carry into other projects
This project pushed me to think beyond writing code that works on my machine. I had to make decisions about access, maintainability, deployment, and how someone else would operate the system.
I enjoy that whole stretch of the work: understanding the requirements, designing the backend, and getting the application into a state where people can actually use it.