The short version
- 01
During my software engineering internship, I worked on an internal portal that brought recurring scripts and operational workflows into one place instead of leaving them as separate tools that had to be run, checked, and debugged manually.
- 02
The project involved much more than putting buttons in front of scripts. The system needed permissions, scheduling, live status, logs, error handling, and a clear way for internal teams to understand what was happening without reading through backend output themselves.
The problem
The existing workflows worked, but they depended too heavily on engineering knowledge and repeated manual steps.
Internal teams needed a faster way to run approved automations, see whether they succeeded, and understand when something actually required attention.
What I built
- Django APIs for internal automation workflows
- React portal for running and monitoring jobs
- Scheduling and background task support
- Real-time execution status and logs
- Role-based access and OAuth sign-in
- PostgreSQL-backed workflow and result data
- AWS EC2 deployment with Gunicorn and Nginx
Design decisions
The interface was designed around state. A user needed to understand what could be run, what was currently running, what finished, and what failed without digging through technical details first.
The goal was not to expose every possible configuration. It was to make the common, approved workflow easier while keeping the risky or unusual cases controlled.
Technical decisions
Django provided the API and permission structure, while React gave the portal a more responsive monitoring experience.
Celery and background workers handled longer-running jobs, WebSockets supported live updates, and PostgreSQL stored the workflow state and results.
The application was deployed on AWS EC2 behind Gunicorn and Nginx, which gave me direct experience taking a full-stack internal system from local development into a maintained environment.
Challenges
The main challenge was making automation failures understandable. A script can fail for many reasons, but the interface still has to tell a non-author what happened and what they should do next.
Performance also mattered once several workflows and users were active at the same time, so backend queries and data handling had to be tightened as the portal grew.
The outcome
The portal automated more than 15 recurring IT workflows, cut roughly 150 hours of repeated manual work a year, and made internal operations easier to monitor from one place.
I also worked through the backend bottlenecks behind the portal, improving API query performance under concurrent load.
What I'd improve next
A later version could make more workflow configuration self-service while still preserving approvals, permissions, and safe failure behavior.
Let's Talk
Want something like this for your business?
Whether it's a website, a system, or an idea that still feels a little messy, I can help you figure out what makes sense next.