Understand the problem
Define your users, core journey, scope, assumptions, and success conditions in a one-page brief.
THE HACKATHON THEME
Build something small enough to finish—and thoughtful enough to defend.
Four real-world domains. One assigned problem. Architecture you can explain, verify, and evolve. A prototype is optional.
Explore how state and recovery fit together.
Draw one of four domains at random and solve its assigned problem. Start with a one-page solution brief, then design the architecture and record your decisions. Show a clear user journey, consistent state, reliable behaviour, and choices you can defend. Working code is optional.
AI can help you build. Your architectural decisions still need evidence. AI tools and AI features are optional; the challenge is to design for change and show why your choices work.
Architecture accounts for 60% of the score.
Define your users, core journey, scope, assumptions, and success conditions in a one-page brief.
Prepare HLD, focused LLD, and as many ADRs as your design needs, explaining responsibilities, state, dependencies, and tradeoffs.
Explain the core flow, a failure and recovery, and a realistic requirement change. Prototype only if it helps.
Your team draws a domain at random and receives its fixed problem statement. Browse the domains here; these buttons do not assign your domain. Every track uses the same requirements, deliverables, and judging criteria. Clarify any open scope with an organizer.
Design a mobile solution that helps employees submit expenses and reviewers manage reimbursement requests.
Business rule: An approved amount cannot exceed the claimed amount. Retrying a submission must not create duplicate claims.
Architecture focus: Monetary values, validation, approval transitions, and submission consistency. Payment processing and receipt scanning are optional.
Design a mobile solution that helps patients request appointments and clinics manage availability.
Business rule: A confirmed slot cannot be allocated to two patients. A cancelled appointment must update availability consistently.
Architecture focus: Scheduling, competing requests, changing availability, and consistent patient and clinic views. Use fictional patients; clinical advice, medical records, and video consultations are outside the required scope.
Design a mobile solution to a property issue faced by people in Mumbai. Work from the specific problem assigned by the organizers and identify its users, such as renters, buyers, residents, owners, or housing societies.
The domain includes rental discovery and affordability, transparent total costs, listing accuracy and availability, and housing-society coordination. These are context for the domain; your assigned problem determines the scope.
Business rule: Define and enforce a rule that protects the consistency of your chosen workflow. For example, a listing marked unavailable cannot accept a new viewing request, or a closed maintenance request requires explicit reopening before work resumes.
Architecture focus: Reliable property information, explicit workflow states, updates across user views, and recovery from stale or conflicting data. Use sample listings and data; live property integrations and maps are optional.
Design a mobile solution that helps marketing teams prepare campaign proposals and coordinate approvals.
Business rule: Only an approved campaign can be scheduled. Changing an approved proposal’s budget or audience must trigger another review.
Architecture focus: Revisions, approval validity, workflow state, and decision history. Actual ad publishing, external marketing integrations, and generated content are optional.
Working code, a complete app, login screens, and polished UI are not required. Use diagrams, contracts, example data, and structured walkthroughs. A prototype or demo is optional; identify simulations and do not claim guarantees you have not verified.
Your technology and dependency choices should suit the problem and available time. AI, IoT, animations, and external integrations are optional. Your team must understand and defend all submitted material, including AI-generated work.
Use this checklist to prepare your submission. Your checks are saved in this browser; they are not submitted to MAL.
0 of 5 ready
Architecture accounts for 60% of the score. The remaining 40% recognises verification and observability, the core user journey, and your architecture defence. Evidence may be a structured design walkthrough or an optional prototype; working code is not required.
| Criterion | Weight | What judges will assess |
|---|---|---|
| Problem framing and scope | 10% | Clear assumptions, constraints, priorities, and deliberate scope choices. |
| Structure and boundaries | 15% | Clear responsibilities, understandable dependencies, and separation appropriate to the app. |
| Data and state management | 15% | Source of truth, state transitions, persistence, validation, and consistency. |
| Failure and recovery | 10% | Predictable behaviour during interruptions, retries, conflicts, and errors. |
| Trade-offs and adaptability | 10% | Justified choices, acknowledged limitations, and a credible approach to change. |
| Verification and observability | 15% | Credible test scenarios and diagnostic design that verify important behaviour and support investigation. Working tests are optional evidence. |
| Core user journey | 15% | A complete, understandable core flow, demonstrated through a structured walkthrough or optional prototype, including relevant success and error states. |
| Architecture defence | 10% | Clear explanations grounded in the proposed design and evidence, acknowledged limitations, and thoughtful responses to questions. |
| Total | 100% | 60% directly allocated to architecture. |
Build something small enough to finish—and thoughtful enough to defend.
These optional integrations complement the core 100-point judging rubric. Prioritise your architecture submission first. If you build a prototype, demonstrate the actual integration and its evidence; a mention in a diagram alone is not a working integration.
measure.sh
Integrate the Measure SDK in your mobile app and capture performance evidence from a real user journey.
Demo evidence: A working SDK integration, captured performance data, and your explanation of the result.
Measure SDK documentationUse Google’s Gemini 4 Argon model (gemini-4-argon) to power a meaningful feature that participants can demonstrate inside the mobile app.
Demo evidence: A working in-app AI feature. Using AI only to generate your code does not fulfil this integration.
Gemini 4 Argon documentationJoin solo or bring a team. Every team can have one, two, or three people.
Solo builders are welcome. Maximum team size: 3.
1 November 2026, 10:00 AM–6:00 PM IST.
Hosted at Paytm in Mumbai. Venue details will be shared with registered participants.
Complete your RSVP on Nivanth. The ₹100 event fee is payable separately; payment instructions will be shared with registrants.
Thanks to the teams supporting the Mobile Architecture Lab 4 Hackathon.


Register on Nivanth to RSVP. The ₹100 participation fee is paid separately.