Less uncertainty.
More architecture.

Each team draws a domain at random from Fintech, Healthtech, Martech and Proptech. Browsing the website’s track buttons only explores the challenges; it does not allocate a domain.

Your drawn domain comes with a fixed problem statement. Work on that assigned problem rather than substituting your own. For example, the Fintech challenge is expense claims and reimbursements. Clarify any open scope with an organizer before proceeding.

Do not assume a swap or redraw is permitted. Ask the organizing team; volunteers should refer allocation requests to them.

Teams may have one, two or three people. Solo participants are welcome; the maximum team size is three.

Ask an organizer, note the clarification and make your assumptions visible in the solution brief. Volunteers should escalate questions that change scope, business rules or judging expectations.

No. The required outcome is a clear, defensible architecture for the assigned mobile solution. You may use a prototype or demo to explain it if time permits. Working code is optional.

No. Skip login screens and decorative UI. Show the essential user journey, roles, decisions and states clearly. If access control matters, explain where permissions would be enforced even if roles are simulated.

Start with a one-page solution brief: users, problem, core journey, scope, assumptions, constraints and success conditions. Then prepare high-level design, low-level design and a critical feature walkthrough, followed by Architectural Decision Records. Prototype afterward if it adds value.

Yes. Use fictional or sample data and label mocks, simulations and assumptions. Explain the production behavior you intend, and do not present a simulation as proof of a working integration.

AI tools and AI features are optional. Your team must understand and defend all submitted material, including anything generated with AI. Explain relevant data flow, privacy, failure behavior and limitations for an AI feature.

There is no prescribed framework, cloud service or architecture pattern. Choose what fits the problem and constraints. Extra layers, microservices or fashionable tools do not earn points by themselves.

• A one-page solution brief.
• A high-level design (HLD).
• A low-level design (LLD), including one critical feature in depth.
• Architectural Decision Records (ADRs): as many as your design needs, with no fixed count or upper limit.
• A walkthrough of the core journey, an important failure and a realistic requirement change.
• An optional prototype or demo.

Keep these in a form judges can open and review. Confirm the submission channel and deadline with the organizers.

Show the app, major components, services, storage and external systems. Explain responsibilities, boundaries, dependencies, major data flows and the authoritative source of state.

Focus on the core workflow rather than every screen or class. Show relevant modules, interfaces, data models, state transitions and errors. Go deeper on one feature where an important architectural decision becomes visible.

Explain the context, alternatives, chosen approach, reasons, consequences and what might cause you to revisit the decision. Write as many ADRs as your design needs; there is no fixed count or upper limit. Focus on meaningful decisions rather than a list of unexplained technology choices.

No. Use the architecture reference to identify relevant concerns. A useful exercise is to choose three priority attributes and define a target, supporting decision, verification approach and tradeoff for each. Always address the business rules and relevant security and privacy concerns.

Use sequence diagrams, interface contracts, example data, state transitions and a structured walkthrough. For reimbursement, show what happens when the service saves a claim, the response is lost and the app retries. Explain how duplicate claims are prevented.

No working code is required, so a source repository and automated tests are not compulsory. Provide a credible verification plan with inputs and expected outcomes. If you implement a prototype, include relevant code, setup steps or tests as supporting evidence.

Pick a realistic change and identify the modules, contracts, state and data it would affect. Explain what remains stable, what needs modification and how you would verify the change. Be ready to discuss alternatives during questions.

See the published judging criteria for the full weights. Architecture accounts for 60% of the score. Judges examine problem framing, boundaries, data and state, recovery, tradeoffs, verification and your ability to defend the design. A core journey may be demonstrated through a structured walkthrough or optional prototype.

No. Visual complexity, code volume and feature count earn no points by themselves. A prototype helps when it supports a clear explanation or verifies a decision. A strong architecture submission does not require working code.

Yes. Divide the work as needed, but every member should be able to explain the core flow, important decisions and limitations. Own the design rather than reading a diagram aloud.

The brownie-points section lists the Measure SDK and in-app Gemini integration opportunities. These are optional and separate from the core 100-point rubric. To demonstrate an integration, show actual behavior and explain the evidence; a logo, mock response or mention in a diagram is not a working integration.

Tell an organizer, explain the dependency and show your fallback or intended behavior. Label any mock clearly. Optional integrations should not displace your core architecture work; volunteers should not promise bonus points or substitute requirements.

Sunday, 1 November 2026, 10:00 AM–6:00 PM IST at Paytm, Mumbai. Follow the venue and entry instructions shared by the organizing team. Ask the registration desk if you need help locating the room.

Confirm the submission channel, deadline and presentation time with the organizing team. These details are not specified on this page; volunteers should use the current organizer briefing rather than guess.

Use the participant brief, judging criteria and these FAQs first. Escalate unresolved questions to an organizer, especially those about domain swaps, rule changes, judging, fees or submission extensions. Share confirmed clarifications consistently with affected teams.

Check that the team has its assigned problem, one-page brief, HLD, focused LLD, ADRs and a core/failure/change walkthrough ready to open. ADRs have no fixed count or upper limit. A prototype is optional. Leave architectural evaluation and scoring to the judges.

The organizing team handles those decisions. This FAQ does not authorize exceptions, refunds, extensions or changes to scoring. Ask an organizer for a confirmed answer.