Your First Product Is Not an Incomplete Version. It Is a Question to the Market.

This post is a translation of the original Arabic article.

Over the past few days, the launch of HudHud, a Saudi mapping application, has sparked a lively debate. Some celebrated it as an ambitious Saudi product. Others immediately compared it with global platforms that have spent years building their maps, data, and user networks, then judged it based on their first experience.

I am not here to evaluate HudHud or defend every aspect of it. What interests me is the larger question this debate has exposed:

How should we evaluate a product when it first enters the market?

Should we treat it as the final expression of the founder's vision? Or should we see it as the first practical question the team is asking the market?

Some founders delay launching until the product appears complete. Others release an early product, then present it as though they have already crossed the finish line. In both cases, the same confusion appears: the difference between the ultimate vision and the first instrument of learning.

A first product is not a smaller version of the dream, nor is it a declaration of victory. It is the fastest credible experiment designed to test the riskiest assumption behind the venture.

HudHud Does Not Need a Final Verdict Yet. It Needs a Clear Test.

When a Saudi mapping product enters a market dominated by mature global platforms, the least useful question is:

Is it already better than Google Maps?

The more important questions are:

• Are there local problems that global mapping platforms do not address well enough?
• Does the Saudi user value a different understanding of entrances, intersections, addresses, and local details?
• What would persuade someone to try a new application and then return to it?
• Where can a local product build an advantage that a global platform may not notice or prioritize?
• Can that advantage become a sustainable product and a scalable business model?

Pitch decks cannot answer these questions. Neither can the excitement or criticism surrounding launch day. They are answered by user behavior and by the team's ability to turn feedback into improvements.

The market may reveal that the real value lies in everyday navigation. It may instead be found in local location data, mapping interfaces for businesses, or services for sectors that require greater geospatial precision. HudHud's website presents services for users, while its developer platform offers mapping and data services for businesses and developers. Which of these paths will become the company's core? Only the market can answer.

HudHud's success will therefore not be determined by the applause it receives or the severity of the criticism it faces in its first week. It will be determined by its learning and improvement curve after launch.

The Size of the Claim Should Match the Maturity of the Product

There is a difference between saying:

We are building a Saudi mapping platform. This is the first version, and we want to improve it with our users.

And presenting the product on day one as a complete alternative to a global platform.

The bigger the claim, the higher the standard by which people will judge it. When the public narrative runs ahead of the product's maturity, people no longer see a promising experiment that needs time to learn. They see an unfulfilled promise.

What we did see from HudHud was an impressive ability to fix errors quickly — and that counts for a lot.

The launch itself is part of the product experience. If the product is still at an early stage, users should know:

• What works today?
• What does the product actually cover?
• What is still under development?
• How can they submit feedback?
• When will they see the effect of that feedback?

Transparency does not weaken trust. It prevents expectations from outrunning the product's capabilities.

Supporting a national product does not mean denying its shortcomings. Criticizing it does not mean demanding that it be born with the scale and maturity of a global company. Real support gives the product room to learn. Useful criticism helps the team decide what it must learn first.

What Question Do We Want the Market to Answer?

Every company begins with a set of assumptions:

• The problem exists and is painful.
• The user is looking for a solution.
• The proposed solution is understandable.
• Someone is willing to pay.
• Reaching the customer is possible.
• Delivering the service is economically and operationally viable.

But these assumptions do not carry equal weight. Some may already be well established, while the entire venture may depend on a single untested hypothesis.

A good first product does not try to prove everything at once. It identifies the assumption that would undermine the entire venture if proven wrong, then designs the fastest experiment capable of producing an honest answer.

Before launching, the team should know:

1. Which assumption are we testing?
2. Who is the target segment?
3. What behavior would count as evidence?
4. What metric and time frame will we use?
5. What decision will change based on the result?

If you do not know which decision the experiment could change, you are not testing. You are showcasing.

AI Has Shortened Build Time, Not Market-Understanding Time

In the past, a founder needed a team, considerable time, and a meaningful budget to turn an idea into a product that could be tested. Today, AI tools can build complete features, understand a codebase, fix bugs, run tests, and work on several tasks in parallel. This is the direction represented by agentic software engineering tools such as Codex and others.

In some cases, work that once took months can now take weeks. What took weeks can sometimes be completed in days.

But this speed does not answer the harder question:

What is worth building in the first place?

AI can help you build the answer faster, but it cannot guarantee that you asked the right question. It can even help you produce unwanted features more quickly, or build a polished product around the wrong assumption at a lower cost.

AI has not made the first product obsolete. It has made it more important for two reasons.

First, the cost of experimentation has fallen. Waiting too long to test an assumption is therefore harder to justify.

Second, the market itself is changing faster. As everyone's ability to build accelerates, assumptions expire sooner, and early learning becomes a competitive advantage.

Execution used to be the scarce resource. Increasingly, the scarcity is shifting toward the quality of judgment: choosing the right problem, understanding the context, framing the hypothesis, and reading what people do rather than relying only on what they say.

This Is Where the Entrepreneur Becomes More Valuable

It may seem that making software easier to build would reduce the importance of the entrepreneur. I believe the opposite is true.

When execution tools become available to everyone, the person who deeply understands the problem and can bring its different parts together into a viable solution becomes more valuable.

A good entrepreneur is not simply someone with an idea, nor are they necessarily the person who knows every technical or specialist detail. Their advantage is learning to see the problem as a complete system:

• Who is genuinely affected by it?
• Who makes the purchasing decision?
• Why have existing alternatives failed to solve it? (Critical to understand)
• What change in user behavior is required?
• What are the technical, regulatory, and operational constraints?
• What incentives drive each party?
• How can the solution sustain itself economically instead of remaining a temporary initiative?

In this sense, entrepreneurs are among today's most important experts on problems. Not because they know the answer from the beginning, but because their real work is to turn the knowledge of users, specialists, data, and the market into a solution that can learn and evolve.

In healthcare, for example, understanding the technology is not enough. You must bring together the patient's needs, the practitioner's judgment, clinical safety, regulation, payment, and operations in one sustainable experience. AI may accelerate the construction of the platform, but it cannot design this balance on its own.

The Business Model Is Part of the Solution, Not Merely a Way to Collect Money

Many people separate "solving the problem" from "building the business model," as though the first were noble and the second merely commercial. But a problem without a mechanism that sustains its solution will return as soon as the funding or enthusiasm runs out.

A good business model answers the questions that determine whether the solution can endure:

• Who pays, and why?
• Are the beneficiary and the buyer the same party?
• Does the revenue support service quality and continued development?
• Does the value improve as usage grows?
• Are the company's incentives aligned with the user's interests?
• Can the solution scale without compromising quality?

Innovation is not complete when we build a product that works technically. It becomes complete when we build a system around it that allows it to survive, improve, and reach more people.

A competitor may copy a feature you built with AI in a few days. It is much harder to copy your accumulated understanding of the problem, the trust of your users, your distribution channels, local data, operations, and the business model that connects them all.

The Smallest Product Is Not the Worst Product

Launching early does not mean releasing whatever you happen to have. If the experience is so poor that users cannot see the value, you are testing their tolerance for poor quality, not their interest in the idea.

The better questions are:

• What is the smallest experience that preserves the core value?
• What can be performed manually behind the scenes?
• Which features do not affect the hypothesis?
• What level of quality or safety must never be compromised?

In a healthcare service like Cura, a first product does not mean reducing clinical safeguards or privacy protections. You can limit the number of cases, service hours, or user segment while preserving safety and regulatory compliance.

Reduce the scope, not the user's rights.

In a mapping product, the team might begin with one city, one use case, or one segment. It should simply be clear about that scope and deliver enough value within it for the hypothesis to be tested honestly.

Behavior Is Stronger Evidence Than Approval

People may say the idea is excellent because it is Saudi, then never use it. Others may criticize it on social media, then later discover a feature that brings them back every day.

Excitement is not evidence of demand. Criticism is not evidence of failure.

The stronger evidence appears in behavior:

1. The user tried the product.
2. They completed the task they came to perform.
3. They returned to use it again.
4. They preferred it for a specific use case.
5. They paid for it, or an organization allocated a budget for it.
6. They recommended it to someone else.

This is what the team should read after the noise of the launch fades.

The First Product Is an Instrument of Knowledge

In the age of AI, building quickly will not be a sufficient competitive advantage because many others will be able to do the same.

The advantage is the ability to learn faster than everyone else:

• Choose a problem worth solving.
• Launch a focused, clearly defined experiment.
• Observe real behavior.
• Admit what did not work.
• Turn knowledge into improvement.
• Build a model that makes this improvement continuous.

The first product is the instrument that moves the conversation from "we believe" to "we observed," and from "the user should want this" to "this is what the user did when faced with the choice."

The fair question for HudHud, and for every new Saudi product, is not: Did it launch complete?

The question is:

Was it designed to learn, and can the team turn what it learns into a better product and a business model that lasts?

Your first product is not a promise that you have arrived. It is a direct request to the market: Show me where I am wrong.

The company that wins will not be the one that asked the perfect question on its first attempt. It will be the one that listens to the answer, learns from it, and moves faster.

Watch