March – May 2025
Rancho Labs
B2B
Admin Panel
Internal Tool
At Rancho Labs, the operations team couldn't manage schools on their own. Every change required developers to modify code and the database. I designed the Super Admin Panel so operations can create schools, add data, and manage platforms independently. No developer involvement needed.
Note: Tool is in development
Rancho Labs is an EdTech startup incubated by IIT Delhi. They partner with schools to teach AI, Robotics, and Coding through hands-on learning. Each school gets a custom-branded LMS tailored to their needs and curriculum. The startup currently manages platforms for 30+ schools and is growing. Managing these platforms manually was becoming a constraint.
Every school management task at Rancho Labs required developer involvement. Creating schools, adding student data, customizing homepages, configuring settings-all meant developers writing code and updating the database. The operations team couldn't act independently. As the number of schools grew, developers spent more time on operational tasks instead of building features. Growth was limited not by operational capacity, but by developer bandwidth.
Additionally there was no centralized way to see or manage all schools. Everything was scattered across code changes and databases.
My team lead walked me through the entire workflow. They showed me how schools were created, where bottlenecks happened, and why developers were required for every task. I identified three core constraints: developer dependency, no visibility across all schools, and scattered data across code and databases.
Researched how platforms handle similar operational workflows. The pattern was clear: centralized dashboards with self-service capabilities eliminate bottlenecks and reduce dependency on engineering teams.
I mapped out the core tasks operations needed to do independently: create schools, add student data, configure settings, monitor platforms. I created wireframes to test the concept quickly and worked with the team lead and engineers to validate feasibility.
When features were too complex or time-consuming to build, I simplified or postponed them. The goal was shipping a tool operations could use immediately, not a perfect product months later.
Designed a centralized admin panel that allows the team to create, edit, monitor, and manage all school LMS platforms from one place.
The team lead reviewed wireframes and prototypes regularly, pointing out what would actually help and what could wait. When I proposed complex features, engineers explained why they were difficult to build, so I simplified them. These conversations shaped the design not to make it flashy, but to make it practical. I worked with both teams to ensure what I designed was both useful and actually buildable.
The tool is in development and being tested with the team. The intended outcome is clear: operations will be able to create schools, add data, and manage platforms without asking developers for help. This frees developers to work on features instead of operational requests. Once deployed, we'll measure how this actually impacts development time and onboarding speed. Right now, the primary benefit is removing the bottleneck that was limiting growth.
This project showed me that internal tools succeed by solving the actual problem, not by being polished or complex. The operations team didn't care about beautiful design they cared about independence and visibility. I also learned that working within constraints (limited time, limited scope) often produces better results than trying to build everything. Feedback from someone actually trying to use the design is more valuable than any design principle.
