PadelMatch: Rearchitect, Redesign and Ship

First look

Before we begin, it is important to mention that PadelMatch was in an MVP state, where it could convey the basic idea of the app and the feature pool but a vast majorty of the code was in disarray, which stemmed out of poor architectural and coding decisions. The most visible issues from a developer's perspective was that it was built on Firebase, a hard dependency. Firebase's out-of-the-box offerings were being used for everything. Nevertheless, the problem didn't lie in using Firebase alone, it being a fairly common and decent tool to get your app up and running, swiftly. The actual issues lied in its inaccurate implementation in code and not choosing the correct systems with scale in mind, for example, an established backend framework with a dedicated database, instead of firebase, especially because it is the kind of app that gains traction very fast.

Building the app the fastest way possible gave rise to violation of best coding practices in 90% of the code, waiting to become a maintainability nightmare, for example,

1. no clear architecture in place, either for coding or for design
2. api calls being made without using the global api client
3. directly manipulating db records without using api methods
4. redundant code everywhere; unused functions, pointless comments etc.
5. absence of proper error handling made for bad UX

The Constraints

Team size: The team consisted of 3 people from Essentia.dev: an SDE1, the head of Engineering and the founder.

Timeline: The project lasted 4 months (December-March).

Stack: React Native, Typescript, Django, AppStore

Scope of services: The team from Essentia collectively provided app development, system architecting and consultation.

Our Services

During the course of this project, Essentia's team delivered on 3 fronts, namely, Consultation, System Architecting and App Development & Distribution.

To these ends, what stayed as a persistant step was holding regular meetings with the client (in pre-decided slots every week) to:

• share the latest updates on previous tasks
• brainstorm and plan new features
• decide timelines for individual tasks

Moreover, the developmental process was divided into three main phases:

Phase 1: New backend, Distribution on TestFlight and App-store(December-January)

We accomplished this in 3 steps :

1. Understand and document the current architecture of the app(included Pages and Components in the Client, APIs and API integrations in the client). This step was perhaps the most important one in the whole process, as it demanded us to documentthe behaviour of the components in the most accurate form, for later reference during development.
2. Build a custom backend with Django and Postgres, then silently replace the existing firebase-integrations with the Django Rest APIs, based on the document prepared and validated in step 1(above).
3. Help the client setup a developer account on AppStore, then take the reigns for make it avaible on test-flight and eventually applied for distribution on App Store.

This phase's outcome was the MVP version of the app being deployed to TestFlight with a stable, fault tolerant and auditable backend system.

Phase 2: UI-UX redesign (February)

This phase's focus was on:

1. Creating a comprehensive UI-UX design
2. Prototyping all the current user-flows
3. Brainstorming about and prototyping all the possible user-flows of the future. This included heavy consultation with the client to incorporate their Founding vision with our terchnical expertise and decade-long experience in the field. This whole exercise gave birth to a set of enticing new features.

At the end of this phase, we had a figma file with all the prototypes for a subsequent overhaul UI-UX

Phase 3: UI-UX overhaul (March)

During this phase we used the prototypes developed in Phase 2 to overhaul the existing design and distribute V1.1 on the App Store.