Mobile Architecture Lab · Event 04

THE HACKATHON THEME

Architects
in AI ERA.

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.

DESIGN FOR CHANGEReady
A mobile request with a recoverable interruption One possible architecture: a mobile app sends an action through domain rules to a service, with a local record available for recovery. Domain rules Service Local record ACTION → RULES → STATE → EVIDENCE
One possible flow. What happens when a request fails?

Explore how state and recovery fit together.

Sunday, November 1, 202610:00 AM–6:00 PM ISTPaytm · MumbaiTeams: 1–3 peopleParticipation: ₹100
The theme · Architects in AI ERA

One meaningful problem.
Architecture you can defend.

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.

01 · FRAME

Understand the problem

Define your users, core journey, scope, assumptions, and success conditions in a one-page brief.

02 · DESIGN

Defend your decisions

Prepare HLD, focused LLD, and as many ADRs as your design needs, explaining responsibilities, state, dependencies, and tradeoffs.

03 · VERIFY

Walk through the evidence

Explain the core flow, a failure and recovery, and a realistic requirement change. Prototype only if it helps.

Explore the four domains

Four domains.
One engineering challenge.

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.

01 · FINTECH

Expense claims and reimbursements

Design a mobile solution that helps employees submit expenses and reviewers manage reimbursement requests.

  1. An employee creates an expense claim with an amount, category, and description.
  2. The employee submits the claim.
  3. A reviewer approves or rejects it, with a reason where appropriate.
  4. Both users can see the current status and decision history.

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.

02 · HEALTHTECH

Appointment coordination

Design a mobile solution that helps patients request appointments and clinics manage availability.

  1. A patient browses available appointment slots.
  2. The patient requests a slot.
  3. The clinic confirms or declines the request.
  4. The patient can see its status and cancel a confirmed appointment.

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.

03 · PROPTECH

Solve a Mumbai property issue

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.

  1. A user discovers or reports a property-related need.
  2. The user takes a meaningful action, such as making an enquiry, submitting a request, or reporting an issue.
  3. Another role or service responds to that action.
  4. The user can track the outcome, status, and latest information.

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.

04 · MARTECH

Campaign review and approval

Design a mobile solution that helps marketing teams prepare campaign proposals and coordinate approvals.

  1. A marketer creates a campaign proposal with its objective, audience, channel, and budget.
  2. The marketer submits it for review.
  3. A reviewer approves it or requests changes.
  4. The marketer can revise the proposal and track its approval or scheduling status.

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.

Requirements for every track

Make the essential behaviour clear.

  • Frame the assigned problem in a one-page brief: users, core journey, scope, assumptions, constraints, and success conditions.
  • Prepare HLD and focused LLD: major components and data flows, plus the modules, interfaces, models, and state transitions for one critical feature.
  • Explain enforcement of the business rules and identify the source of truth. Confirm any unclear rule with an organizer.
  • Write as many ADRs as your design needs. There is no fixed count or upper limit. For each, explain the context, alternatives, decision, consequences, and when you would revisit the choice.
  • Walk through a failure and recovery, such as an interrupted submission, an unavailable service, a stale-data conflict, or a pending action after restart.
  • Explain verification and diagnostics: show example inputs and outcomes, a test plan, and how you would investigate failures. Working tests are welcome if you write code.
  • Discuss one realistic requirement change and which parts of your architecture it affects. Use the architecture reference to prioritise relevant quality attributes.

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.

What to submit

Your architecture. Your evidence.

Use this checklist to prepare your submission. Your checks are saved in this browser; they are not submitted to MAL.

0 of 5 ready

During your presentation: Walk through the core journey, business rule, failure and recovery, and one realistic future requirement. A prototype is optional. Every team member should understand and defend the architecture. See the FAQs for submission and volunteer guidance.
Architecture-focused judging

Decisions backed by evidence.

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.

Understand what judges are looking for. Explore quality attributes such as scalability, reliability, resilience, and security, with practical examples and ways to verify your design. This reference explains the criteria; it does not add scoring categories.
MAL 4 judging criteria · 100 points
CriterionWeightWhat judges will assess
Problem framing and scope10%Clear assumptions, constraints, priorities, and deliberate scope choices.
Structure and boundaries15%Clear responsibilities, understandable dependencies, and separation appropriate to the app.
Data and state management15%Source of truth, state transitions, persistence, validation, and consistency.
Failure and recovery10%Predictable behaviour during interruptions, retries, conflicts, and errors.
Trade-offs and adaptability10%Justified choices, acknowledged limitations, and a credible approach to change.
Verification and observability15%Credible test scenarios and diagnostic design that verify important behaviour and support investigation. Working tests are optional evidence.
Core user journey15%A complete, understandable core flow, demonstrated through a structured walkthrough or optional prototype, including relevant success and error states.
Architecture defence10%Clear explanations grounded in the proposed design and evidence, acknowledged limitations, and thoughtful responses to questions.
Total100%60% directly allocated to architecture.
Consistent evidence matters. Judges will check that diagrams, decision records, walkthroughs, and any optional code agree. Explain the complete core journey and label simulated behaviour. Working code is not required for a top award. Framework names, number of layers, code volume, feature count, and visual complexity earn no points by themselves.

Build something small enough to finish—and thoughtful enough to defend.

Brownie points · Optional enhancements

Go a little further.
Show it working.

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 logo measure.sh
01 · MEASURE SDK

Integrate Measure.
Showcase your app’s performance.

Integrate the Measure SDK in your mobile app and capture performance evidence from a real user journey.

  • Show a useful metric or trace, such as launch time, network activity, or the duration of an important workflow.
  • Walk judges through the captured data in Measure and explain what it reveals about your app.
  • If you optimise a bottleneck, show comparable before-and-after measurements.

Demo evidence: A working SDK integration, captured performance data, and your explanation of the result.

Measure SDK documentation
Google Gemini logo Gemini
02 · GEMINI 4 ARGON

Bring Argon
inside your app.

Use Google’s Gemini 4 Argon model (gemini-4-argon) to power a meaningful feature that participants can demonstrate inside the mobile app.

  • Connect the feature to your chosen domain, such as summarising a campaign brief or explaining property information.
  • Show a real model response in the app and explain the request, response, and data flow.
  • Demonstrate clear loading and failure states, and explain how the app handles unavailable or unsuitable responses.

Demo evidence: A working in-app AI feature. Using AI only to generate your code does not fulfil this integration.

Gemini 4 Argon documentation
Team up

Small teams.
Big build energy.

Join solo or bring a team. Every team can have one, two, or three people.

1–3 people / team

Solo builders are welcome. Maximum team size: 3.

Event details

Save the date.

WHEN

Sunday · Nov 1

1 November 2026, 10:00 AM–6:00 PM IST.

WHERE

Paytm · Mumbai

Hosted at Paytm in Mumbai. Venue details will be shared with registered participants.

FEE

₹100 participation fee

Complete your RSVP on Nivanth. The ₹100 event fee is payable separately; payment instructions will be shared with registrants.

Payment note: Your RSVP is on Nivanth. The ₹100 participation fee is separate; payment instructions will follow after registration.
Made possible with

Our event sponsors

Thanks to the teams supporting the Mobile Architecture Lab 4 Hackathon.

MAL 4 · November 1, 2026

Ready to build?

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

Register on Nivanth →