310TUTORS Multi-Campus Staff Operations Portal

The problem

310TUTORS runs after-school tutoring and test prep across multiple Los Angeles area campuses, including Santa Monica, Hawthorne, and a virtual campus. As the company grew, day-to-day operations were spread across Monday.com boards, Jotform intake forms, and Make.com automations stitched between them. Campus directors could see data belonging to other campuses, instructors filled out session forms that landed in boards they could not query, and leadership had no single view of the enrollment pipeline or instructional delivery.

The goal was a single internal portal where six distinct staff roles (Administrator, Clinical Director, Campus Director, Campus Coordinator, Instructor, and HR) each see exactly the records they are entitled to see, with the CRM pipeline and the instructional path running as two connected workflows inside one system.

Phase 1 consolidated the operational core: a normalized six-table schema covering Campuses, Staff, Families, Students, Instructional Plans, and Session Reports, built on Softr's native database. Rather than rebuilding from scratch, the existing five-table structure was extended and cleaned, which preserved historical records and shortened the migration window.

The interface layer was delivered as custom React (Vibe) blocks rather than stock components, because the role model required record-level scoping that off-the-shelf list blocks could not express. Each block resolves the signed-in user, reads their role and campus association through linked record fields, and gates both visibility and write access at the component level. Create and edit flows share a single form component so validation stays consistent, and action buttons are shown or hidden based on the actual table-level permissions returned by the platform rather than a hardcoded role list.

The client's brand palette (green, orange, blue, and fuchsia) was implemented as a token object with inline color values, driving a consistent design system across every screen, including animated empty and permission-gated states so that a restricted view reads as intentional rather than broken.

The result is a portal that replaced three separate tools, removed cross-campus data leakage, and gave leadership a live operational picture that previously required manual board exports.

What we built

310TUTORS operates after-school tutoring, executive functioning, and test prep programs across several Los Angeles campuses. Operations were previously split across Monday.com for pipeline tracking, Jotform for session reporting and intake, and Make.com for the automations connecting them. The fragmentation created three recurring problems: staff could see records outside their campus, session data was captured in forms that could not be queried back by the people who submitted them, and leadership had no consolidated view of enrollment or instructional delivery.

Phase 1 delivered a consolidated operations portal on Softr, built around a normalized six-table schema: Campuses, Staff, Families, Students, Instructional Plans, and Session Reports. The schema extended the client's existing structure rather than replacing it, so historical data migrated without loss and the cutover required no parallel-running period.

Two workflows drive the system. The CRM pipeline tracks families and prospective students from first inquiry through consultation, enrollment, and assignment to a campus. The instructional path tracks each enrolled student through their instructional plan, weekly session reports, and progress review, with parent-facing updates generated from the same records.

The interface was built as custom React blocks rather than stock components, because the permission model needed record-level scoping that standard list configurations could not express. Each block resolves the current user, reads their role and campus association through linked record fields with a primary and fallback resolution pattern, and applies a scope model with tolerant string matching so that minor naming variations in role labels do not silently break access control. Create and edit flows share a single form component, and action buttons are gated on the write permissions actually returned by the platform for that user group rather than on a client-side role list, so the UI can never offer an action the backend will reject.

Six roles are supported. Administrators see everything. Clinical Directors see instructional quality and analytics across campuses. Campus Directors and Campus Coordinators see only their own campus. Instructors see only their assigned students and their own session reports. HR sees the applicant and onboarding pipeline without access to student or family data.

The client's brand palette was implemented as a design token object applied through inline style values, which was necessary because dynamically constructed utility class names are stripped at build time. Every screen, including empty states and permission-gated views, uses the same tokens, so restricted views read as a deliberate part of the product.

An AI snapshot mechanism sits alongside the portal, using an automation layer to call a language model API and write a summarized student progress narrative back to the record, giving directors a readable status without opening every session report.

Phase 1 was delivered against fixed-price milestones. Phase 2, covering scheduling and calendar management, is scoped and pending commitment.