Building practical software for African businesses. At @LWEGATECH we’re creating BORAsuite — a growing set of tools designed to help businesses run better day-to-day: • #BORApos – Point of Sale & inventory • #BORAinvoice – Invoicing & billing • #BORAlearn – Learning & membership systems • #BORApharma – Pharmacy operations …and more products in the pipeline. Our focus is simple: technology that simplifies the work people already do, instead of trying to replace them. If you’re building, running, or supporting businesses in Africa, you’ll find practical product lessons, SaaS building stories, and real-world observations here. Explore the suite: borasuite.com What part of business operations do you wish software handled better?

Hello @X community Lwegaba here, into Web solutions, #SaaS building. Let's connect

One thing that I am coming to appreciate about the @X community is the vast knowledge people here have. So much you can learn just by reading, posting and interacting with members here. And when it comes to idea generation, superbly you will get alot more. Cheers guys.

Do you still run such commands or its #AI’s problem now. python manage.py showmigrations python manage.py migrate python manage.py runserver

One rsync option I'm increasingly appreciating is: --dry-run It helps you preview what a synchronization would do before making changes. Particularly useful when you're updating production files and don't want surprises. 😂 Do you normally dry-run your deployments, or do you trust your command and verify afterwards?

WHAT IS THE WORST THAT CAN HAPPEN!? - The Question That Changed How I Approach Problems Many years ago, while working at Africa Online, I worked with a brilliant Tech Manager called Paul. Whenever we faced a difficult problem and expected him to simply give us the answer, sometimes he would look at us and say: “Go and find a solution… I mean, what is the worst that can happen?” At the time, it became something we laughed about. But years later, I realised that simple question had changed the way I approach problems, technology and entrepreneurship. It taught me that you will not always have all the answers before you begin. Sometimes you test. You fail. You adjust. And you continue. Even today, as we build #BORAsuite and grow @lwegatech , there are decisions where the complete answer is not immediately obvious. You assess the risk, make the best reasonable decision you can, learn from the outcome and keep moving. In this first episode of LJBStories, I share that experience and four lessons I believe every entrepreneur, technology professional and anyone trying to build something can take from it: • Don’t let fear stop you from trying • You will not always have all the answers • Let failure give you information, not paralysis • Learn how to recover, not simply how to avoid mistakes Of course, “What is the worst that can happen?” does not mean being careless or reckless. Sometimes the better question is: If the worst happens, can I recover from it? If the answer is yes, perhaps the fear is bigger than the actual risk. Welcome to LJBStories — conversations about technology, SaaS, entrepreneurship, business and lessons from the journey. If this story connects with you, subscribe to the channel and share your own experience in the comments: What is something you eventually tried after being afraid to start? #LJBStories #Entrepreneurship #Technology #BusinessLessons #SaaS #AfricanTech #LJBTechBiz Thank you @ambrose_watanda for production

You deploy updated application files. You verify that the new files exist on the server. But your browser still shows the old version. 😂 Sometimes the missing piece is #caching, browser cache, application cache, PHP OPcache or another layer. What's the most frustrating caching issue you've encountered after deployment? #LinuxServers #SystemAdministration #SaaS

One #lesson managing #Linux #servers keeps teaching me: A successful command doesn't always mean a successful outcome. I've had #rsync finish without errors, only to discover that important application files hadn't changed as expected. These days, I prefer verifying the result before celebrating. What's your favourite post-deployment verification command?

One small detail in #Linux that can create a big deployment headache: rsync -av source/ destination/ isn't always equivalent to: rsync -av source destination/ That trailing slash changes how the source directory is copied. And sometimes that's all it takes to put files somewhere you didn't intend. 😂 Have you ever been caught by this?

RSYNC: A Saviour That Can Sometimes Mislead You Have you ever deployed an application update, received a successful result from #Linux, and then discovered that your application was still running the old code? 😂 Well, I've been there! There are times when deploying application updates through Git or automated pipelines isn't practical, and I find myself going the old-school way: FTP → rsync → Production Server. For those working with Linux servers, rsync is one of those commands you quickly learn to appreciate. It synchronizes files between locations, copying new or changed files without requiring you to manually approve every replacement. And when you're updating hundreds of application files, that can be a real lifesaver. But here comes the interesting part. 😂 Sometimes rsync finishes successfully, yet your application is still running old code! I've encountered situations where images, JavaScript files or even important PHP files appeared not to have been updated after synchronization. Now, this doesn't necessarily mean rsync failed. Perhaps the source path was wrong, the command skipped certain files, the comparison didn't detect the expected change, or the server was still serving cached content. For example, there's an important difference between: rsync -av source/ destination/ and rsync -av source/* destination/ The second command relies on shell wildcard expansion, which can exclude hidden files and may behave differently from what you intended. And if you haven't paid attention to the directory structure, you might successfully copy files into the wrong location. Linux did exactly what you asked. But was that what you intended? 😂 And that is where the real lesson begins. Never assume that because a Linux command completed successfully, your deployment was successful. These days, I increasingly appreciate combining rsync with verification commands to check what changed, confirm important files were replaced and ensure the application is actually serving the latest version. Sometimes that means comparing file checksums, checking timestamps, reviewing deployment paths or investigating application and server caches. And whenever possible, a dry run before synchronization can help identify unexpected changes. Because the difference between “Files transferred successfully” and “Application updated successfully” can sometimes be several hours of unnecessary troubleshooting. The tool may have done exactly what you instructed it to do. The problem is that what you instructed wasn't necessarily what you intended. For fellow Linux administrators, developers and DevOps engineers: Have you ever had an rsync deployment that left you scratching your head? And what verification steps have saved you from deployment surprises? Happy new week, friends! #MondayBusinessWithLJB #Linux #SysAdmin #BORApos #BORApharma #BORAinvoice #BORAlearn #DevOps #WebDevelopment #ServerManagement #LWEGATECH

Most Sunday evenings ... I like to recharge outside and process how it will go.

A beautiful Sunday 😍 to you all my friends. One thing I keep learning is "asking for what you want" With clarity in your request ..... you will always get it. So what is that you want this new week? Me? Another 500 great @X friends here and healthful week to post and reply to as many people's post as I can. Set your goal today, we are reviewing it together on 24th/Oct/2026

Hello @X community. Thank you so much for the love. We are closing a week very strong together ❤️ Am very close to 500. Lets close that number today as we go in resting Sunday Cheers

Everytime you challenge yourself, set those tough goals, you are always to a certain degree. That is why pen and paper are still my best friends.

Call me old but I prefer web Apps for usage. No drama of install now. Just open -> use -> close That is it.

My overused google fonts are Montserrant and Roboto. If #Google is to come collecting royalties, i would be on their list of defaulters. Which #Google font do you use most.