The problem CryptoCab solves

The right time in the market for a dapp would be when it does not feel like a dapp, but a simple app.
With the combination of account abstracted accounts, zero-knowledge proofs for validating our users, deployed on blockchain that supports high throughput, and persistent storage to store the data that is vital to the application's running, we're powering our decentralized ride-hailing application that can be used by everyday users to get their rides for a cheaper price since there is no middle-man to take a cut.
Currently, we have options like Uber, and Ola, and decentralized options like Drife, the centralized applications still suffer from surge fees, data ownership, almost unreadable terms and conditions, and a big cut to the corporations.
The decentralized applications till now offer better pricing but at the cost of the tiring process of signing messages via mobile wallets, having to do on-ramp, and off-ramp hassles, and an incentive-based model that always includes a separate coin launch for the funding of the product, that is completely unrelated to the in-app currency being used.

In all, CryptoCab is a decentralized protocol that helps its users find rides, and drivers find customers on-chain.
The smart contracts have been designed keeping in mind that the user/driver might want to use a different protocol for the same purpose as well, so the contracts let its users/drivers authorize being routed new rides from other escrow(cryptocab) contracts as well.

Challenges we ran into

The design of the product was a breeze in itself, but as we started building it, we realized that the SDKs we wanted to use from the event did not support the blockchain we wanted to deploy our contracts on.
We found a replacement for the SDK (Account abstraction) and went on designing the flow, and contracts.
After this, libraries of multiple sponsors had bugs that the devrels helped in solving.
For one of the sponsors, the doc link was not updated.
Our implementation for the zero-knowledge integration in the product required us to have some endpoints that were not available in most sdks, so we had to do the task in parallel with the web3Auth itself.