Inspiration
A classroom suddenly becoming unavailable sounds like a simple problem:
Move the affected class to another empty room.
But what happens when the best replacement room is already occupied?
That class might be able to move somewhere else, which may require moving another class again. One unavailable classroom can create a chain reaction across the timetable.
That's why I built ClassShift.
When a classroom goes offline, repair the schedule — not the whole school day.
Instead of rebuilding an entire timetable, ClassShift asks one focused question:
What is the smallest set of room changes that keeps every class in the affected period running without breaking any modeled requirement?
For school administrators and timetable coordinators, the goal is straightforward: recover from an unexpected room disruption while changing as little of the school day as possible.
ClassShift began as a classroom-recovery engineering prototype. I also see an opportunity to develop it into a practical education-operations product for schools, colleges, and institutions managing shared classrooms and laboratories.
What it does
ClassShift is a decision-support tool for classroom disruption recovery.
The workflow is simple:
Select a period → Mark unavailable rooms → Preview impact → Find recovery → Review changes
ClassShift considers every class in the affected period, not only the class whose room became unavailable.
It respects modeled constraints including:
- Room availability and capacity
- Required room features and equipment
- Verified step-free metadata when required
- Locked classes that cannot be reassigned
- Same-period room conflicts
- Preservation of existing lesson times
Keeping a class in its original room costs 0. Moving it to another valid room costs 1.
The optimization objective is therefore:
Find a complete valid schedule with the fewest room changes.
If no complete assignment satisfies all hard constraints, ClassShift returns INFEASIBLE instead of silently weakening a requirement.
The administrator can inspect the proposed recovery before deciding whether to use it.
The idea that makes ClassShift different
The main demonstration begins when LAB_A becomes unavailable during Monday Period 3.
Chemistry must leave LAB_A, but the room it needs is already occupied.
ClassShift discovers a coordinated recovery:
Chemistry: LAB_A → LAB_B
Biology: LAB_B → LAB_C
Physics: LAB_C → ROOM_D
Only one room failed, but the minimum valid recovery requires three coordinated room changes.
A simple tool that searches only for an empty room for Chemistry may miss this solution.
ClassShift solves the assignment problem across the whole affected period. It can discover relocation chains involving initially unaffected classes while still minimizing overall disruption.
The key difference is that ClassShift doesn't optimize a single classroom move in isolation. It optimizes the complete recovery.
How I built it
ClassShift uses:
- Python 3.11 for the backend and optimization logic
- Flask for the API
- Google OR-Tools for exact assignment optimization
- Waitress for serving the application
- HTML5, CSS3, and JavaScript for the frontend
- pytest for automated verification
I modeled classroom recovery as a constrained assignment problem.
For every lesson-room pair, ClassShift determines whether the room satisfies the modeled constraints.
The system constructs a candidate graph and uses an OR-Tools min-cost-flow formulation to find a minimum-cost complete assignment.
The objective assigns zero cost to retaining an existing valid room and unit cost to moving a class.
ClassShift deliberately operates within a narrow scope.
It does not regenerate a school's entire timetable, change teaching periods, or reschedule lessons across different times.
It repairs room assignments within the disrupted period.
This makes the proposed recovery easier to understand, verify, and review.
Building for trust
Finding an optimized answer was not enough.
A mathematically optimal result is only useful if the input constraints were modeled correctly and the resulting assignment is valid.
After OR-Tools proposes a recovery, ClassShift sends the result through a separate validator.
The validator independently checks that:
- No lessons were dropped, invented, or duplicated
- No lesson was moved to another period
- Unavailable rooms were not assigned
- Room capacity and feature requirements were preserved
- Locked assignments remained unchanged
- No room was double-booked
- Accessibility-related requirements were respected according to supplied metadata
- The reported number of room changes was correct
Only a proposal passing validation can be presented as a successful recovery.
For small test cases, I also created an independent brute-force oracle and compared the optimizer's feasibility and minimum move count against exact answers.
This provides three layers of correctness:
Constraint modeling → Exact optimization → Independent validation
Rather than relying only on successful example runs, the project explicitly tests incorrect, adversarial, and corrupted outcomes.
When the correct answer is "no solution"
The second demonstration makes ART_1 unavailable during Monday Period 1.
The affected class requires a specialized room feature that no remaining valid room provides.
ClassShift returns:
INFEASIBLE
It does not remove the requirement, assign an incompatible room, change the lesson time, or pretend that a software failure means no valid schedule exists.
The system distinguishes genuine mathematical infeasibility from invalid inputs, solver failures, validator failures, and unexpected internal errors.
One principle guided the entire project:
ClassShift doesn't invent a schedule when the constraints cannot be satisfied.
Challenges I faced
The biggest challenge was realizing that the problem is global rather than local.
At first, moving only the directly affected class seems reasonable. But a valid recovery can require moving classes that were never directly affected by the outage.
That insight transformed the project from a simple room lookup into an exact assignment-optimization problem.
A second challenge was distinguishing no valid recovery exists from the software failed.
Those outcomes require completely different responses from an administrator. I implemented separate states and validation paths to prevent them from being confused.
Another challenge was ensuring that the optimizer and validator did not depend entirely on identical eligibility logic. Shared defects could otherwise cause both components to agree on the same incorrect assignment.
I also addressed frontend race conditions so an outdated recovery response cannot overwrite the interface after a user changes the selected outage.
These were not just algorithmic problems. They involved API correctness, asynchronous interface behavior, error handling, testing, and trust.
Accomplishments I'm proud of
The final RC8 release passed:
- 171 automated Python tests
- 34 mandatory release-critical checks
- 16 measured synthetic OR-Tools benchmark scenarios
- Real Waitress endpoint smoke testing
- Independent brute-force differential checks
- Validator corruption and adversarial tests
Testing covers optimizer correctness, input validation, multi-period behavior, API responses, property-based scenarios, error classification, and release-verifier behavior.
The main demonstrations are also protected by release tests:
LAB_A / Monday Period 3 → Minimum three-move recovery
ART_1 / Monday Period 1 → Genuine infeasibility
The release verification demonstrates correctness across the modeled scenarios. It does not establish production readiness or validation against real institutional timetables.
The achievement I'm most proud of is building a system that can explain what needs to move, why a recovery is valid, and when a recovery is impossible.
Who would use ClassShift?
ClassShift is designed for organizations that manage many classrooms, laboratories, and shared teaching facilities.
The primary users are:
- School timetable coordinators
- College academic administrators
- Campus operations teams
- Laboratory and classroom scheduling staff
The potential paying customers are schools, colleges, and education groups responsible for managing those facilities.
The problem is particularly relevant where rooms have specialized equipment, capacity restrictions, or accessibility-related requirements.
A general timetable generator helps create a schedule before the academic day begins.
ClassShift addresses a different problem: what happens when an already-created schedule breaks.
This distinction provides a focused starting point for developing a business.
Rather than replacing an institution's complete timetable-management system, ClassShift could eventually become a disruption-recovery capability integrated into existing administrative software.
Business model and financial sustainability
My proposed business model is annual institutional licensing.
Instead of charging teachers or students, ClassShift would charge schools and colleges that use the recovery workflow.
An initial pricing hypothesis is:
$199 per campus per year for a future production-ready version, with custom institutional pricing for larger campuses and education groups.
At 50 paying campuses:
50 × $199 = $9,950 in annual recurring revenue
At 100 paying campuses:
100 × $199 = $19,900 in annual recurring revenue
These are illustrative revenue scenarios, not existing sales, confirmed demand, or validated pricing.
The current prototype has no paying customers.
The initial pricing would need to be tested against customer willingness to pay and the actual cost of serving each institution.
Operating expenses would include cloud hosting, onboarding, customer support, software maintenance, security, and integration work.
An advantage of the current approach is that the core optimizer operates on conventional CPU resources and does not require paid LLM inference for every recovery.
However, computational efficiency alone does not guarantee profitability. Customer acquisition, integration complexity, and support costs could be more significant than the cost of running the solver.
A sustainable business would require demonstrating that the product saves enough administrative effort and disruption-related costs to justify its subscription.
The first commercial milestone would therefore be validated customer demand, not revenue projections.
Go-to-market strategy
I would begin with schools and colleges that have shared laboratories, specialized classrooms, and complex room allocation requirements.
The initial approach would have four stages.
1. Problem validation
Interview timetable coordinators and campus administrators to understand how frequently classroom disruptions occur, how they currently resolve them, and how much operational effort recovery requires.
2. Supervised pilots
Test ClassShift using synthetic or institution-approved non-sensitive schedules and compare its proposed recoveries with existing administrative workflows.
3. Measure practical value
Evaluate recovery time, number of required changes, administrator understanding, and the percentage of modeled disruption scenarios resolved successfully.
4. Institutional licensing
If the pilots establish practical value, test annual licensing and potential integration partnerships with timetable-management providers.
The initial target would be a small number of institutions willing to evaluate the workflow.
No institutional adoption, completed pilots, or measured real-world time savings are claimed for the current prototype.
Scalability
ClassShift currently runs as a Flask application using Google OR-Tools and a bundled synthetic timetable.
The existing implementation is a locally runnable prototype, not a deployed multi-tenant school-management SaaS platform.
Its optimization model focuses on a single affected period.
Because the current problem formulation does not introduce dependencies between periods, separate periods can be solved independently.
This provides a useful foundation for handling multiple disruption requests.
To support real institutions, a production architecture would need:
- Secure institution-specific timetable storage
- Authentication and administrator authorization
- Timetable import and validation
- Tenant isolation between schools
- Controlled optimization workers
- Audit logs for proposed and approved changes
- Monitoring, deployment automation, and recovery mechanisms
- Integration with existing scheduling platforms
The optimization service could be separated from the web application and executed by independent workers as demand grows.
However, solver performance depends on the number of lessons, eligible room assignments, and constraints.
The current 16 synthetic benchmark scenarios provide development evidence, but they do not establish performance for every school size or large production workload.
Larger and more representative datasets would be required to measure latency, memory consumption, concurrent request handling, and operating costs.
The intended architecture would preserve the same core principle: compute a minimum-disruption recovery and verify it before presenting it.
Design and user experience
ClassShift hides optimization complexity behind a simple administrative workflow:
Select outage → Preview impact → Find recovery → Review changes
The interface shows which classes are affected, where they would move, how many changes are required, and whether the proposed assignments satisfy the modeled constraints.
The user does not need to understand graph algorithms or min-cost flow.
The tool focuses on the decision an administrator actually needs to make.
Instead of presenting a complicated optimization report, it presents a clear recovery proposal that can be reviewed before operational use.
A key UX decision was to distinguish between a valid recovery, genuine infeasibility, invalid input, and internal failure.
Those states should never look identical to the person making the decision.
Impact and underserved institutions
Unexpected room closures can interrupt teaching, delay laboratory sessions, and create additional administrative work.
Large institutions may have dedicated scheduling software, but smaller schools and colleges may rely on manual coordination or spreadsheets.
ClassShift explores whether a focused recovery tool could make sophisticated optimization more accessible to institutions without dedicated operations-engineering teams.
Potential benefits include reduced scheduling disruption, fewer unnecessary room changes, and clearer administrative decision-making.
These benefits remain hypotheses until validated in real school workflows.
The current prototype establishes technical feasibility for the modeled problem, not proven educational outcomes.
Privacy and responsible use
The bundled timetable is completely synthetic and contains no real student records.
ClassShift is a decision-support prototype. A human reviews the proposed recovery before it would affect a real timetable.
The system only reasons about constraints represented in its input.
Accessibility-related decisions depend on supplied, verified room metadata. ClassShift does not independently certify room accessibility or guarantee regulatory compliance.
It also does not model every possible operational factor, such as walking time between buildings, real-time staff availability, or institution-specific emergency procedures.
These limitations would need to be addressed or explicitly managed before real-world deployment.
AI use
I used ChatGPT and OpenAI Codex / Terra during development for brainstorming, implementation assistance, debugging, adversarial testing, edge-case analysis, test design, release hardening, and documentation.
AI does not generate ClassShift recovery plans at runtime.
The deployed application logic uses deterministic constraints and Google OR-Tools optimization.
Successful proposals are checked using an independent programmatic validator.
The central engineering contribution is the constrained optimization and verification system, not an AI-generated timetable.
What I learned
The biggest lesson was that a problem can look simple locally while being difficult globally.
Moving a single affected class is easy to understand. Finding the smallest valid set of coordinated movements requires reasoning about the entire affected period.
I learned how to model interconnected assignment decisions, use OR-Tools for exact optimization, and verify optimizer output with independent checks.
I also learned that correctly identifying an impossible problem is as important as solving a feasible one.
Beyond the algorithm, the project reinforced how much reliability depends on input validation, API behavior, frontend concurrency, adversarial testing, and clear communication of limitations.
The business exploration added another lesson:
A technically correct solution is not automatically a viable product.
Building a company around ClassShift would require understanding administrators' daily workflows, integrating with existing systems, and proving that institutions would pay for the value it provides.
What's next
ClassShift was originally developed as a focused classroom-recovery prototype and has been presented previously in a hackathon context.
For Next Founders, I am presenting its potential as an education-operations startup while preserving the original engineering evidence and being transparent about its current limitations.
The next steps would be to:
- Interview real timetable administrators.
- Validate the current constraints against institutional workflows.
- Support importing institution-specific timetables.
- Measure performance on larger, realistic datasets.
- Evaluate integrations with existing academic scheduling systems.
- Run supervised pilots and test willingness to pay.
- Develop a secure, institution-ready deployment architecture.
The immediate priority is not adding unnecessary features. It is determining whether the existing solution addresses a sufficiently frequent and valuable problem for real customers.
ClassShift's vision is simple: when a classroom becomes unavailable, recover the school day with the fewest necessary changes — and verify the result before anyone acts on it.
Log in or sign up for Devpost to join the conversation.