The client needed help building mobile products on an accelerated timeframe

OVERVIEW

Sphere was asked to build a mobile application that allows employees to pay for a taxi using a corporate account.  The goal was to build a MVP within 3 months that shares 90%+ or more of the code between iOS and Android as well as important structural commonalities between mobile and web versions

TEAM

For the MVP, the Sphere team included three developers, one designer, and two shared QA analysts.  

APPROACH

The client’s requirements were quite fluid. Features were added and subtracted with each sprint. However, the basic flow of the project followed an agile test/release process.

  1. Business requirements received
  2. Designer creates mock-ups
  3. Mock-ups discussed and reviewed and revised internally
  4. Client approves designs or another round of adjustments takes place
  5. Development
  6. QA
  7. Wash, rinse, repeat

Within that deadline, bi-weekly sprints kept the team on a rapid release schedule. The team used Slack and Jira with bi-weekly sprints. In person and video meetings occurred on a regular basis to keep the team connected.

TECHNOLOGIES USED

For fast prototype creation against an accelerated timeline and to preserve a common code-base across iOS, Android, and web, React Native was used for Android, and iOS while Ruby on Rails was used for the backend. In addition, other tools used included:

  • Jira
  • Zeplin
  • GitHub
  • Overflow
  • Codeclimate
  • Airbrake

Deciding on a tech stack for this project was not easy since requirements were flexible and the end state was not well documented. The team recognized that the limitations of standard mobile development approaches (Swift – iOS, Java – Android) would not work given the constraints of budget and timeframe.

A cross-platform approach was required. With React native and React.js using JavaScript under the hood, mobile developers were able to reverse-engineer the existing web app to better understand the feature logic and how it should work. React Native was selected because it allowed a single codebase and reuse for multiple platforms – making it less expensive to create and maintain apps for iOS and Android.

OUTCOME

A  MVP was completed within the three-month deadline.  The MVP was released for internal use. Testing followed, and then after acceptance testing, the app was made available publicly.   So far, the app is responsible for 20% of all orders on the platform. This number is growing every week.

Understand the trade-offs of technical debt

How do you strike the right balance between feature development and the handling of technical debt? New white paper now available.

Talk to the team that worked on this project

Related Case Studies & Resources

Flutter mobile SDK: Pros & Cons

Flutter mobile SDK: Pros & Cons

By Artem Gordeev The Flutter mobile SDK was created by Google for creating cross-platform mobile apps and it also has some other powerful capabilities. This article offers an in-depth look at Flutter’s advantages and disadvantages, its usage of Dart as the main...

read more
Continuity of User Experience – Case Study

Continuity of User Experience – Case Study

Founded in 2010, 90Seconds is a video authoring platform that simplifies the complexity of video production, connecting brands to freelance creators through a simple, streamlined workflow. User experience background 90Seconds has three key user roles in...

read more

Introducing Jira Software 8.0

Jira Software 8.0 is the next chapter of Jira for enterprise teams, harnessing a speedy new engine built for scale. With this release, Jira users will be able to communicate updates and priorities more clearly, while system administrators will find it easier and less...

read more
Case Study: Loan Approval Workflow

Case Study: Loan Approval Workflow

CreditNinja is a fast-growing web loan application and approval service. It requires a loan approval workflow and high-quality solutions and fast code delivery to keep rapid development. 3rd party services needed to be efficiently integrated in order to fetch and...

read more
Case Study: Develop End-User Portal using Microservices

Case Study: Develop End-User Portal using Microservices

OVERVIEW A financial services company wanted to rapidly develop a transactional portal for storing customer financial data and make the data available to customer service personnel. PROBLEMS / CHALLENGESThe organization had made significant investments in its digital...

read more

Previous

Next