From MVP (minimum viable product) to PMF (product market fit) - Designing the tech stack for an early stage startup

Case Context :

A leading pharma company in India with a global presence is planning to engage with consumers directly to provide a holistic experience “beyond the pill”. 

The overall market size is significant with over 50 million patients in India alone.

Solution Envisioned :

A digital platform targeted at consumers and caregivers which will scale across therapies ( starting with one initially ) and geographies ( starting with India ) providing a holistic experience including but not limited to :

1. Education on how to use the medicine delivery mechanism effectively 

1. Scheduling live online sessions with counsellors 

2. Education materials – text / videos etc 

3. Smart connected medical devices

2. Medication scheduling and monitoring with alerts

3. Consumer journey orchestration 

4. Integration, Single Sign On with 3rd party APIs, SDKs 

1. Integration with other medical services eg. Ambulance

5. eCommerce :

1. With portals like 1mg, Pharmeasy etc

2. Shopify or similar functionality 

6. Gamification / Community building

7. Subscription based monetization

Case Study :

As the Engineering Lead of the above platform, based on the above information :

7. Propose a technical architecture for the above proposed platform as we scale from 10k (starting user base) to 1Lac to 1Million users ensuring 

1. Platform to be accessible on Mobile

2. Infrastructure services leveraging AWS components 

3. Analytics including dashboards, business insights and ability to recommend personalized N=1 next best action

4. Micoservices / Monolith - is answered in 14h

8. -x-x-x-

9. Building for a million users from day one is not advisable as the product market fit (PMF) is seldom the same as the minimum viable product (MVP). Hence for fast movement at the initial stages the architecture needs to lean towards agility more than scalability. Hence, I believe prototyping speed must be the top priority for the selected architecture. Once the PMF is achieved the core features can be then optimized for scalability.

10. A 3-tier architecture works well here

1. front end clients - web(angular, vue, react), mobile (generally a hybrid app - ionic, react native, flutter)

2. business logic - REST API - python (flask, django), javascript (express, nextjs)

3. database - arangoDB,  postegres, mongoDB

4. and a caching layer - redis, aerospike, couchDB.. (in most cases, arango / postgres do a good enough job up to a certain scale)

5. a CDN for static assets - S3, (although a small HTTP server serving cached static assets in the same country as the traffic works well up to ~5-6k active users per day)

6. if all the above requirements can be managed in the same programming language that gives the project an additional boost to the development speed, as front-end and back-end developers can be used interchangeably. Disclaimer, the degree of success in interchangeability depends on the training, adaptability and capability of developers. Javascript emerges a clear winner in this regard.
   
   

7. This forms a good starting point for a basic setup that can handle traffic of about 5-6K users per day and still be flexible enough to support rapid development.
   
   

11. The  above architecture is infrastructure agnostic, and can be built out on almost any cloud service provider. - Digital Ocean, Linode, Azure, AWS or a custom one; many emerging players now in the Indian market as well.

12. Once the usage ramps up, application and infrastructure monitoring can help understand the profile of the system load, this is the prerequisite for next steps in scaling. 

13. For a product centric organization - data democracy is a must. ELK (Elasticsearch, Logstash, Kibana) stack can play a dual role. It is well placed for building dashboards for application and infrastructure monitoring and the same can be used for business goals and product metric dashboards as well. So it is generally my first choice.
    But other commercial data visualization platforms are also a fair solution if cost is not an issue; PowerBI, Datadog, NewRelic are also good alternatives. 

1. The selection decision depends more on the management policy - is data analysis going to be the prerogative of the technology team OR there is a data analysis team that is going to build the visualizations ?

2. case 1 - tech team builds and maintains the visualizations - then there are a different category of tools available that are developer friendly and can be used to create visualizations fast.

3. case 2 - data analysts build and maintain the visualization - availability, skill and comfort of the data analysts will determine the choice of the tool. Pushing data to all major data visualization tools is well supported in any backend programming language

4. both cases have their pros and cons - but that is a management discussion and I will refrain from getting into it here

14. What are the specific technology choices :

1. Frontend : Options / Considerations / Recommendation

2. -x-x-x

3. the use cases mentioned above have proven to fit the single page app, progressive web app and mobile app format of front-end very well.

4. For webapps as mentioned in 10a - a modern framework like react, vue, angular would be recommended. The projects have a batteries included philosophy. So basic things like: routing, bundling, minification, etc are all included and configured by default.

5. For the mobile app front-end - a hybrid app framework is recommended as maintaining separate teams and development pipelines for native ios and android development is expensive and cumbersome. For the use cases stated above native performance would not be significantly different. So ionic, react-native and flutter are good candidates for hybrid apps. Keeping the theme of an all javascript stack - flutter is ruled out. The other two - react-native and ionic are very close contenders.

6. wireframe to FE code automation platforms can also be used to reduce the time required by FE developers to build UI

7. Backend ( Microservices / Databases ) : Options / Considerations / Recommendations

8. -x-x-x-

9. as mentioned in 10b - modern web backend frameworks like - django, flask, expressJS, nextJS - include base functionality like - authentication, REST apis, ORM for most database backends, caching, queuing, periodic jobs - out of the box.

10. micro-monilith is a good compromise between the pros and cons for micro services and monoliths. The degree of the mix can be varied by the use case and functionality required. Also, this allows the project to transition from “small and easy to maintain” to “large but modular and de-coupled” very organically.

11. as in 10c - arangoDB / postgresSQL - are great jack of all trades databases and very good for initial stages of development. As the project progresses depending on the use case the project can incorporate specialized database technologies.

12. 3rd Party add ons required ( eg. Marketing automation ) : Options / Considerations / Recommendations

13. -x-x-x-

14. Similar to 13a the architecture would depend on the management policies.

1. If the user engagement is required to be run by the marketing team without dependence on the tech team then 3rd party platforms (webengage, kaleyra, moengage) can be employed.

2. Although a steady state can be achieved in this regard (marketing team having no dependence on tech), but as soon as new features are introduced, the tech team would need to push the new events to the engagement platform. Pushing new events can be automated to a certain extent, but in my experience ends up inundating the automation tool with events and the marketing team ends up confused.

3. if the tech team can be involved - a small project for sending out engagement messages can be setup within the backend. The parts required for implementing this functionality are generally already present in the project for other features:

1. capability to send multi-platform messages (SMS, email, notifications)

2. user activity tracking

3. dashboards for monitoring

4. the only additional feature required is click tracking to complete the loop and many reasonably priced tools are available for this purpose

5. The click data can be imported from the click tracker periodically (say every night)

15. Propose Project Management Processes you will implement 

1. -x-x-x

2. agile development with sprints varying between 1-2 weeks are generally ideal

3. this generally requires good coordination between - product, design and tech teams, so that long term goals (business goals), short term goals (operational issues, bug fixes) and software maintenance tasks can be balanced effectively

16. Propose Release Management Processes you will implement

1. -x-x-x-

2. requirements capture by product 

3. requirements review by tech + product - to ensure no questions were missed

4. requirements to feature conversion by product + design,
   expected output: a PRD + wireframes / a UI prototype

5. design review by tech + QA + product - to ensure none of the requirements were missed and the design assumptions do not create tech issues / utilize the existing tech infa effectively - rather than developing new infra all the time

6. development start - timelines and requirements frozen

7. parallelly QA team builds test cases

8. development complete - code review

9. demo by tech with - product and design - to ensure requirements were faithfully executed

10. QA starts 

11. demo with users for feedback - by product and design

12. QA done - approved for production

13. deployment to production
    
    Bugs, requirement misses, design misses, code review rejections cause the feature to move back in the queue and repeat the previous steps.

17. Propose Testing Processes you will implement 

1. -x-x-x-

2. as in 16e - QA team reviews requirements and points out misses if any

3. before requirement reaches 16h - QA team completes the test cases and gives a timeline

4. test cases include - feature testing and regression test cases

5. automation and manual QA - ideal scenario - the manual testing team is one sprint behind the development team - and all features released are added to the automated regression testing once they are live on production.

18. Application health monitoring plan you will put in place

1. -x-x-x-

2. This is specifically for application health monitoring

3. API monitoring is a good place to start triaging
4. if an API response is fast and within tolerance - well ! ALL IS WELL - don't fix what ain't broke
5. If API response is out of bounds - well then dive deep and fix the bottle necks
6. -x-x-x- there are other monitorings to be considered as well as a project matures:
7. infrastructure, process monitoring
8. pre-emptive crash logging - know your bugs before your users
1. backend, front-end --> use things like sentry, firebase crashlytics to monitor and fix crashes and bugs before they become critical
9. bugs monitoring
1. bug post mortems (root cause analysis) - which miss in the design,requirement, dev, testing, human factor - caused this bug - ?
10. user issues monitoring

19. Team sizing / Skillset needed – Scale up plan

1. -x-x-x-

2. the team size depends on the number of active pipelines that need to be run - which is a management and budget issue

3. the basic unit required for a pipeline is: 1 product manager + 1 designer + 1 front-end dev + 1 backend dev + 1 QA 

4. when scaling up -

5. depending on the project development profile 1 backend developer can serve roughly 2 front end developers

6. 1 project manager can manage up to 3 pipelines

7. the running of multiple pipelines of-course does not scale linearly as more people are required to maintain coordination between multiple pipelines (product managers, architects, etc) and sometimes some functions can be branched out as teams in themselves serving multiple pipelines (dev-ops, QA automation, etc).

20. Data / Information Security / Privacy / GDPR / Compliance including HIPAA, ISO270001

1. -x-x-x-

2. for an early stage product this aspect is economical to be outsourced to an agency

3. Data and information security:
   a regular certification with a reputed player for

1. application penetrations testing

2. network penetration testing

3. application black-box hacking

4. frequency: 6-months - advisable

4. Privacy, GDPR, HIPA, ISO

1. a consultant to work with the software architects and product team to periodically review compliance of new features

2. this can be a full time role as this will need to be done for all new features

21. What Challenges do you anticipate / How will you resolve based on your previous experiences 

1. -x-x-x-

2. My first impression after a quick google search is that this product is the first of its kind in this space hence the product market fit is not known. It will be an exercise in PMF discovery requiring multiple iterations.

3. designing and developing while maintaining compliance is always a challenge, iteration speed and compliance are conflicting requirements.

-x-x-x-

Part-2 

1. <some-app-for-the-pharma-company> app

1. issues observed:

2. why no auto detection of phone number at signup ?

3. dob selector - starting from 1930 - bad UX

4. height - 3 ft 12in ?

5. confusing language to describe relationship

6. next button all of a sudden in the UI feels weird

7. nice animation with the pinwheels 

8. meters + text - for power users

9. weather section did not load

2. app architecture feedback 

1. micro services is not a magic bullet for scaling, it works well if some parts of a system are used more than the others and require more resources. Micro services architecture can help separate various parts of the system and reduce the overhead of scaling.

2. My estimate of the traffic on the app is < 5-10k monthly active users. (A guess I made from the number of reviews and likes on the tips section in a month)

3. this level of traffic even to 100x growth does not need microservices, can easily scale ~1Cr monthly active users with the same (3-layer) architecture with auto scaling or business logic servers and read replicas scaling of the database server.

4. But a good case can be made for micro services when it comes to the dev ops and team management aspects of managing a micro-service architecture.

1. running different teams for each of the planned feature

2. running different development cycles for different feature sets 

3. a replaceable glue-layer for 3rd party integrations 

5. the requirement itself is ripe for micro services architecture - the health data, the diary, reminders, tips and  can readily have their own micro services since there is low interaction of these features with each other. So designing the architecture would be easier.

6. also with the planned functionality in the future - ecommerce, integration with other service providers can clearly be separated out as microservices of their own

3. remote / hybrid team management 

1. been managing a hybrid team size ~15 members quite successfully for 2 years, through various business cycles - hiring, attrition, lay-offs, etc

2. morning huddle - set the work to be done by all reportees - get them to write it out and send out as a message

3. mid-day catch-up - either people confirm that they will be able to deliver the committed tasks or present blockers and get them cleared by a Sr resource / decision maker and the deliverables are revised for the day.

4. EoD call - demo / review for work completed; and TODOs discussion for the next day (this forms the basis of the morning update the next day)

5. the culture of push updates - reporting as soon as an impediment to the committed timeline is found and not waiting for the next catchup.

6. 1-1 catchups with reportees once a month to align their goals and the company goals

-x-x-x-x-
Fun fact:

- None of the interviewers has read this essay that I wrote in response to the case study 🤦
- I was rejected for this position.