1 hour, 1 idea, 1 working product

Last Friday I was at the Go-to-Market Builders AI Build Lab in Singapore, co-hosted by Build Club, Singtel, and SMU AI. One hour. Solo. From scratch.

Here is what I built, how I built it, and what actually went wrong.

The idea

My mum asked me to find a vegetable chopper for her.

I opened Amazon. Scrolled through the listings. Watched a few Tamil YouTube review videos. Checked the reviews on the shortlisted ones. Came back Friday morning and still had not placed the order.

The problem was not that I could not find options. There were too many. The problem was that I could not reach a confident decision. Too much noise, too little signal. No way to apply her specific constraints — elderly users, easy to clean, dishwasher-safe, not full of food-contact plastic — against the flood of marketing copy and paid review content.

So I built Shortlist: an AI buying advisor that takes a natural language query, applies remembered preferences, researches candidates, and returns a ranked shortlist with red flags per product and a recommended winner.

The tagline I wrote in the PRD: Amazon gives options. Shortlist gives confidence.

The approach: specs first, parallel tracks second

Most people working under time pressure go sequential. Design the thing, then code it, then maybe polish the demo if time permits. I did not do that.

The first ten minutes were specs only. PRD, data contracts, which tool handles which part of the workflow, what the demo query would be, what success looks like. No code. No design. Just clarity.

That ten minutes of upfront work was what made everything else possible. Because once the contracts were fixed, two tracks could run simultaneously without stepping on each other.

Track 1: Manus. I gave Manus some visual examples of what the landing page should feel like — not a text description, actual reference images. It produced a design.md first: a proper design brief with layout, colour, spacing, and component decisions. Then it built the page from that brief. The separation matters. “Build me a landing page” produces mediocre output. “Make a design brief first, then execute against it” produces something you can actually review and refine.

Track 2: Claude Code. While Manus was handling design, Claude Code was implementing the agents. Exa for product research and evidence gathering. Mem0 for user preferences, seeded with constraints like “dishwasher-safe”, “easy to clean”, “avoid food-contact plastic”, “durability over lowest price.” An orchestrator to discover candidates, score them against constraints, surface red flags, and rank the shortlist. A Manus verification pass as an optional independent second opinion.

Logo options came from Manus running alongside. Picked one, moved on.

When both tracks were done: merged, tested, made UX improvements, refined how listings were displayed.

The thing that broke

Exa is excellent for product research. It was not surfacing Amazon results the way I needed for the demo.

I caught it mid-build during testing. Checked the Exa docs, thought about the options, decided to add SerpAPI alongside it. SerpAPI has better Amazon integration. Wired it in, tested again, got the results I needed.

That took about ten minutes I had not budgeted for. It is the kind of thing you do not know until you test against a real query. No tool works perfectly in a 60-minute hackathon. What matters is catching it early enough to fix it.

The video

I had a screen recording of the demo. Created a storyboard. Let Sonnet generate the actual video using Remotion.

Some sections are rough. The AI-generated visual segments are visible as AI. That is the honest trade-off between polish and completion when you have a hard stop at 60 minutes. The decision to make the video at all — rather than just screensharing — was the right one for the demo context. But I am not pretending it is a production asset.

What the build actually looks like

You type: “Find a vegetable chopper for my elderly parents in India.”

Shortlist pulls your remembered preferences from Mem0. Runs Exa and SerpAPI across product candidates. Gathers evidence and reviews. Runs a risk pass for complaints, durability issues, cleaning problems. Scores each candidate against your constraints. Returns a ranked shortlist of three with a recommendation, red flags, confidence score, sources, and a memory-save confirmation.

The UX is split: chat input on the left, research dossier on the right. The dossier shows research progress live: searching products, reading reviews, finding red flags, checking fit, ranking options.

Demo: https://www.youtube.com/watch?v=7zZuLRwh9r8

Live: shortlist-web-vert.vercel.app

What I took from the night

The priority ladder. I wrote this before the build started: never cut red flags, never cut memory save, cut Manus verification first if time runs short, then cut streaming, then cut live image fetching. Having those decisions made before the pressure hit meant I did not have to make them mid-build. That is worth doing for any time-constrained project, not just hackathons.

The parallel tracks. This is not just “use AI.” It is thinking about the architecture of the build before you start: which workstreams can run simultaneously, what the dependency graph looks like, where the contract between them needs to be fixed first. The tools are fast enough that the bottleneck is usually the builder’s thinking, not the tools’ execution.

The examples-over-instructions habit. Giving Manus reference images instead of a text description, and making it produce a design brief before touching code, produced better output than a direct “build this” prompt would have. That pattern generalises. Concrete reference plus an intermediate artifact step before execution gets better results than jumping straight to the output.

The team at Build Club, Singtel, and SMU IIE put together a well-run night. Real tools, real credits, real problems to build against. The room had the kind of energy that comes from people who want to make something, not just talk about it.