I am not a designer by profession. I am a software engineer with over six years of experience, and I have worked closely on consumer products in delivery logistics, fintech, and healthcare. Long before I touched Reconify, I understood the importance of user experience, even as a backend engineer. I wrote about why backend engineers should learn about user experience back in 2022, and that belief still holds.
During my career, I have had the privilege of working with talented designers like Emmanuel and Olafemi, and each of them has shaped how I think about building products. I also took part in UX workshops and read Refactoring UI.
Along the way, I understood one thing: product experience isn't about making interfaces simpler. It's about making someone's work easier. Design gives you the tools to do that.
Two stories taught me that lesson the hard way.
Engineering should never dictate experience
At my first job, we spent six months building a food delivery product called Quatro, similar to Uber Eats. The product depended on real-time notifications for riders, and we built it on Django WebSockets during the early days of asynchronous Python. We still shipped it for testing among consumers, riders, and restaurants.
The first problem was technical. The WebSocket notification system was buggy and did not alert riders quickly enough. Orders sat waiting. Riders didn't know when to move. Restaurants called support asking why no one had picked up the food.
The second problem was more interesting. Even after we fixed the notification bugs, the workflow still didn't feel natural for riders or restaurants.
We removed the WebSocket-based notification system that same week. Instead of making riders wait for a push notification before picking up an order, we replaced it with a single screen listing orders as new, ongoing, or cancelled, refreshed at a high rate. That screen ran for 12 months, and WebSockets only came back a year later, this time in read-only mode. By then, we had learned enough about the experience riders needed to design the engineering around it, instead of the other way around.
Restaurants, especially the busiest ones, were focused on cooking and serving customers. They didn't have the attention to spare for a tablet buzzing with new orders. We had designed the workflow around what we expected restaurants to do, not around what they actually had time to do. So we moved order-management responsibility to the rider, who was already coordinating the pickup.
The lesson: engineering should never dictate the product experience. We copied Uber Eats and Glovo's technical implementation, WebSockets and all, before validating that we had the same operational constraints they did. The question we should have started with wasn't which technology they used. It was what experience our riders needed, and what the simplest technology was that could deliver it reliably at the time. We never even showed the riders the application before they started delivering with it.
The second lesson: put yourself in your customer's shoes before you build a prototype. That step saves time, even after you hand the shoes back and watch how they actually walk in them.
No matter how much research you do, you'll still make assumptions. Some will be right, others won't.
The first version of your product isn't there to prove you were right. It's there to reveal where your assumptions break down.
That's why observing users is just as important as empathizing with them. Research helps you build a better first prototype, but observation is what turns that prototype into a great product.
I thought I'd learned that lesson. Six years later, while building Reconify, I found out I'd only learned half of it.
Know when to build for trust or for speed
Over the following six years, I worked on fintech, fiber network management, construction software for European companies, healthcare, and edtech products. Those experiences refined my understanding of user experience, but they never challenged its foundations.
I am currently working on a financial reconciliation software for fintechs, called Reconify.
The idea started with audit work I did for mobile money companies in West Africa, matching records between network operators, accounting systems, and payment processors. That work stayed with me because reconciliation touches everything a finance team does, and almost nobody enjoys doing it by hand. Reconify became the system finance teams use to reconcile those transactions at scale.
Using AI, I vibe-coded the first version of the Reconify dashboard in a few days. Before I trusted it, I put myself in a finance analyst's shoes: watching how analysts reconcile transactions in Excel, testing the competing tools I could get access to (most hide behind a demo request instead of a free trial), and talking with people at fintech companies like Djamo and Conduit about where it hurts most. What I learned mattered more than how I learned it.
That research taught me one thing: reconciling 100 transactions is not that different from reconciling 40 million, because it is a scale problem, not a logic problem. Matching turned out to be the least difficult part of reconciliation. The harder work happens before it, during ingestion and data cleaning, and after it, during adjustments, investigation, and audit. That insight redirected where I put my energy.
With that research behind me, I made a handful of design decisions for the first version of Reconify. Two of them turned into the stories that taught me the most: how analysts wanted to review exceptions, and how they wanted to upload their data in the first place.
I believed I had translated the research into the right decisions. Testing showed me how far I still was from that.
I have a close relative who works as a finance analyst. I showed her the platform, helped her generate realistic files, and watched her use it.
She reached the upload step and wanted to add every source at once, not one file at a time. Sequential uploads felt slow to her and did not match how she works. I replaced the step-by-step modal with a drawer, large enough to hold several sources in one pass.
When she opened an exception, she expected a panel that let her keep browsing the table while she worked, not a pop-up that blocked it. That confirmed a decision I had made without testing it, the exception panel instead of a modal, and showed me why the choice mattered.
I thought I had already done the work, through research and design decisions made in good faith. Testing showed me that good faith is not the same as good judgment.
I had built for correctness and completeness rather than for trust.
Analysts do not want fewer clicks. They want certainty that the number in front of them is right. They will take an extra confirmation screen every time, which protects them from a reconciliation mistake.
Consumer products optimize for speed. Professional tools optimize for confidence.
If you are a software engineer or a founder, invest in learning UX
If I could start again, I would spend less time looking for clever technical solutions and more time understanding the people I was building for.
Today, building software has never been faster. That doesn't mean it's easier, just that it's easy to turn ideas into a working prototype nowadays, whether you have the skills or not. But one principle hasn't changed: software exists to solve problems. And understanding the problem hasn't become significantly faster.
As engineers or founders, we naturally fall in love with solutions. We discover a new technology, an elegant algorithm, or a clever architecture, and immediately start thinking about where we could use it. I still catch myself doing exactly that.
Instead of starting with a solution, start with the people.
Who is struggling?
What are they trying to accomplish?
What gets in their way?
Only after answering those questions do I think about the technology that could help.
And in a world where everyone can build software and create slop faster than ever, I believe the ability to observe, understand, and design around real problems will remain one of the most valuable skills an engineer or founder can develop.
Top comments (0)