Skip to content
← All writing

Build Your MVP with AI

Cursor Saudi — CODE, Riyadh Event recap
On this page

The second Cursor Riyadh event, and the first one where we mostly stopped talking. Run with Faris Hijazi, Data Science Lead Specialist at Thiqah.

The schedule was the whole design:

Three and a half hours
6:00 Introduction 30 min. Pick a partner, pick a problem worth solving.
6:30 Build 2.5 hours. Faris and I circulating, unblocking people.
9:00 Demos 30 min. Show the room what you got working.
Deliberately more building than talking. The demo slot at the end is what makes people finish something.

It was open to non-developers, which changed the character of the room considerably. Some of the best demos came from people who had never opened an IDE before that evening.

What I covered before letting people loose

A short version of how these editors work, because you make better decisions once you know:

You say “make this button green.” The editor sees your code, your open files, and your request. The model predicts what change fits the patterns it’s seeing. You get a diff back.

The secret, such as it is, is that context determines quality. Include the files that matter. Say what you’re actually trying to do. Paste the error text rather than describing it. Provide an example when you have one.

Then the features people don’t discover on their own — Tab for multi-line cross-file autocomplete, Cmd+K for inline edits in natural language, and the chat modes: Agent for autonomous multi-file work, Ask for understanding without editing, Manual for tight control, Custom for your own workflows. Plus rules files, docs indexing, checkpoints, and MCP for external tools.

Memory Bank, again

I ran the Memory Bank session again here, because for a three-hour build it matters more, not less.

The pattern: keep human-readable markdown in the repo describing what the project is, how it’s built, and where you got to. Plan with an expensive reasoning model, execute with a fast cheap one, start every task in a fresh chat, review the git diff rather than the conversation, and update the files before moving on.

In a hackathon setting the payoff is immediate. You will hit the point where the agent has lost the plot, and the fix is a new chat plus a file that explains the project — not another paragraph of increasingly desperate prompting.

What actually happened

People shipped. Not polished things — a few had visible bugs during the demo — but working ones, built in an evening by people who mostly hadn’t done this before.

The framing I kept repeating: ship something functional, not something perfect. Two and a half hours is enough for the first and nowhere near enough for the second, and knowing which one you’re aiming at is most of the skill.

Mazen Alotaibi (@ma7dev)