Eight builders. One sharper standard.

The first NavAIgate Build Challenge started with a simple provocation: could you turn an unfamiliar warehouse into something a business leader would trust, without hiding the hard parts off-stage?

The fictional company was Aurelia Cloud. Its warehouse contained eight connected tables and roughly 688,000 rows across accounts, subscriptions, usage, support, pipeline and NPS. The builders had to make that data conversational, then turn the conversation into commercial insight and a presentation. Both the in-browser deck and the PowerPoint had to be created by the application at runtime. A screenshot pasted onto a slide did not count.

Why make the brief so demanding?

Because an AI demo is easy to flatter. Give it one polished path, one rehearsed question and one forgiving user, and almost anything can look intelligent for three minutes. A product has to survive the bits between the screenshots: empty states, slow model calls, broken queries, user isolation, provenance, editable outputs and deployment drift.

So the brief combined eight requirements that usually live in separate prototypes:

That combination changed the nature of the work. Builders could not optimise only for the model, only for the interface or only for the architecture. They had to make a whole system cohere.

What did the judging reveal?

Tom won. Eric placed second with a captured score of 91.5. The call also recorded Richard at 88, Ronaldo at 86.5, Fred at 83 and Kisa at 81. Matt's reference-grade entry arrived after the deadline and was reviewed for feedback rather than the prize. Andres completed a working entry, but the call record did not preserve his final number.

That last sentence matters. We are publishing what the evidence supports, not manufacturing a neat leaderboard after the fact. The useful part is not false decimal precision. It is what each build did unusually well, where it would break under real use, and what test should come next.

Four lessons travelled across almost every build

Grounding is an architectural decision

The strongest entries did not merely instruct a model to be accurate. They narrowed where numbers could come from. Some used allowlisted SQL, some validated chart fields against returned columns, and one made the language model an optional narrator over deterministic analysis. The pattern was consistent: the fewer opportunities a model had to invent a number, the more confident the product felt.

Waiting is part of the interface

AI products have variable latency. A blank screen during a query or deck build is not neutral; it asks the user to guess whether the system is thinking, stuck or broken. The best builds made the work visible with streamed reasoning steps, query status, skeletons or a clear build sequence.

An output is only useful if the next person can use it

The PowerPoint requirement became the easiest separator in the whole brief. A beautiful screenshot inside a slide is still a dead artefact. Native charts, editable text and clean lineage turn a generated deck into something a salesperson, analyst or executive can continue working with.

Local completion is not product completion

Several of the most important review findings lived outside the happy path: an unavailable repository, ephemeral storage, a public data route, a gallery seeded with mock content, or a live version that did not perfectly match the reviewed code. “It works on my machine” is a development milestone. It is not the finish line.