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

Yesterday, live, I rebuilt @stripe's website. Pixel by pixel. Then I made it my own. 🔗 See it live: stripe-website-sable.vercel.… Why Stripe? Because almost everything on it is built in code, where a simple image would have done the job. That's exactly what separates a generated website from a desired one. Today, AI generates a landing page in 10 seconds. The result: a purple gradient, 3 cards, a "Get started" button. Everyone ends up with the same site. Nobody remembers it. That was the heart of my Design Engineering training: 2 days to go from generated to desired. Day 1: See, understand, direct → A Design Engineer ships end to end: design, code, optimize, improve → Taste lives in milliseconds: 1,000 ms linear feels tiring, 200 ms cubic-bezier(0.22, 1, 0.36, 1) feels natural → Train your eye: look at 10–30 sites a day, recreate them 1:1, publish → The invisible details: spacing scale, type hierarchy, every state, accessibility Then the most important skill: directing AI with a real brief. A generic prompt: "Make me a modern landing page for a money transfer app." A real brief has 6 ingredients: 1. Ambiance: 3 adjectives for the emotion you want (warm, confident, modern African) 2. Palette: one dominant color, one support, one accent (deep green + sun yellow on cream) 3. Typography: name the fonts and their role (editorial serif for headlines) 4. References: 1 to 3 sites to imitate in spirit (stripe.com for clarity) 5. Motion: durations, curves, what moves and why (200 ms ease-out entrances, nothing gratuitous) 6. Constraints: what's forbidden, accessibility, performance (no purple gradients, no emojis, no stock photos) Same AI. Completely different result. Day 2: Animate, polish, ship → Animate with intention: 150–300 ms, ease-out, transform and opacity only → Motion for everyday UI, GSAP for storytelling → The toolbox: shadcn/ui, TweakCN, Motion Primitives, Tabler Icons, React Scan → A beautiful slow site is still a bad site: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 The Stripe case brought it all together: read the design, write the brief, rebuild it in code, animate it, then give it our own identity. The lesson: AI doesn't replace taste. It amplifies it, if you know how to direct it. Want the full source code? 💬 Comment "BRIEF" below and I'll send you the link in DM. I started my YouTube channel 2 weeks ago to share this process in depth. ▶️ Subscribe: youtube.com/@duclair-fopa Need a website redesign, a pro web app, or custom software? 💬 Message me on WhatsApp: wa.me/237676535501 #DesignEngineering #UIDesign #AI #WebDesign #FrontendDevelopment

Another one: an HTML Web Page Analyzer. 🔍 Paste any URL and it tells you the HTML version, page title, heading structure, whether there's a login form, and how many links are internal vs external, then checks each link to see if it's actually reachable. Built with Spring Boot, Jsoup and Guava, and packaged as a Docker image so anyone can run it in one command. 🐳 Docker: hub.docker.com/r/fkd2000/htm…

One of mine: a DSL that recognizes Pascal programs, built with Xtext during my university compiler course. 🛠️ It parses Pascal source, builds a model, and generates code from it. Nobody asked me to push it further, but it taught me more about how languages actually work than any exam did. Four years later, that "small school project" still shapes how I think about building tools. 👉 github.com/ubuntu-assist/dsl…

Yesterday we pitched @sendsasallc at @EnovationF, in the SCALE 32 program for startups. While I waited to go on stage, I picked up "Atomic Habits" from the shelf. The title stopped me for a reason that has nothing to do with productivity. In software engineering, atomicity means an operation either completes fully, or it doesn't happen at all. No half-finished states. No middle ground where money leaves one account and never arrives in another. That's not a nice-to-have in fintech. It's the whole game. As we build SendSasa, atomicity is the principle we obsess over. A transaction that's 80% complete isn't 80% successful, it's a support ticket, a lost customer, or worse, lost trust in an entire payment rail. James Clear wrote about small changes compounding into remarkable results. In fintech, we'd say it differently: small failures compound into catastrophic ones if you let them slide even once. Holding that book on stage felt less like a coincidence and more like a reminder of the standard we hold ourselves to every time someone sends money on SendSasa. Grateful to Enovation Factory for the platform, and for a room full of builders who understand that the smallest technical details are often the biggest business decisions. #SendSasa #Fintech #MobileMoney #Scale32 #Startups #SoftwareEngineering

Most people think startups die from bad ideas. They don't. They die from running out of money before enough people loved the product. Here's what actually matters, from someone who's been there: 1. You don't need a genius idea Google's idea wasn't genius. It was "make search that doesn't suck." That's it. Three tweaks, index more of the web, rank by links, keep the page clean and that alone is worth a billion dollars a year. Look for stuff that's still broken. Dating apps in 2005 were embarrassingly bad. An undergrad could've built something better as a class project. The idea isn't the moat. What you do with it is. 2. Good people fix bad ideas. Good ideas can't save bad people. VCs will hear your "brilliant, secret" idea and pass in five minutes. That tells you what ideas alone are worth. What they're actually betting on is whether you're the kind of person who takes the work a little too seriously, the hacker who won't sleep with a bug in the code, the salesperson who won't take no. If you can't describe someone on your team as "an animal" at what they do, that's a gap. 3. Build the smallest thing, then watch people use it Don't spend a year and $2M building the "perfect" version in isolation, that's the Hail Mary strategy, and it's how most failed startups actually failed. Ship something rough. Watch real users struggle with it. Fix that. Repeat. Your first plan is wrong somewhere, you just don't know where yet, and the only way to find out is to put it in front of people. 4. Stay poor on purpose Money in the bank isn't revenue. It's a loan against a future you haven't earned yet. Growing slow, cheap office, few hires, no fancy chairs, isn't a failure state. It's a lab. It buys you time to actually understand your users before you scale the thing you built for the wrong people. 5. Users over advertisers, always The businesses that win put the person actually using the product first, even when someone else is the one paying. Do that, and the money follows. Do it backwards, and you leave the door open for whoever gets it right. None of this requires brilliance. It requires: — good people — something people actually want — spending as little as possible while you figure it out Hard. But doable.

Two engineers. Both around seven years in. One says: "I'm a full stack engineer. I've worked on a bit of everything, frontend, backend, databases." The other says: "I work on payment systems. I've spent the last five years making sure money and transactions move correctly when millions of them are happening at the same time, without anything getting lost, duplicated, or processed twice." Now ask yourself: who is a company like @stripe, or any company that builds fault-tolerant systems, going to hire? The second engineer. Almost every time. Not because they worked harder. Because they're not selling effort, they're selling expertise. A specific problem they've already solved. The first engineer is still valuable. Don't get that twisted. But you can find a lot more of them than the second one. This is also why the very first recruiter call always boils down to the same questions: What team are you on? What domain are you in? Tell me about the kind of work you do day to day. Tell me about what you're looking for. They're not making small talk. They're searching for a domain match. So before anything else, find yours. Look at your past experience. Honestly figure out what domain you're actually in. Not what sounds impressive. Not what you wish it was. That's what you're going to use to brand yourself. That's what gets you attention from the companies that actually pay for expertise. What domain would you say you're actually in?

I was a kid. Left hand. Always left hand. My mom didn't like it. Cane. Ruler. Across my hand. I cried. Every time. I didn't understand it then. She wasn't trying to break me. She was preparing me, for a world that wouldn't always bend for me. She got me to switch, for eating. Right hand, she said. Learn both. Writing, I kept left. She let that one go. Today is International Left-Handers Day. I'm one of the 10%. And today, I'm not thinking about the pain. I'm thinking about the woman who raised me. She taught me discipline before I knew the word. She taught me how to adapt without losing myself. That lesson built me. SendSasa LLC. Mobile Wallet Inc. InReach. Every one of them exists because a woman who once corrected my hand with a cane also gave me the discipline to build something from nothing. Turns out I'm in good company. Bill Gates. Steve Jobs. Jack Dorsey. Mark Zuckerberg. Lefties. Builders. Category-definers. I don't know their stories. But I know mine. And mine starts with a woman who loved me enough to correct me, and wise enough to know when to stop. To my mother, thank you. For the discipline. For the education. For everything I didn't understand back then that I'm grateful for now. 🙏🏾✋💛 #LeftHandersDay #ProudLefty #ThinkDifferent #BuildDifferent

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?

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?

Most founders think infrastructure means "which cloud, which framework, do we have AI agents." Wrong question. Infrastructure isn't decoration. It's your survival system. The real question: will this survive real users, failed payments, fraud, and a confident engineer pushing to prod on a Friday? Because that Friday deploy always comes. 𝗙𝗶𝗻𝘁𝗲𝗰𝗵? 𝗬𝗼𝘂'𝗿𝗲 𝗻𝗼𝘁 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘀𝗰𝗿𝗲𝗲𝗻𝘀. You're handling money, trust, identity, audit logs, reversals, reconciliation. User says "I paid, but my wallet shows zero"? You can't guess. Maybe the webhook failed. Maybe the provider was slow. Maybe the DB choked. Guessing is not a system. You need to trace: → Who paid, and when → What the provider returned → Whether the webhook arrived → Whether the wallet was credited → Whether it was logged Can't prove what happened? That's not a product. That's a liability waiting to go viral. 𝗔𝗜 𝘀𝘁𝗮𝗿𝘁𝘂𝗽? 𝗔 𝗱𝗲𝗺𝗼 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗰𝗼𝗺𝗽𝗮𝗻𝘆. Everyone can plug into an API and call it "AI-powered." That's the easy part. What actually separates a product from a demo: → Tracking cost per request → Monitoring wrong answers → Knowing which prompts fail → Handling hallucination → Handling provider downtime → Knowing what data you send the model → Catching the one user quietly burning your margin Without answers here, you're not scaling. You're just burning money faster with extra steps. 𝗧𝗵𝗲 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 𝗜 𝘀𝗲𝗲 𝗲𝘃𝗲𝗿𝘆𝘄𝗵𝗲𝗿𝗲: Teams want microservices before they have logs. They want Kubernetes before they have backup and restore. They want AI agents before they have evaluation. They want complex architecture before they understand their users. That's not scaling. That's multiplying confusion. A bad monolith is bad. A bad microservices setup is worse, a distributed crime scene. Every service reports "healthy." Payment service, fine. Wallet service, fine. Redis, fine. And yet the customer's money is still gone, and nobody can point to what actually broke. 𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘄𝗼𝗿𝗸𝘀: 1. Start simple, not careless Modular monolith. Postgres. Redis for cache and queues. Background jobs for slow work. Real CI/CD. Structured logs. Monitoring. Audit trails. Backups you've actually tested by restoring them. An untested backup isn't a backup, it's a hope. 2. Build for recovery Every serious system has to answer: what happens when this fails? Not if. When. The payment provider will fail. The database will slow down. The model will time out. Users will double-click the pay button out of anxiety. Plan for all of it on day one. 3. Security from day one Not a feature you bolt on later. Part of the product itself. Proper authentication. Proper authorization. Rate limiting. Non-negotiable, especially in fintech. Infrastructure isn't what impresses people in a demo. It's what's still standing when real users, real money, and real failure all show up on the same day. What's the first "invisible" system you built — logging, backups, audit trails — before anyone asked you to?

every external API you integrate into @sendsasallc is a liability. not because APIs are bad. because APIs change. pawaPay changes a field name in their deposit response → every service that read that field breaks. Gemini changes how structured output works → every place you called the API needs updating. I let this happen once. a pawaPay response field rename. I found it in three places before I found it in the fourth. the fourth was in production. Adapter pattern: IPaymentGateway is our interface. it's ours. it's stable. PawapayAdapter implements it. it translates between our shape and theirs. feature services call gateway.deposit(). they never see a pawaPay response object. they never know what correspondent means or what MSISDN is. when pawaPay changed their field: I changed PawapayAdapter. one file. every feature was already correct. when I wanted to swap Gemini for Claude for dispute adjudication: I wrote a new adapter. SafiPayService never knew anything changed. the insight that changed how I design systems: vendor contracts will change. your interfaces shouldn't. the Adapter is the wall between those two truths.