App platform for a startup

Background

The startup has a physical business that provides a premium service to clients in their own homes. They wanted to expand by creating a new online platform with two apps: the Provider App would help independent service-providers easily manage their businesses; and, the Client App would allow clients to easily schedule in-home services with their providers. Additionally, the platform would automatically optimize various aspects of providers’ operations.

Their initial development team built a prototype by integrating existing 3rd-party services. After 22 months, it still had minimal functionality. Clients could book appointments, but with no regard for drivability, let alone route optimization. Providers could charge manually-entered payments, but they passed directly through to the payment processor leaving no records on the platform. Some important information still used hard-coded demo values. The platform had never been used by real providers or clients.

This is the stage that David joined the team.

From prototype to product

The project had started with the intent of providing all features by only gluing together existing 3rd-party services. That had proven infeasible.

For example, the 3rd-party calendaring service lacked essential features. The prototype had started to make up for that by keeping its own database of information for each appointment, but this would become inconsistent with the calendaring service.

David addressed this by first fixing the consistency problem to eliminate bugs. Then, he added fields to the local database to cache all details about each appointment. Finally, he removed the dependency on the calendaring service entirely, relying only on the platform’s own database. This allowed David to easily add features, such as accounting for driving time between appointments and route optimization.

David also added other important business features, like client reports, revenue history, in-app messaging, and proper payment handling.

Improving performance

The prototype was slow in several areas. One of the worst was the providers’ daily overview. The back-end would hit 3rd-party services 3 times serially, perform O(N) database queries, and loop O(N²) times. It would take over a minute for normal use.

In addition to removing dependencies on the 3rd-parties, David rewrote the logic to perform only one database query and have no looping. Generating the overview now completes in under a second.

David also addressed dozens of other performance issues, making the apps feel snappy.

Fixing data bugs

The project was continually plagued with errors about what data existed and how to access it. Most data was passed and stored as JSON blobs, and the apps were inconsistent about what data was stored and by what names. For example, one part of the front-end might store a phone_number, while another part might store and read a phonenumber.

David fixed this by gradually adding more structure to the data along with type-checking. How migrated important bits out of the JSON blobs and into proper database fields with consistency checks. He rewrote API endpoints to use named structures with field validation, which also supported generating and OpenAPI schema. He added tooling to the apps to import that schema to produce Javascript interfaces for each endpoint. Finally, he converted the apps to Typescript and added type-annotations to both them and the Django back-end.

The new approach not only prevents new data bugs, but also identified several undiscovered bugs along the way.

Product design, vision

The platform was initially conceived as a two-sided marketplace, where clients would search for nearby providers, as well as a platform for providers to manage their appointments. However, we were targeting a market with premium services offered by trusted providers who had established relationships with clients, so clients wouldn’t normally go looking for a new provider—they’d use the one they’d been using.

This caused unnecessary effort to be spent on supporting search, which wasn’t even functional yet. Additionally, there were no strong, well-defined use-cases to drive priorities, so new features were regularly added to the backlog because they sounded good.

David pushed really hard to on-board a single provider as soon as possible. The provider would be hand-picked by the owners, and someone they had worked with in the profession.

He regularly repeated the question, “what’s essential for us to do to on-board provider #1, knowing we’ll be able to do a lot of hand-holding?” David also pushed for and helped run customer interviews with other providers. Throughout this, he helped make decisions about what features to implement, how they should work, and how they should be prioritized.

This relentless focus helped the whole team gain clarity and establish priorities. The search feature was removed entirely, and essential features added to prepare for launch. The team got valuable, real-world feedback from provider #1 and the other providers they interviewed.