Home

Case Study: Shudi Mobile App

Published 10/08/2018

Problem

What was the problem to be solved?

Matt is an active duty serviceman and entrepreneur who created an idea to crowdsource decision making via a social platform.

The idea was to allow users to post simple, binary items such as “Which one should I get for lunch?”, including a photo of each item.

The app alerts other Shudi users about the post and places it in a global feed for all users to see.

Users can then vote for which option they suggest and comment to tell the creator why they voted the way they did.

Solution

What was the proposed solution?

Working with a tight budget, we approached this project from a standpoint of “What is the minimum viable project that is fun, useful and exhibits the potential of the app?”

We encouraged Matt to look at this as a showcase prototype that we could take to investors who could provide the resources needed to expand Shudi into mass adoption.

This meant prioritizing features based on impact and simplicity. Anything that wasn’t core to the idea and required a lot of time was pushed to future development.

Challenges

What challenges arose during the project?

First, Matt had a small budget – which was no fault of his.

Unfortunately, he original had taken his idea overseas for outsourced development.

As is almost always the case, this didn’t end well as Matt exhausted most of his budget and got back a non-functional app.

We examined the code and nearly all of it was not reusable.

As mentioned, we solved this problem by focusing on an MVP and also by moving from Swift to React Native which allowed for more rapid development.

Second, Matt was deployed in South Korea, so communication was almost non-existent.

To solve this problem, we laid out a detailed roadmap after the research sprint and provided him recorded, video demos after each sprint.

Finally, we were on a compressed timeline as competitors such as Facebook and Instagram appeared to be entering the market.

React Native helped here as well because it allowed us to simultaneously build the Android and iOS apps.

Technical

What was the technical approach to the project?

As touched upon, React Native was the backbone of our stack choice.

Specifically, we chose Apollo with GraphQL for our API bridge and Material Design as our design framework.

We built out the supporting backend using a plethora of AWS technologies, including Mobile Hub (for configuration management), AppSync (for API Management), DynamoDB (for data management), Lambda (for task management), Pinpoint (for analytics management), SNS/SES (for syndication management), Cognito (for authentication and account management) and more.

Management

What was the project management approach to the project?

Using Agile Scrum, we took an iterative approach to this project with a team consisting of a back-end engineer, frontend engineer, a designer and a project manager.

Matt had previously had screens mocked up for Shudi, but those needed to be revised.

Because communication was difficult, we were left to our own assumptions a lot of the time, so we started with a two-week research sprint, followed by two feature sprints, a bug sprint and then two feature sprints until the project was completed.

Lessons

What did you learn from working on this project?

We learned a lot about AWS Cognito during this project – specifically, integrating it with callback hooks during registration to validate certain things about the sign up.

We had custom parameters that needed to be checked that weren’t a standard part of Cognito, so we had to implement custom logic in Lambda and hook it into the registration process.

Why Gunner?

Why was Gunner selected for this project?

Gunner had the unique ability to focus on what was important to manage budget and time constraints while still creating a fun application which definitely highlights Shudi’s potential.

Gunner provided valuable business process insights as well, helping to create a plan to get from prototype to investment.

Architectural Description

What platform was built for this project?

We chose a serverless architecture because it provides the perfect combination of scalability and cost.

As this was a new product, we knew that initial usage would be very low and we were working with a near non-existent hosting budget, so a traditional, redundant, fault-tolerant architecture was unrealistic and wasteful.

However, using serverless with AWS allowed for us to create a setup that will scale infinitely and immediately with no additional changes need from us. The cost will increase with usage, but at that point, the app will be generating revenue.

In the meantime, the setup runs itself for less than $15 a month.