I’d like you to meet Cari
…and some things I learned building it out
Over the past few months, I’ve been spending a chunk of my spare time working on a project that I named Cari, as a homage to my birthplace in the Caribbean. A few things about Cari, and what I learned from building:
First up, what is Cari?
Cari’s goal is to provide a suite of business essentials for micro and small enterprises (MSEs) in emerging markets like my birthplace of Barbados.
While there’s no shortage of SMB tools like QuickBooks and Xero, they often feel overly complex to get started with, even for someone like me with an accounting degree.
Picture a street vendor selling food on weekends to make a bit of extra cash, or a tiny two-person business where one person takes orders and the other handles the work or delivery.
While my goal is to offer a suite of business essentials, I needed to start somewhere, and I chose expense management. I focused on this because, in conversations with MSEs, one theme kept coming up: they often have very little clarity on the overall health of their business.
Many rely on proxies like cash on hand at the end of the day or remaining supplies, but this doesn’t account for bulk purchases or other non-daily factors.
I built the product with extensibility in mind so I could quickly add new use cases in the future, such as appointments, which are predictive, whereas expenses are more historical.
How does it work?
It was important to make access as simple as possible and to go where MSEs already are. As such, Cari functions entirely in WhatsApp. There is no new app to download or website to login to, you simply message Cari to get started and go.
You can send it receipt images, manually log an expense by specifying the details, and request summaries and exports of your transaction history, all using a natural language conversational interface.
I then use a small and cost-effective LLM to convert that message into an API payload that can be processed against the backend, where the necessary data validations and permissions checking can be enforced.
Building out a product on a 3rd party platform where you have limited control over the UI is not without its challenges. My time at Buddy Media (now Salesforce Marketing Cloud) having to navigate Facebook’s ever changing platform policies meant this wasn’t my first exposure to this.
That being said, WhatsApp’s market penetration makes it incredibly attractive for this target segment, if you can get a bit creative with how you execute certain workflows in the product.
Onboarding: Sign-up is done entirely via chat, so I built out a micro-KYC flow that users go through, including providing some basic information about their business. This helps me understand who is using the product, but also enables a potential recommendation engine down the line for improving their business.
Currency & Locale: One benefit of WhatsApp is that your phone number does provide some signals which could be useful, because it ties you back to a country. With the country, I can identify the language and currency you likely want to use.
Billing: Unfortunately, WhatsApp only supports integrated payments in Brazil and India, with no plans for broader rollout. To work around this, I built a flow that sends users to an external payment link, then redirects them back to their WhatsApp chat with Cari once payment is done. Webhooks help me track subscription updates and payment issues, so Cari quickly knows if your subscription lapses 😅.
Exports: I believe in open data, so I added the option for users to export their transaction information anytime, whether for personal use or to share with a bookkeeper they likely already communicate with on WhatsApp. Given the sensitivity of this data, I implemented auto-expiring download links for these CSV exports.
How’d this go?
I could have moved faster
My brain often naturally gravitates to platforms, rather than narrow use cases and my thesis in essence pushed me towards extendability rather than locking down a single use case.
This inevitably slowed me down to start, although I am starting to wonder if the underlying platform components are now more valuable than any specific use case I could build out.
That’s hardly a bad outcome, but potentially pushes me upmarket towards medium businesses looking for more customization rather than an out-of-the-box toolset for MSEs.
I could have learned less
Cari is composed of DevOps tooling that I was not too familiar with when I got started: AWS Lambda Powertools, CloudFormation, Serverless Application Model, etc.
This took so much more time than I expected to get setup, locally on my machine, and then in staging and production environments in the cloud.
Individual components weren’t so bad, but building out a well oiled testing and deployment workflow wasn’t fun, especially as it’s sometimes difficult with AWS to fully develop and test locally.
I learned a lot, but I also could have moved faster with something like a Heroku or Supabase, with potentially less vendor lock-in from AWS.
I should have considered using AI more quickly
Is it weird that this is an AI-enabled product and I initially started building it without using AI at all?
This slowed me down, no doubt about it, especially as a solo builder, but I also think this helped me develop a very strong understanding of the fundamentals and components underpinning Cari because so much of that core code I wrote from scratch.
When I did finally start using AI to accelerate things, I found that knowledge incredibly helpful in how I devised my LLM prompts and instructions, because I could then quickly tell when things were about to go sideways and/or when it was suggesting changes that didn’t make sense given the context I had.
I had to approach testing differently
As I alluded to earlier, Cari is split into 2 main buckets:
The AI layer that assigns a user’s message to a specific workflow and the necessary API request payload.
The backend API that actually has almost no AI magic, it’s a standard REST API and database interface.
This is great as I can write and run tests against either bucket independently, and API testing is much easier than AI testing, so by enforcing validations at the API layer, I can more easily drive data consistency and integrity regardless of what the LLM comes back with (e.g. hallucinations, etc).
It also means I could build a full-featured app or website on top of the API rather quickly, particularly helpful if Meta’s WhatsApp policies change.
This also freed me in how I test the AI components, because I can test a bunch of various messages and just confirm that they convert to the appropriate API payload without needing to always go end-to-end.
Why I did this
Being able to explore projects in depth like this is precisely why my focus is on fractional or part-time work to sustain myself. I readily acknowledge that sometimes it would be so much easier to just go find a full-time job somewhere, but I really enjoy this newfound space to explore during my prime working hours even if it means some opportunities just won’t make sense for me.
You can learn more about Cari here. If you want to chat more about Cari, or if you’re interested in comparing experiences and insights around building, feel free to reach out! I’d love to explore our different approaches, share challenges, and maybe even collaborate on future projects.
P.S. If you’ve never seen Schitt’s Creek, it’s well worth the binge watch. My hubby and I have rewatched it COUNTLESS times.
Love this Jamar. It's fun to see you combining your many talents in such an entrepreneurial way, to help people who need these tools. I also love the Schitt's Creek reference. I have an apron that says, "Fold in the cheese."