Crowd-sourced verification of Covid19 resources — Coverify.in
Building a centralized system for covid19 resource leads, co-verified by the people: coverify.in
During the second wave in India, there was a spike in the number of covid19 infections, with number of cases exceeding 400,000 per day at the peak (Source: Google). The sudden increase tested the various systems in place — hospital capacity, access to valuable resources, mental support, etc. Having heard of the ground situation from friends and the news media, for the Indians living outside of India, this was plain-scary — being thousands of miles away and helpless, if a loved one got sick. Donating to NGOs and groups helping on the ground was a start, but many of us felt a strong need to do more, directly or indirectly, to help or assuage the situation.
A group of us saw a few solutions: making verified resources accessible to people, volunteers providing mental and emotional support for anyone affected greatly by the pandemic.
In this story, I recount my experience of launching the coverify initiative together with a talented and a hardworking group of volunteers.
Coming together
In 2021, social media platforms are powerful tools. A friend shared (and re-shared) a story on Instagram calling for volunteers who wanted to get together to come up with potential solutions. Interested individuals replied and quick a Discord channel was set up for communication.
After a couple of online meetings, we quickly realized that there is a lack of verified information about Covid19 resources. Solutions existed that addressed this need, however, many of them were either constrained to certain cities or the resource list was not exhaustive. A quick study on the existing solutions led us to the following points:
1. How do we access and verify large amounts of data (contacts)?
2. How do we make it accessible to tier-2 and tier-3 cities (and at a later point, towns and villages)?
3. How do we keep this information updated over time?
A few of the existing initiatives banked on volunteers for verification — calling various contacts in a city and marking them as valid or not. An issue with this route is scaling to multiple cities. Many of the of the volunteer groups existed for larger cities. For smaller cities, towns and villages, it is much harder to pool such resources. Non-centralized resources also mean it is harder to track whether a vendor has run out of some resource. Having volunteers call and re-call these contacts works, but it is time consuming.
There was a need for a central platform for accessing information — with crowd-sourced verification. It hinges upon people helping themselves and others. In addition, volunteers from NGOs would get a privileged access to update the leads.
Backend and Frontend
We envisioned a self-correcting backend that was driven by people updating the contacts for resources in various location, with NGOs (and volunteers) updating the contacts from time to time. After an initial discussion, we decided not to use Firebase, despite its simplicity in setting up a database and a backend. With a custom backend hosted on AWS, we had more control: providing privileged access to NGOs, sorting contacts based on recent information, blocking spam requests from some ips, reporting malicious/invalid resource leads etc. We used a variation of the RFD (recency, frequency, duration) method to keep track of the latest contacts.
In less than 48 hours after initial discussion, the team provided the first version of the backend. Something that was surprising and commendable about was everyone’s professionalism: there was a open API documentation available for the system, rigorous testing was being done, the use of communication channels (all were volunteers putting in effort outside work hours). Compared to this, my company recently worked with a software development company who basically ripped us off with very unstable systems (refer my post: Bad developers are everywhere).
With the frontend, we envisioned native applications at the start. Partly because of the control we get — making a phonecall directly from the app, using call statistics to prevent people from making making unwanted edits, etc, and party because of the limited app developers we had access to. With an initial proof-of-concept of the app using flutter, we went ahead with the plan. Flutter’s added advantage is maintaining a single codebase for iOS and Android.
Fortunately, one person in the team was a designer. Based on the message we wanted to convey, a design was made on Figma for the coverify website and the app. Over the next few days, we put in all our resources into populating a database, reaching out to NGOs for collaborations and building the app (link: https://github.com/akashrajkn/coverify).
Road blocks
One of first things we realized is that many groups had already started initiatives similar to coverify.in without a central database for all cities. Instead of reinventing the wheel, we reached out to a few of the initiatives in the hopes of collaboration. However, not many of them had an open API to access data. Some of them were even reluctant to share this data — since they had spent resources gathering this data.
While we concentrated our efforts in this area, we hit a road block with publishing the app on Play store (review times were much longer since the pandemic started). A related issue was unavailability of a mac to build and test the app on an iPhone. In retrospect, this should have been a launch blocker since the start, however, with the speed with which we developed and limited resources, it was overlooked.
Quickly, we moved to building a web app using React.js. Since the backend was ready, we delayed the launch by a few days. With the web app, while some features were not optimal (calling directly, accessing contacts on iOS), it was convenient for the people to use it — opening a url on the browser vs installing via app/play stores.
Roles and management
During the whole process, two aspects stood out for me: communication and trust. We were all volunteers working towards a common goal — we respected each other’s time, while trusting deliverables. We had daily quick meetings (sort of a standup) to keep progress checks on various fronts, help each other out, and design a plan.
Two aspects stood out for me: communication and trust
After a couple of weeks of work, we did a soft launch with a few NGO volunteers, friends and family. (Coverify is a not-for-profit initiative.)
