Skip to content

Consulting · AI products

AI product consulting, from use case to shipped prototype

Pick the AI use cases worth building, design them around real people and ship a prototype you can test. AI product consulting from a UX-first studio.

How much should the agent do alone?

Every AI feature needs a decision about who acts. Here's how the same customer message changes as the agent gets more autonomy.

Autonomy dialIllustrative demo
Set how much the agent does alone. The task: a customer asks about a delivery date.
Customer, on WhatsAppCan you deliver my order by Friday?
Agent suggests

“Friday works. I'll confirm the time slot tomorrow.”

InsertDismiss
Draft in your reply box

Hi, Friday works. Your order ships Thursday and arrives Friday before 6 pm.

Unsure: the courier cut-off time is not confirmed.

EditSend
Waiting for your approval
  • Send the reply confirming Friday delivery
  • Book the Friday courier slot

Heads up: this is the last courier slot this week.

ApproveEdit first
Activity log

done: sent reply confirming Friday

done: booked Friday courier slot

UndoPause agent
Who sends
You
You check
Every word
If it's wrong
Nothing reaches the customer
Who sends
You, after editing
You check
The draft and its flagged line
If it's wrong
You catch it before sending
Who sends
The agent, once you approve
You check
A preview of what will happen
If it's wrong
It stops at the approval step
Who sends
The agent
You check
The activity log
If it's wrong
The customer sees it first
Read: levels of autonomy for AI agents

Every product team now has a list of AI ideas. A few of them will change how customers work. Most will ship as a chat box that nobody opens twice. The difference shows up long before the build, in which use case you pick and how much care goes into the moments where the model is unsure or wrong.

We help you choose the two ideas worth building and put a working version in front of your users. You see it perform before you commit a build budget, and you keep the reasoning behind every call.

Built for

  • A founder with a funded idea and no product team yet. You need to decide what to build first, see it working and brief the people you hire.
  • A product team under pressure to "add AI". Leadership wants a launch this year. You want a use case that earns its place in the product.
  • A company with a stalled pilot. The demo impressed the board and then nothing shipped. You need a path from pilot to something customers use.

Deliverables

  • Use-case scorecard. Every candidate use case scored for user value, risk and feasibility, including data access, cost per task and latency.
  • Jobs map. The jobs your users do, drawn from interviews or support logs, with the steps where AI helps and the steps where it gets in the way.
  • AI PRD. What the feature does, what good output looks like, the success metrics and the eval plan.
  • Designed states. Flows and UI for the full range: loading, confident, uncertain, wrong, corrected and handed to a person.
  • Testable prototype. A working prototype built with AI coding tools, tested with real users before anyone writes production code.
  • Build plan. Scope for the MVP, the open risks and a 90-day path from prototype to production.

Working together

  1. Frame. A clarity session or kickoff on the business goal, the users and the constraints.
  2. Choose. We gather evidence and score the use cases with you.
  3. Design and prototype. We design the chosen flow with its failure states and build a version people can use.
  4. Test. Real users try it. We change what they stumble on and record what we learned.
  5. Hand over or carry on. You get the artefacts, or we continue into the MVP.

Most teams start with a clarity session or a sprint. See the engagement formats for scope and pricing. We work remote and async first from Kuala Lumpur (UTC+8), with a weekly live call in the overlap window.

The craft difference

  • The failure states come first. An AI feature that looks right in the happy path and breaks in front of a customer loses that customer's trust fast. We design recovery before polish. AI error handling UX shows the patterns.
  • Real users before real code. A prototype or a Wizard of Oz test, with a person playing the model, costs a fraction of a build and tells you whether anyone wants the thing.
  • Nothing ships straight from the generator. We use AI tools to move fast, and every screen still gets a critique pass and a user check before you see it as finished.

Proof

Marcus teaches PRD-first prototyping as the named instructor of AI Vibe Coding and Rapid Prototyping at AiTraining2U, where participants build working apps in two days. More on his background is on the about page.

TBC: first consented case study for this track.

If the product question turns into "is this feature working?", the product management track picks up evals and roadmaps. If you want to learn to run this process yourself, the founders' coaching path covers it one-on-one.

Questions people ask

We already have an AI idea. Do we still need the use-case work?

Often a short version of it. We score your idea next to two or three alternatives from the same workflow. If yours wins, you go into the prototype with the reasons written down. If it loses, you found out before paying for a build.

Can you build the MVP, or only the prototype?

Both are possible. The sprint ends in a prototype real users can try. After that we can carry it forward into an MVP, or hand it to your engineers with the PRD, the states and the eval plan they need.

Which AI models and tools do you work with?

We pick per use case and prefer what your team can run and maintain. Our own prototyping uses current AI coding tools such as Claude Code, the same toolchain Marcus teaches in the AI Vibe Coding course.

Do you work with teams outside Malaysia?

Yes. We are based in Kuala Lumpur and work remote with teams worldwide, async first, with one weekly live call in the hours our time zones overlap.

How do you handle time zones?

You get a written or short video update each week, and we place the live call where our days overlap. For teams in the Americas we agree one fixed slot at the edge of both working days.

How long does it take to reach a testable prototype?

The sprint format runs one to three weeks and ends in a prototype and a test with real users. Scope sets the length, and we agree it before we start.

Next step

Tell us what you're building

Based in Kuala Lumpur, working with teams worldwide.

Book a call about AI products