School / University ERP System

Problem Statement

Design and build a foundational School/University ERP system that can be used by multiple institutions and scale as the number of students, staff, and schools grows. The product should cover a clear core user workflow that students can easily understand and visualize (such as onboarding users, managing academic records, or institutional operations). In the initial abstract and presentation stage, teams must propose their feature set and a high-level system architecture showing how the system would scale across institutions and users. For the hackathon implementation, selected teams should build the proposed architecture to a realistic extent, focusing on delivering an end-to-end working product. The backend must be built using Python, while teams are free to use any frontend framework and any database or infrastructure components that best fit their design. Teams are encouraged to make strong engineering decisions that maximize speed and impact, including using third-party tools or services (e.g., OAuth-based authentication providers) to avoid unnecessary code ownership. The primary goal is to evaluate how quickly teams can go from zero to one by building only what is essential, making production-minded architecture choices, and demonstrating strong founding velocity. Teams are recommended to leverage their favorite AI-powered tooling as they see fit. The problem statement is intentionally open-ended on certain aspects to encourage candidate teams in showcasing their creative engineering skills. Candidate teams during their hackathon are expected to work on a public repository since their code will be evaluated for quality and accuracy among other things.

Evaluation Guidelines

1. Product Completion

Looking for:

• The team delivers a working product that can be used end to end.
• The main user flow works without requiring explanations.
• The scope is clear and intentionally limited.

Not looking for:

• Only mockups or partial implementations.
• Many features started but none completed.

2. User & Product Understanding

Looking for:

• The team clearly understands who the user is and what problem is being solved.
• Features directly support the main user workflow.
• The team can explain why certain features were not built.

Not looking for:

• Unclear target user or problem.
• Features added without a clear purpose.

3. System & Architecture Choices

Looking for:

• The system architecture is simple and appropriate for the problem.
• Correct use of components such as frontend, backend, database, and infrastructure.
• Infrastructure choices match the product needs (e.g., managed services where suitable).

Not looking for:

• Overly complex architecture without justification.
• Incorrect or unnecessary infrastructure components.

4. Engineering Judgment

Looking for:

• The team avoids unnecessary work by using existing tools and services.
• Examples include using OAuth for authentication or managed AI APIs instead of self-hosting or implementing relevant modules.
• Technical decisions help the team ship faster and more reliably.
• Researching and reusing the most appropriate libraries for the task.

Not looking for:

• Rebuilding standard components without need.
• Complex setups that slow down delivery.

5. Functional & Accessible UI

Looking for:

• The interface is clear, usable, and easy to navigate.
• Forms, errors, and loading states are handled properly.
• Accessibility basics such as readable text and keyboard usage are considered.

Not looking for:

• UI looks good but does not work well.