SendSasa

WhatsApp-Native Financial Operating System for Africa

[Duclair Fopa ♈ @BlockchainMonk_]

Most apps only store the current state.

Balance: XAF 15,000. Tomorrow it's XAF 30,000. You update the record. Fine for most apps.

But for fintech, banking, inventory, logistics, trading platforms, hospital systems, storing only the current state isn't enough.

Because the real question isn't "what's the balance now?" It's "how did it get here?"

That's where event sourcing comes in.

𝗘𝘃𝗲𝗻𝘁 𝘀𝗼𝘂𝗿𝗰𝗶𝗻𝗴: 𝘀𝘁𝗼𝗿𝗲 𝘁𝗵𝗲 𝘀𝘁𝗼𝗿𝘆, 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝘁𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁.

Instead of storing "balance: XAF 30,000," you store: account created → XAF 50,000 deposited → XAF 20,000 withdrawn. Add it all up, and you get XAF 30,000.

Think of El Clásico. Ask who won, someone says "Barcelona demolished Real Madrid, 4–0." 😄 (@10Ronaldinho is why I fell in love with this club.) That's current state.

Event sourcing is minute-by-minute: goal at 12', goal at 38', goal at 61', goal at 85', Madrid never even got a shot on target. Now you know exactly how the beatdown happened, not just the final score.

When a customer asks "why did my balance drop?" you don't guess. You check the events. Money in here, transfer out there, fee deducted here, reversal there. Your system has memory, not vibes.

𝗖𝗤𝗥𝗦: 𝘀𝘁𝗼𝗽 𝗳𝗼𝗿𝗰𝗶𝗻𝗴 𝗿𝗲𝗮𝗱𝘀 𝗮𝗻𝗱 𝘄𝗿𝗶𝘁𝗲𝘀 𝘁𝗼 𝘀𝗵𝗮𝗿𝗲 𝗮 𝗺𝗼𝗱𝗲𝗹.

Command Query Responsibility Segregation. Big name, simple idea: separate the side that writes data from the side that reads it.

Commands are actions — create account, place order, send money, approve loan. They need validation, business rules, security, consistency.

Queries are questions — get balance, fetch order history, show dashboard. They need speed, filtering, search.

Small apps can use one model for both. Fine. But at scale, forcing reads and writes into the same structure just slows everything down.

It's a kitchen and a serving counter. The kitchen (writes) is where the strict, careful work happens. The counter (reads) is where customers grab what they need, fast. Force everyone through the kitchen, and the whole place backs up.

𝗖𝗼𝗺𝗯𝗶𝗻𝗲 𝘁𝗵𝗲𝗺, 𝗮𝗻𝗱 𝘁𝗵𝗶𝗻𝗴𝘀 ����𝗲𝘁 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴.

Write side stores events: order placed → payment received → order packed → shipped → delivered.

Read side builds different views from the same events: a customer sees "your order is on the way," admin sees "243 orders shipped today," finance sees "XAF 18M received this week," logistics sees "27 packages pending."

Same events. Different views. That's the power.

But don't misuse this.

Don't bring event sourcing and CQRS to a to-do app. If your system just needs create, read, update, delete — plain CRUD is enough. Use it and sleep well.

The skill isn't knowing these patterns exist. It's knowing when they actually earn their complexity.

Where's the line for you, when does a system stop being "CRUD is fine" and start needing its full history?

[Duclair Fopa ♈ @BlockchainMonk_]

Every startup has that one dependency that, if it goes down, takes the whole product with it.

One payment provider. One AI API. One SMS gateway. One email service. One cloud storage. One npm package installed because @StackOverflow said so.

Everything works. The demo is smooth. Investors clap.

Two weeks later: the SMS provider goes down. The payment webhook starts delaying. The AI API returns garbage. The email provider blocks your domain. That npm package gets compromised. Cloud storage says "degraded performance."

Degraded performance for them. Cardiac arrest for you.

That's the moment you realize: your architecture was never a system. It was a prayer request.

If one dependency going down can send your entire product to the grave, you didn't integrate a service, you married your destiny to another company's uptime. That's not partnership. That's technical bondage.

𝗛𝗼𝘄 𝘁𝗼 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗯𝘂𝗶𝗹𝗱 𝗳𝗼𝗿 𝗶𝘁:

𝟭. 𝗗𝗲𝘀𝗶𝗴𝗻 𝘄𝗶𝘁𝗵 𝗳𝗮𝗶𝗹𝘂𝗿𝗲 𝗶𝗻 𝗺𝗶𝗻𝗱
Every dependency can fail, payment provider, AI model, Redis, database, email. Treat failure handling as part of the product, not an afterthought.

𝟮. 𝗜𝘀𝗼𝗹𝗮𝘁𝗲 𝗲𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀
Don't let a vendor's SDK scatter through your entire codebase. Build your own wrapper, a payment service, an email service, an AI provider service. Your app talks to your interface; your interface talks to the vendor. If the provider fails you tomorrow, you swap the wrapper. You don't rewrite the company.

𝟯. 𝗧𝗶𝗺𝗲𝗼𝘂𝘁𝘀, 𝗿𝗲𝘁𝗿𝗶𝗲𝘀, 𝗰𝗶𝗿𝗰𝘂𝗶𝘁 𝗯𝗿𝗲𝗮𝗸𝗲𝗿𝘀
Non-negotiable for anything you don't control.

𝟰. 𝗤𝘂𝗲𝘂𝗲 𝗲𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝘄𝗼𝗿𝗸
Sending email, SMS, or a slow job? Accept the request, store the state, process in the background, retry when needed. Your user's experience shouldn't collapse because a vendor is slow.

𝟱. 𝗠𝗮𝗸𝗲 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀 𝗶𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁
If the same operation runs twice, it shouldn't cause double damage. Period.

𝟲. 𝗙𝗮𝗹𝗹𝗯𝗮𝗰𝗸𝘀 𝗮𝗻𝗱 𝗴𝗿𝗮𝗰𝗲𝗳𝘂𝗹 𝗱𝗲𝗴𝗿𝗮𝗱𝗮𝘁𝗶𝗼𝗻
Always have one. Always.

𝟳. 𝗠𝗼𝗻𝗶𝘁𝗼𝗿 𝘆𝗼𝘂𝗿 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀
Track latency, error rates, timeout rates. Your system should know a vendor is sick before your users tell you on Twitter.

𝟴. 𝗣𝗿𝗼𝘁𝗲𝗰𝘁 𝗮𝗴𝗮𝗶𝗻𝘀𝘁 𝗰𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗶𝗲𝘀
Review packages. Use lock files. Run dependency scans. Remove what you don't need. Least privilege. Keep secrets out of your code. "We trust this package" is not a security strategy.

𝟵. 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝘆𝗼𝘂𝗿 𝗲𝘅𝗶𝘁 𝗽𝗹𝗮𝗻
Before you depend heavily on any provider, ask: Can we export our data? Switch API keys? Route to another provider? Change the implementation without breaking the product? Every serious dependency needs an exit door.

Trust providers, but don't worship them.
Integrate dependencies, but isolate them.
Use external services, but protect your own core.
Automate retries, but avoid duplicate damage.
Monitor everything. Plan for failure.

If one dependency can take down your whole product, that dependency is no longer a tool. Now it's your co-founder.

And some co-founders resign without notice.

What's the one dependency your product would not survive losing tomorrow?

[SendSasa @sendsasallc]

collecting for a birthday, a trip, or a shared expense?

create a pot. share the code.
SplitChat tracks who paid and who hasn't.
money releases when you hit your target.

no chasing. no drama.

#SendSasa #SplitChat #MobileMoney

[SendSasa @sendsasallc]

4/ The address book is for your inner circle.

SasaNames is for everyone else.

grace.sasa · duclair.sasa · shop.sasa

[SendSasa @sendsasallc]

the address book holds 20 contacts.

after that, older ones disappear.

SasaNames has no ceiling.

claim [yourname].sasa, anyone pays you, no number, no list, no limit.

#SasaNames #SendSasa #MobileMoney

[SendSasa @sendsasallc]

3/ So we built past it.

SasaNames — claim [yourname].sasa

→ Anyone types your name to pay you
→ They don't need your number
→ They don't need to be in your contacts
→ No ceiling. No list. No limit.

[SendSasa @sendsasallc]

2/ After 20, older contacts start falling off the list.

Fine for most people.

Not fine if you're a merchant with 50 regulars.
Not fine if you're a freelancer with 30 clients.
Not fine if strangers pay you daily at a market stall.

[SendSasa @sendsasallc]

1/ The address book is one of the best features in SendSasa.

Save "Mom." Save "Landlord." Save "Boss."
One tap. Transfer done.

But it has a ceiling — 20 contacts.

[SendSasa @sendsasallc]

She's "Mama" in your phone. Not "[phone]."

Your transfers should know that too.

→ Save names, not numbers
→ Lock in your amounts
→ Send in one message

Smart Address Book — SendSasa 💙⚡

[SendSasa @sendsasallc]

Patrick is in Montreal. His crew is in Douala.

Every Friday he calls his brother to hand out cash — because no Canadian bank reaches MTN MoMo.

We're building the fix inside WhatsApp.

Type. Approve. 8 wallets credited in Douala. From Canada.

SendSasa 🌍

#Fintech #MobileMoney

[SendSasa @sendsasallc]

African SMEs don't have a talent problem.

They have a "how do I invoice my client in Texas" problem.

We're solving it, inside WhatsApp. No bank. No app. No terminal.

Just a message. A link. And money in your mobile wallet.

SendSasa 🌍

#Africa #Diaspora #Fintech #MobileMoney

[SendSasa @sendsasallc]

Send money home faster than typing "I love you" 💛

No app. No bank account. No crypto knowledge.

Just open WhatsApp, type the amount, and your family has it in 60 seconds.

https://t.co/0s3lf66hI6

#SendSasa #Remittance #Africa #WhatsApp #Stellar #Fintech

[XRPL Commons @xrpl_commons]

Welcome Duclair Fopa @BlockchainMonk_ , CTO
@mobilewalletinc to the 🌊Aquarium Incubator cohort 8 on Social Impact at XRPL Commons, Paris.

[Duclair Fopa ♈ @BlockchainMonk_]

We just got accepted into The Aquarium residency in Paris.

12 weeks to build what traditional finance fears most:

- WhatsApp remittances in 60 seconds (<1% fees)
- Crypto ATMs across Africa (BTC, ETH, USDT, SOL)

March 27th, we launch. 🇨🇲🚀

#XRPL #Crypto #Africa

[SendSasa @sendsasallc]

@Eyob_Geremew_ @BlockchainMonk_ @theresidency Thanks! 🔥

Week 1 challenge: testing if our one-liner works for people who've NEVER heard of sign language accessibility.

Does it intrigue them? Or just confuse them?

That's what we're validating this week.

How are you testing yours? Let's compare notes! 💪

[Startup Archive @StartupArchive_]

Michael Seibel on how to create a great startup pitch

In the clip below, former Y Combinator CEO Michael Seibel breaks down the two types of pitches every startup founder needs: a 30-second elevator pitch and a two-minute pitch for investors.

“A lot of people practice 10-minute, 30-minute, hour-long, pitches. I think that’s all garbage. I think you can get all of your points across in two minutes. And one thing I like to tell founders is that the more you talk, the more you have an opportunity to say something that people don’t like.”

30-Second Elevator Pitch:

You should be able to explain to anyone you come across what your company does in 30 seconds.

This should be three sentences:

1. What does your company do? Assume the person you’re talking to knows nothing. This should be a 1-sentence explanation that your mom or dad can understand (e.g. “We’re Airbnb and we allow you to rent out the extra room in your house” NOT “We’re Airbnb and we’re a marketplace for space”).

2. How big is the market? Do a couple hours of research so that you can give investors a rough approximation of the size of the market you’re in (e.g. Airbnb might give the size of online hotel booking market)

3. How much traction do you have? Ideally you can say something like: “We launched in January and we’re growing 30% month over month. We have $ X sales and Y users.” If you’re pre-launch, you need to convince investors that you’re moving quickly (e.g. “the team came together in January. By March we launched our beta. By April we launched our product.”).

Two-Minute Pitch:

This pitch is for people you’re actually trying to convince of something (e.g. investors, potential employees, etc.). You basically want to simply explain what you do and then ask for money.

There are 5 key components:

1. Clear 30 second pitch (everything mentioned above)

2. Unique insight—what do the biggest players in your market not understand? This should be 2 sentences.

3. How do you make money?

4. Team. If your team has done something that has made investors money, you should mention that (e.g. “we’re the founders of PayPal”). If you haven’t, don’t go on about the awards you’ve won or PhDs you hold. What investors want to hear is: how many founders? (hopefully 2-4) how many of the founders are technical? (hopefully 50% or more engineers) How long have you known each other? (ideally you’ve known each other either personally or professionally for at least 6 months) Are you all full-time?

5. The Big Ask ($$$). You have to know what you’re talking about when you ask for money. Are you raising on a convertible note or a SAFE? What’s the cap of the SAFE? How much money are you raising? What’s the minimum check size? If you don’t know these things, investors won’t think you’re serious or that you haven’t done your homework.