Super-charged Growth: MTU (Monthly Transacting Users)
Ideas and solutions that create quick growth opportunities to bring in more new users across SouthEast Asia, and have significant impact on the flywheel of Grab across one or more ecosystem services.
Consumer Candy (aka Engagement): MEU (Monthly Engaged Users)
Solutions that keep our users attracted and coming back to our app and services, with a focus on creating sticky, engaging and delightful app experiences.
Strategic spaces: Powering social commerce, encouraging group shopping,spending and financial habits, creative lifecycle gamification
Golden Faithfuls (aka Loyalty): Retention
Solutions which encourage repeat users to get into a long-term relationship with Grab through their lifetime, and drive their loyalty to the Grab platform. “The more you Grab the better it gets”
Strategic spaces: Building on user’s value and identity within Grab, personalisation, loyalty program improvements
Platformers: Shared Code, Engg Stability & Velocity
“Build once, reuse across teams''. Platformised Solutions that solve multiple problem statements across teams.
Strategic spaces: Emphasising focus on building reusable platforms and frameworks that increase collaboration across engineering, data engineering and data science teams
GrabForGood: Philanthropy and GrabForGood
“What is now proved was once only imagined.” – William Blake. Philanthropy related solutions that help bring solutions to the people affected by COVID (or any equivalent use case).
Pre Hackathon Schedule
Registrations Open
Grabathon Day 1 ( 16 September 2021) - WIP
Grabathon Day 2 ( 17 September 2021) - WIP
Grabathon Day 3 ( 18 September 2021) - WIP
Award for winners
Prizes
WIP
awards per theme (winner & runner-up)
WIP
special category awards
Panel
Judges Scorecard
- WIP
- WIP
- WIP
- WIP
- WIP
- WIP
- WIP
- WIP
Resources
Developer Resources
Rules & Regulation
Developer Rules
- All teams should be as 'inclusive' as possible. The recommended team size is 6: 1 from Business, 1 from product, 1 from frontend/fullstack, 2 from backend, 1 from QA
- The maximum team size is 10 members.
-
iOS and Android
- Create branches with name grabathon-9-[team-name]
- Push code to this branch
- Deploy using IPA/APK or Xcode/Studio using debug mode on the simulator or test devices
- Backend changes can be deployed to staging and no changes will be required to access the same or it can be mocked locally on a laptop
-
Flutter
- Apps written fully in flutter:
- Create branches with name grabathon-9-[team-name]
- Add new folder in apps directory
- Push code to this branch
- Build and deploy using flutter tooling
- Native apps with flutter as a module:
- Create branches with name grabathon-9-[team-name]
- Add new folder in flutter_pax directory
- Push code to this branch
- Build and deploy using XCode/Studio as native app
- Apps written fully in flutter:
-
Backend:
- Teams can build a mock backend server on a laptop within your team and ask the mobile engineers to integrate with the same
- Teams can also merge your code to a custom hackathon branch (with name grabathon-9-[team-name]).
- It is recommended that teams deploy on staging for demo + presentation:
-
They would need to format their service name as "gh-[team_name]-[service_number]" and tag G9-{teamname} and tag_aws_cost_center_grabathon9.
E.g. As team "Hackathon Geeks", if I want to deploy 2 services on staging for the hackathon:
Service 1: gh-hg-one
Service 2: gh-hg-two
Note: GFG has a strict limitation of maximum 10 characters in the service name. The staging deployment format for GFG would be
"g9-[first_5_chars_of_team_name]-[service_number]" -
They would need to deploy on their existing staging infrastructure with the right service names.
In case of any queries / approvals during the hackathon, please reach out to @anshu.prateek (GFG) and @althaf.hameez (non-GFG).
-
They would need to format their service name as "gh-[team_name]-[service_number]" and tag G9-{teamname} and tag_aws_cost_center_grabathon9.
FAQs
-
Q. Do I need to have an idea to register a team?
A: No, please register your teams, and all the problem statements will be made available to everyone on 06th Sept. -
Q. Do I absolutely need to submit a problem statement that I could potentially solve?
A: Yes, all problem statements will need to be submitted at go/grabathon-9-idea, even if you are not going to work on it. -
Q. What is the process of filtering problem statements, and why do we have it?
A: It is NOT a filtration process, but rather a verification process to address 3 things:
- Each problem statement has enough information so it is 'hackable'.
- The problem statements are not hacked in silos, i.e. they are made available for everyone so that it is an even ground to start hacking, and innovation is in the way the problem statement is solved.
- Each idea 'sufficiently covers the themes and judging criteria' mentioned in hackathon.grab.com/9.0/.
-
Q. If my submitted problem statement does not pass the filtration/verification process, does that
mean I/any team cannot work on it?
A: No, teams can work on any of the submitted problem statements, verified or otherwise. However, the organising committee advises but does not enforce, teams to work on the verified problem statement. -
Q. Are all problem statements visible to all teams before and during the hackathon?
A: Yes — check them out here!. -
Q. Can I work on a problem statement that is not part of the submitted list?
A: Yes, but is MANDATORY to submit your problem statement at go/grabathon-9-idea. -
Q. Can I keep a problem statement to myself, and hack? I am sure this is a winning problem
statement.
A: As mentioned in FAQ-5, it is mandatory to submit the problem statement that you are going to solve, before hacking on it. -
Q. What if my team has only a few members, can I still participate?
A: Yes, however the recommended team size is 6, and as inclusive as possible (1 business, 1 product, 2 backend engg, 1 fullstack/frontend engg, 1 QA), and the maximum team size is 10.