For a long time, I had a simple belief about pilot projects. If we could demonstrate that the technology worked, solve the technical problems encountered during testing, and show the customer that the solution could operate successfully in a real environment, then moving into a commercial deployment seemed like the natural next step. It made perfect sense from an engineering perspective. Why would an organisation spend months testing something, prove that it works, and then decide not to continue?
Over the years, I discovered that the real world does not always follow engineering logic. A successful pilot proves that something can work, but it does not automatically prove that a customer will buy it, that a budget exists, that management will continue supporting it, or even that the market will still exist when the pilot ends. Two projects in particular taught me this lesson. Both were government funded pilots, both involved technologies that we successfully tested, and both gave us reasons to believe there was a future beyond the pilot. Yet neither became the commercial project we had hoped for.
What makes these two experiences interesting is that they ended for completely different reasons. The first was affected by an extraordinary event that nobody could control. The second exposed weaknesses in the way we had qualified the customer and the commercial opportunity. Together, they changed the way I think about pilots and taught me that technical success is only one small part of building a sustainable technology business.
Raqib: When We Found a Market and Then the Market Disappeared
The first project was Raqib, a product we developed around 2018 and 2019. Raqib originally began as a smart elderly care solution, using connected devices to help families and caregivers monitor the location and wellbeing of elderly people. As we developed and tested the concept, we began to see another possible application that shared many of the same challenges: monitoring pilgrims performing Hajj and Umrah.
The problem made sense to us. Pilgrims often travel in large groups and move through unfamiliar places, sometimes in extremely crowded environments. Many are elderly, and there is always a possibility that someone becomes separated from the group or needs assistance. We believed that connected devices could provide tour operators and family members with better visibility of where pilgrims were and help them respond more quickly when something went wrong.
We decided to reposition Raqib towards this market and began testing the concept more seriously. We conducted local trials and asked several early users to carry the devices during their pilgrimage. I even tested Raqib personally during my own Umrah trip because I wanted to experience the product under the same conditions as our users. That field experience was far more valuable than testing the system from the comfort of our office because it exposed issues involving connectivity, battery life, device handling and actual user behaviour.
There were challenges, of course, but that did not discourage us. In fact, that was exactly what we expected a pilot to reveal. We identified the problems, worked on them and improved the system. By the end of those trials, we had become increasingly confident that the technology could work. We had moved beyond PowerPoint slides and laboratory demonstrations. Real users had carried the product into the actual environment for which it was designed.
From where I stood at the time, the next stage seemed obvious. We had tested the product, learned from the problems and improved it. Now we needed to build the market.
Then 2020 arrived, and everything changed.
COVID-19 Changed the Question Overnight
When COVID-19 spread across the world, international travel came almost to a standstill. Borders closed, flights were cancelled, Umrah travel was suspended for long periods, and Hajj participation was severely restricted. For Raqib, this was not merely an operational inconvenience. The very activity around which we had positioned the product suddenly became inaccessible to most international pilgrims.
There was nothing our engineering team could fix because there was nothing technically wrong with the product that could solve the situation. We could improve the software, extend battery life, redesign the interface or improve the platform, but none of those things could reopen international borders or bring pilgrims back to Makkah.
Initially, like many businesses, we did not know how long the disruption would last. Perhaps travel would resume after a few months. Perhaps the following pilgrimage season would return to normal. But uncertainty continued, and for a small company, waiting indefinitely carries a very real cost.
A product continues consuming resources even when customers disappear. Servers must be maintained, software requires updates, devices need support, engineers have to spend time fixing problems, and management must continue thinking about the product. More importantly, every hour and every ringgit spent keeping one product alive is a resource that cannot be spent somewhere else.
Eventually, we had to make a difficult decision. We could continue supporting Raqib while waiting for the pilgrimage market to return, without knowing when that would happen, or we could accept that circumstances had changed and redirect our limited resources elsewhere. We chose to shut down the service and move on.
It was painful because Raqib had not failed in the traditional sense. The technology had been tested. We had real users. We had solved many of the problems discovered during field trials. Yet the commercial opportunity disappeared because of something nobody on our team could have predicted or controlled.
That experience taught me my first major lesson about pilots: even when you do many things correctly, timing and external events can still determine the fate of a product.
The Second Pilot Taught Me a More Uncomfortable Lesson
Our second experience was very different because this time there was no pandemic, no global shutdown and no disappearing market. The project involved the Favoriot IoT platform and a local council that wanted to test the platform’s functionality, standards interoperability and ability to work with several of its existing smart city solutions.
From a technical perspective, this was exactly the type of challenge that interested us. Smart cities rarely operate with one system from one vendor. A council may already have different systems for parking, CCTV, environmental monitoring, flood monitoring, street lighting and other municipal services. These systems may have been purchased at different times from different suppliers, which often means they use different architectures, protocols and applications.
One of the values of an IoT platform is its ability to connect these different environments and make information available across systems. During the pilot, Favoriot successfully demonstrated that capability. We tested the platform’s interoperability and showed that it could work with several of the council’s existing smart city solutions.
Technically, the pilot achieved what it was supposed to achieve. Naturally, we were pleased with the outcome, and once again I believed that we had crossed the most difficult hurdle. If the platform had demonstrated its capabilities in the customer’s environment and met the pilot objectives, surely the next logical step would be a commercial deployment.
It never happened.
The local council eventually decided not to proceed with Favoriot as its platform. They had different ideas about how they wanted to move forward, and the commercial project that we had imagined never materialised.
This time, I could not blame COVID-19, market conditions or an unexpected global event. The technology worked, the market still existed, and the organisation continued pursuing its smart city ambitions. Yet our successful pilot did not become a commercial project.
That forced me to examine something much closer to home: perhaps we had been too focused on proving our technology and not focused enough on proving that there was a committed customer waiting at the other end.
A Pilot Participant Is Not Necessarily a Customer
This distinction seems obvious to me today, but when you are inside a pilot project it can be surprisingly difficult to recognise. A participating organisation can behave very much like a customer. People attend meetings, technical officers provide requirements, sites are made available, integration discussions take place, demonstrations are conducted and progress reports are written. Everyone appears engaged, so it is natural for the technology provider to interpret that activity as evidence of future commercial commitment.
But participation and purchasing intent are two very different things.
An organisation may participate in a government funded pilot because it wants to learn about a new technology, compare different approaches or satisfy the objectives of a particular programme. The technical team may genuinely like the product and the operational department may find the solution useful, yet none of these conditions necessarily means that someone has approved a budget to purchase it after the pilot.
Looking back, this was one of our biggest mistakes. We spent considerable effort answering the question, “Can Favoriot successfully do what the customer needs?” We did not spend enough time answering the equally important question, “If Favoriot proves that it can do this, is the organisation genuinely prepared to buy and operate it?”
Those are two completely different validations.
Government Funding Can Sometimes Hide the Real Market Signal
I remain supportive of government funded technology programmes because they can be extremely helpful for startups and local technology companies. They allow companies to test products in real environments, provide access to organisations that might otherwise be difficult to reach, and reduce some of the financial risks involved in experimentation. Without such programmes, many technologies might never get the opportunity to move from laboratory prototypes into actual field environments.
At the same time, founders need to recognise a weakness in this model. When someone else pays for the pilot, the participating organisation does not have to make the same financial decision it would face during commercial deployment. Trying a technology using grant funding is very different from allocating your own operational budget, going through procurement and signing a purchase order.
This can create a false sense of market demand. Everyone may be enthusiastic while the pilot is funded, but once the external funding ends, the organisation suddenly has to justify the expense internally. Management priorities are reconsidered, budgets must be found, procurement procedures begin, other projects compete for the same money, and the technology that looked important during the pilot may suddenly become optional.
If I were evaluating such an opportunity today, I would ask a much harder question before committing significant resources:
If the government funding disappeared tomorrow, would this organisation still be willing to pay for the solution?
The answer tells us far more about the commercial opportunity than enthusiasm during a demonstration.
Technical Validation Is Only One Part of a Successful Pilot
My engineering background naturally influenced the way I viewed pilots. We tend to focus on measurable technical questions. Does the device communicate reliably? Can the platform handle the required data? Does the API connect properly? Can different systems exchange information? Do alerts work? Is the dashboard displaying the correct information?
These questions matter, but they represent only technical validation. A commercially meaningful pilot must test several other assumptions at the same time.
First, we need to establish whether the technology genuinely solves the operational problem. Second, we need to understand whether the problem is painful enough for the organisation to spend money solving it. Third, we need evidence that the value created by the solution can justify its cost. Fourth, there must be people inside the organisation who are committed to moving forward. Finally, there must be a realistic procurement and budget pathway after the pilot.
A pilot can pass every technical test while failing all the commercial ones.
That was perhaps the biggest change in my thinking. I stopped seeing a pilot as merely a technical experiment and started seeing it as a test of the entire commercial hypothesis.
Lesson One: Find the Buyer, Not Just the Pilot Site
Today, one of the first things I would want to understand is who will actually buy the solution if the pilot succeeds. This can be complicated in government organisations and large enterprises because the person experiencing the problem, the person evaluating the technology and the person controlling the budget may all be different people.
The operational team may desperately want the solution. The IT department may approve the technology. Engineers may love the architecture. Yet if senior management has different priorities or there is no budget allocated, none of that enthusiasm guarantees a project.
Before committing significant resources to a pilot, I would want to understand who owns the problem, who owns the budget, who makes the final decision and how procurement will happen. I would also want to know whether those people are aware of the pilot and whether they have expressed any intention to proceed if it succeeds.
The question I should have asked more often years ago was remarkably simple: Who signs the purchase order when this pilot succeeds?
If nobody can answer that question, we should recognise the risk before we begin.
Lesson Two: Define What Happens After the Pilot Before It Starts
Another lesson is that success criteria should not stop at technical measurements. We may define that a platform must connect a certain number of devices, integrate several systems, achieve a particular uptime or demonstrate certain operational functions. Those are useful measures, but they do not tell us what happens when every technical box has been ticked.
Before starting a pilot, I would now want a discussion about the commercial next step. If the agreed objectives are achieved, does the solution move into production? Will deployment expand to more locations? Will the organisation request budget? Will a commercial tender be issued? When is the decision expected to happen?
Government procurement cannot always be guaranteed in advance, and I would never expect a pilot agreement to bypass proper procurement procedures. But there should at least be a credible pathway from technical success to commercial consideration.
Without that pathway, we may spend months building a bridge without checking whether there is a road on the other side.
Lesson Three: Look for Real Commitment
I have also become more cautious about completely free pilots. Free pilots can generate interest because they reduce the customer’s risk, but that same advantage makes it difficult to measure genuine commitment. When there is little cost to participate, organisations can experiment without having to make difficult internal decisions.
The customer does not necessarily need to pay the full commercial price during a pilot. Commitment can take many forms, including staff resources, infrastructure, integration support, access to operational data, management involvement or a smaller financial contribution. What matters is that the customer also has something invested in the outcome.
When both parties have something at stake, behaviour changes. Meetings become more serious, deadlines receive more attention and internal stakeholders are more likely to remain involved.
If the technology vendor is the only party carrying significant risk, the pilot can easily become an interesting experiment rather than the beginning of a commercial relationship.
Lesson Four: Ask What Could Stop the Project Even If We Succeed
This is perhaps one of the questions founders do not ask often enough. We spend so much time thinking about how to make a pilot successful that we forget to ask what could still kill the project afterward.
There may already be another preferred platform. A larger procurement exercise may be planned. Management priorities may change. The organisation may not have budget. The project may depend heavily on one internal champion who could be transferred to another department. Existing contracts may restrict what can be purchased. A new policy could change the direction entirely.
Understanding these risks before starting does not mean being negative. It simply means understanding the environment in which the technology will eventually have to survive.
A technically successful pilot does not remove organisational, political, financial or procurement barriers. Those barriers need to be identified and managed separately.
Lesson Five: Separate Bad Luck From Bad Decisions
Perhaps the most personal lesson from these two experiences was learning to distinguish between circumstances we could not control and mistakes we could have avoided.
COVID-19 was outside our control. We could not reopen borders, restart international pilgrimage or predict exactly when travel would return. The lesson from Raqib was therefore not that we should have somehow predicted a global pandemic. The lesson was that small companies need to manage exposure to external shocks, avoid becoming overly dependent on a single market condition, and be willing to stop investing when the economics no longer make sense.
The smart city pilot was different. We had greater control over how we qualified the opportunity. We could have asked harder questions about customer commitment, budget ownership, management support and the procurement pathway before investing significant time and resources.
This distinction matters because founders should neither blame themselves for everything nor blame circumstances for everything. When something does not work, I now try to ask whether the cause was within our control. If it was, the lesson should become part of our process. If it was not, the lesson should strengthen the way we prepare for uncertainty.
Lesson Six: Design the Pilot Backwards From Commercial Deployment
If I were designing these pilots today, I would begin from the end rather than the beginning. Instead of asking, “What technology should we demonstrate?” I would first ask, “What needs to be proven for this customer to confidently move into an operational deployment?”
That small change in perspective produces a very different pilot.
If management needs evidence of cost savings, the pilot should measure those savings. If cybersecurity approval is required, security requirements should be tested during the pilot rather than discussed afterward. If interoperability is the main concern, the pilot should prove interoperability with the systems that matter. If procurement requires a business case, the pilot should collect the operational and financial evidence needed to build that case.
Every activity in the pilot should reduce one of the uncertainties preventing the customer from moving forward.
When viewed this way, a pilot is no longer just proof that the technology works. It becomes a structured process for removing the reasons a customer might hesitate to deploy it.
The Dangerous Comfort of Being Busy With Pilots
There is another uncomfortable lesson that took me longer to appreciate. Technology companies can become very busy doing pilots without actually building a sustainable business.
Pilots create activity. There are meetings, presentations, site visits, demonstrations, progress reports, launch ceremonies and photographs. Engineers are busy solving interesting problems, customers are talking about the technology, and management feels that the company is making progress. Sometimes the pilot even receives publicity, which makes everything look even more promising from the outside.
Then the pilot ends. The final report is submitted, everyone shakes hands, photographs are taken, and a few months later the system is no longer operating.
A startup cannot survive indefinitely on demonstrations, no matter how successful those demonstrations appear. At some point, somebody must value the solution enough to pay for it, operate it and continue using it.
That is why I no longer measure the success of a pilot only by whether we achieved the technical objectives. I also ask whether the pilot moved us closer to an operational deployment and a paying customer.
The Questions I Would Ask Before Accepting Another Pilot
If another organisation approaches Favoriot today and says, “Let us run a pilot,” I will still be interested. Real world testing remains extremely useful, particularly in IoT where laboratory conditions rarely represent what actually happens at a customer site. But my enthusiasm is now accompanied by many more questions.
Before committing significant resources, I would want to understand the operational problem, its seriousness, who owns it, who will use the solution, who controls the budget and who has authority to approve deployment. I would ask what success looks like, what business outcome is being measured, whether there is a budget after the pilot, how procurement could happen and what circumstances might still prevent the organisation from proceeding.
I would not expect perfect answers. Large organisations are complicated, and government projects often involve long budget and procurement cycles. What matters is whether there is a believable commercial path beyond the experiment.
The answers help me distinguish between two opportunities that can look almost identical at the beginning: a pilot designed to explore technology and a pilot designed to become an operational project.
Both have value, but they should not be confused.
Perhaps the Real Pilot Is the Business Model
Looking back at Raqib and the Favoriot smart city project, I realise that we were testing much more than technology. Without fully recognising it at the time, we were testing timing, market readiness, customer commitment, organisational priorities, procurement realities and our own assumptions about how technology moves from experimentation into daily operations.
Raqib taught me that sometimes you can build something useful and still arrive at exactly the wrong moment. The smart city pilot taught me something more uncomfortable: proving that your technology works does not prove that a commercial customer exists.
Those lessons have stayed with me.
Today, when someone suggests another pilot, the engineer inside me still becomes curious. I immediately start thinking about devices, APIs, connectivity, architecture, interoperability and what we could demonstrate. But experience has taught me to ask another question before becoming too enthusiastic:
If we succeed, what happens the morning after the pilot ends?
Will the equipment remain installed? Will the platform continue running? Will the solution become part of the organisation’s daily operations? Will somebody allocate a budget and issue a purchase order, or will everyone shake hands, take a photograph and move on to the next experiment?
After experiencing both outcomes, I no longer believe that the purpose of a pilot is simply to prove that technology works.
A good pilot proves the technology. A better pilot proves that the technology creates measurable value. The best pilot proves that a real customer is willing to keep using and paying for it after the experiment is over.
That is the difference between demonstrating technology and building a sustainable business. It took me two very different pilots to understand that difference, but it is a lesson I now carry into every new opportunity.
Have you ever completed a pilot that everyone considered successful, only to discover that the commercial project never came? What stopped it, and what would you do differently today? I would be very interested to hear your experience in the comments.
