The problem Shoptik solves

This product has been developed for both Corona stricken and the post-pandemic world where hygiene and social distancing will be of utmost concern. Shoptik is a simple solution backed with blockchain to ensure the safety of citizens on their trips to buy essentials and hence lowers the risk factor when they go out.

Customers can book a time slot on the day when they decide to go to a shop in their locale, every shop has a hold limit to ensure social distancing while the customers are shopping. The customers then receive a QRcode via email(also accessible via the web-application) that will be scanned on entering the shop premises as well as billing to ensure exit before the time-slot ends. More-over the application lets customers view the availability of essential goods at a shop before booking the slot and the shopkeepers can also tailor their purchase accordingly. The most interesting part of this process is the tracking of people without violating their privacy unlike established apps such as Aarogya Setu, Shoptik allows admins appointed by the government to track the shops that a customer has been to upon being tested positive, and acquire the information of customers who were possibly exposed due to sharing a shopping slot with the carrier.

To ensure that the shops follow the guidelines of social distancing there is a "report shop" feature in the application, so customers can report a shop if they find more people than the allowed safe limit per slot or any other malpractices that endanger the shoppers, which will reduce vulnerability on weekends and holidays.

Shoptik can be extended by implementing batch transactions to handle simultaneous requests while inserting into the blockchain. The intimation about the slot booked can be synced to google calendar, to remind the customers about the start and end of their booked slots. Further KIOSK stations can be set up around the locale to facilitate the availability of services to all.

Challenges we ran into

One particular problem that we faced was the amount of hardcoding involved. Every node needed an address, the contract details and the network id of the chain. Since the number of nodes is dynamic, ( shopkeepers can register), we faced a lot of problems with hardcoding all details with respect to a node.
We isolated the problem in the initial stages of development when deploying contracts to the chain. However, this severely impacted our testing phase since getting keys from ganache - CLI and pasting manually for every run was time-consuming.
We solved this problem by externalising configuration completely with respect to both contract and keys.
For deterministic key generation, we fixated on a mnemonic and initialised our chain with the mnemonic every time we restarted the chain.
We wrote wrapper bash scripts for "build" and "run" that take care of contract deployment.
Another problem we ran into while debugging was that the contracts weren't getting deployed properly. It was a minor bug (the account was not unlocked properly ) but we stress it here because the error messages out of Web3.py are "vague", so to say and with every new update to the package, existing code breaks. We had to spend time digging through the docs.
There were deployment problems. We deployed backend and frontend in separate environments (in separate repositories as well) and automated deployment to Heroku. As a team, this was our first ever attempt on Continuous Integration and it came up with problems on its own. We had to write scripts that give successful builds before actually deploying.
Further, while deploying the backend, we had problems configuring the mail server. We had to change port numbers and disable TLS for it to work. Furthermore, these problems were deployment server specific - gunicorn and uwsgi both gave different errors for the same mail server configuration. We had to fixate on one and solve the errors.
It was a roller coaster journey with lots of fun :D