Pitch, recap and what's next

Pitch

As we uploaded our pitch video yesterday, we have a moment of relief today and can reflect on the weeks of sheer joy we had building Kumuly Pocket.

As the curtain is falling on the Legends of Lightning vol. 2, we find ourselves at the intersection of excitement and nostalgia. We're elated with what we've accomplished, eagerly anticipating the judges' thoughts, yet a tinge of sadness lingers. The journey has been a rollercoaster of learning, adrenaline rushes, team camaraderie, and countless late-night coding sessions, leaving us yearning for more time to refine, build, and extend our project.

But most of all are we immensely grateful for the opportunity to showcase Kumuly Pocket and learn from the experience that came with it. The Legends of Lightning tournament provided us with a unique space, urging us to share progress, engage with users and actively participate in a space that values innovation and collaboration.

Before we make up the balance of what we wanted and what we were able to achieve, we invite you to watch the result of our journey by watching our pitch video that we proudly present:

We also recommend to have another look at our final Figma prototype to discover all details of what the project entails and at our app's Github repo to see how it has been build so far.

Week by week progress videos of the working app can also be seen on the Youtube playlist: https://www.youtube.com/playlist?list=PLRPUe5cZJyJxj8gnhyJwM5dfHU5KTveKe

Recap

Goals and Principles set from the start

At the inception of our Kumuly Pocket journey, we recognised the challenges that hinder widespread Bitcoin adoption in daily life. The existing hurdles ranged from limited or cumbersome spending options and the struggles with getting merchants to adopt Bitcoin and especially with keeping them engaged, to the difficulty of onboarding no-coiners with non-custodial apps.

Having defined the problems we set out to solve, we defined some basic requirements and principles that we felt were important to do so:

📝 We do not want to custody funds.
📝 We do not want to collect personal data.
📝 The user should not really know the difference between on-chain or Lightning to be able to use the app.
📝 Onboarding should be effortlessly simple.
📝 Becoming a merchant, whether as an individual or a sole proprietorship business, should be a straightforward process without requiring a separate business account or wallet.
📝 Payment experiences should be superior to traditional online shopping, without tedious checkout processes or shopping carts that get abandoned.
📝 The app and systems should be scalable so we can go from only promotions to any product to complete stores and different services.

Implemented in working app

During the weeks of the hackathon, we were able to really implement the following functionalities in a working app for both Android and iOS:

✅ Signup and login with signed messages by embedded Lightning node with Breez SDK.
✅ Non-custodial spending wallet functionalities powered by Breez SDK.
✅ Contact list with chat like feature and UX to add contacts and spontaneously send them sats.
✅ For You tab where promos published by merchants are shown.
✅ Payment flow to enjoy a promo.
✅ Menu with contact ID (node ID), button to switch between Pocket mode and Store mode and with settings to switch between BTC and SAT, to set a local currency and to backup the seed phrase.
✅ Cashier or Point-of-Sale functionality for merchants
✅ Flow to validate and accept or reject a paid promotion as a merchant

Evaluation of achievements

Now lets evaluate if what we implemented met our goals and principles.

We believe Kumuly Pocket with its "For You" tab where users can directly spend sats for promos from different merchants can solve the problem of limited spending options for Bitcoiners in a very user friendly way.

This is of course only true if we can get enough merchants onboard and keep them engaged and selling through the app. We believe that by positioning the app first as a promotional tool to attract Bitcoiners to their businesses, instead of just as a tool to accept Bitcoin, we have a higher chance to achieve this. In the pitch video we also explain why we also think promos are a gentle way to introduce them to receive their first sats, since they can choose the products they are willing to receive sats for in exchange and should not directly accept sats for everything they sell.

We think the onboarding without asking for an email/phone or password, all managed under the hood by signing messages with the embedded Lightning node is a good experience to onboard new users. Also do we not require them to directly write down their seed phrase, which is also a hurdle while onboarding. The user can make the backup himself at any time from the menu, and we will show some notifications and reminders from the time the user has received some sats.

Thanks to Breez SDK, we could also achieve the non-custodial spending wallet, so we do not need to custody funds for the users in Pocket mode. Also when a merchant uses the Cashier/Point-of-Sale functionality, funds will directly go to this same non-custodial wallet.
The only case we are currently not achieving this is for the funds that are received from paying for promos. Since we use a static LNURLpay link per promo, we use an LNbits instance and merchants should withdraw funds received for their promos from this. We tried to make it as easy as possible though with a clear button on the home screen of the merchants to withdraw the funds from promo sales to their pocket. We could in the future even automate this when they open the app or we can use static BOLT12 offers from their Breez SDK wallet so all payments go directly to their pocket. In this last case, we off-course will have the trait-off that their app should be running for users being able to pay for their promos. But we prefer this and be completely non-custodial.

By having a signup and login without email or phone or any other data and because of the promos being redeemable physically at the merchant or by following instructions of the merchant in the info of the promo, we do not need to collect any personal info of the user. We do not even know or record what every user buys, since the payment is done by the non-custodial node and at the moment of validating the promo, we only mark the payment hash as used for that specific promo, we do not know who paid or claimed it. And we also do not need to know this.
The only data we will probably request at some point in time is data to verify a merchant and be able to give more trust and create a business model around merchant verification.

Thanks to Breez SDK we could easily achieve that the user does not need to know about Lightning and the difference with on-chain bitcoin. He does not need to acquire inbound liquidity himself to start receiving and can send and receive from and to on-chain addresses, this is managed automatically by Breez SDK and its LSP.

We think we also achieved to make switching to merchant role or becoming a merchant from an existing account very frictionless. With just one button in the menu, users can quickly switch between their spending wallet and the merchant functionalities. All with just one account and one node and wallet. Perfect for natural person or sole proprietorship businesses.

A promo can be acquired with just three taps: one to open the details of the promo, one to open the confirmation modal and one to confirm the price in sats and make the payment. All of this without needing to enter any information. So we believe we also succeeded in making an effortless payment experience superior to the ones in other e-commerce platforms.

The use of the payment hash to redeem and validate a promo can be easily extended to other types of services like transport or event tickets or to redeem any other product. We also already started structuring the backend data models to be able to support both promos as products as different ways of redemption and delivery of them. And we think that with the lightning authentication, we can also make a Web platform for bigger businesses to manage their stores and even co-workers too. So we think the system is scalable to at some point be used to publish complete stores with all their products and even include delivery options. The UX of the app with customisable category options is already thought out like this and it will be easy to navigate different categories, products and stores.

What's next?

Off-course we would have liked to be able to build more during the hackathon, but we are happy with the achievements and will keep dedicated to continue Kumuly Pocket and hope to launch soon after the hackathon.

Near future

In the weeks after the hackathon we would first like to polish the Pocket mode completely so we can start having test users that can already use the app as their Lightning spending wallet.

Then we will build out the backend to store the info of merchants and promos and to validate promos and integrate this in the app so the parts to create, publish, pay and validate promos are also completely functional.

We will also finish the home of the Store mode with sales numbers and transactions, graphics and analytical data that, for example, tell the merchant how much he has gained or lost compared to if he would have accepted fiat currency instead of Bitcoin for his sales.

For the chat experience we also want to support lightning addresses and on-chain addresses as contact info to spontaneously send to. We also have some more ideas we would like to implement to make this chat-like payment experience better, as we are aware of the current limitations that the app of a contact has to be online to be able to send to it with a keysend. But nothing we feel we can not solve on the end-user app's side.

Mid to long-term Roadmap

In the process we had to prioritise and push back some ideas for others with higher priority, but we have been keeping track of everything and currently have the next items on the Roadmap:

⛏️ Explore Nostr, Slashtags and other open protocols that could remove the need and reliance on our backend system completely. For example, to create and store merchant profiles, promos and product info, to coordinate requesting payments from contacts and to send delivery information directly between user and merchant without having to store data ourselves.
⛏️ Integrate BTC Map to automatically tag merchants on BTC Map and confirm them when they are selling promos, also to make it very easy for users to tag merchants they paid at in sats and to show a BTC Map view in the app.
⛏️ Integrate BOLT12 when available in Breez SDK and replace the LNURLpay link of promos for BOLT12 offers to be completely non-custodial for merchants too.
⛏️ Add filters and settings to search for running promos and registered merchants close to a set location.
⛏️ Add 'Buy bitcoin' functionality with Breez SDK.
⛏️ Add 'Saving bitcoin' functionality by configuring an xpub to easily swap-out to.
⛏️ Use BOLT12 instead of keysend to improve on the chat-like experience.
⛏️ Give more analysis and reporting tools and info to merchants so they can manage their accounting easily.
⛏️ Integrate AI to help merchants enhance their product photos, help write product descriptions and create a logo for their business. Explore TaskTiger for this, since this would already make it possible to pay for those services in sats.
⛏️ Give the option to add co-workers to a business.
⛏️ Program to share in the income of merchants you onboard.
⛏️ Build a web platform for bigger merchants to more easily manage their stores, products and co-workers and they are not limited to one app on one device.

Closing

In closing, we reiterate our gratitude to bolt.fun and the community.
We also commit to uphold the spirit of #BuildInPublic as the hackathon instilled in us, and invite you to continue following our journey, and, hopefully, become a user of Kumuly Pocket in the near future.