> ## Content Index > Fetch the complete content index at: https://afrolynx-insights.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # Shoot first, ask later. - URL: https://afrolynx-insights.ghost.io/shoot-first-ask-later/ - Published: 2026-09-28T12:03:02.000Z - Updated: 2026-09-28T13:23:04.000Z - Author: Peter Mugisha Turns out, that does not work particularly well when you are writing code. A prospective client had a business process they needed to automate. It happened to be in an area I had spent the previous five years working in, so I understood the obstacles, limitations and nice-to-haves. I thought I knew the problem. So, I started building. For six months, I worked on the solution. Weekends. After hours. Whenever I could find the time. My team chipped in, but because we did not yet have a confirmed client, I chose to do most of the heavy lifting myself. There was just one rather important thing I did not do: I never checked back with the prospective client. In my mind, the need was obvious. The problem existed across the industry, and I was confident my solution could address about 80% of it. The remaining 20% could be customised once we deployed. Six months later, I was ready to pitch. There was only one problem. A few weeks earlier, the client had implemented another system. And, in his words, he was “happy with the solution.” Six months of development, and I had arrived late to a race I did not even realise had started. Over the past 17 years, I have built many applications. A considerable number have eventually been shelved because clients changed direction, budgets disappeared, priorities shifted or another solution became more appropriate. That comes with the territory. But this one felt different. The technology was not the problem. Neither was my understanding of the business process. The mistake was building in isolation. I had confused knowing the *industry* with knowing the *customer*. There is a difference. **Audience before product** In *The Embedded Entrepreneur*, Arvid Kahl challenges the conventional approach: Idea → Product → Find customers and proposes: Audience → Problems → Validate → Product His argument is particularly relevant to developers because our greatest strength can occasionally become our weakness: we can build things. An idea appears technically feasible, Visual Studio opens, a database appears, and before long there is an architecture, an API and several thousand lines of code. But technical feasibility does not equal customer demand. Seth Godin approaches the same problem from a marketing perspective. His philosophy captures it neatly: “Don’t find customers for your products, find products for your customers.” Rob Walling similarly emphasises validation before investing heavily in development. His approach can broadly be represented as: Problem/Market → Validate → Establish an acquisition channel → Build → Launch to existing prospects Three different perspectives, but one uncomfortable lesson: Writing the code should not necessarily be the first step. What I would do differently today The six months were not wasted. They were expensive tuition. Today, I would spend considerably more time speaking to the prospective users before committing months to development. I would ask what they currently use. I would ask what frustrates them. I would ask what the problem costs them. I would ask what alternatives they are considering. Most importantly, I would ask what would make them actually pay for a different solution. Only then would I decide what deserves to be built. As much as I enjoy spaghetti westerns, I have learnt that software development is not the place to shoot first and ask later. Perhaps the better approach is: 1\. Listen first. 2\. Validate second. 3\. Build third. The encouraging part is that six months of building the wrong thing can teach lessons that improve the next 17 years of building the right things. A shelved product is not necessarily the end of a good idea. Sometimes it is simply the beginning of a better way of finding one. The next great product may not start with a line of code. It may start with a conversation over a nice cup of coffee.