It’s 5pm. My event starts in an hour.
Plenty of time to build an app, right?
I’m currently exploring a new project idea. Still early, still messy.
One of the most common pieces of advice when building a product is to validate early by talking to potential users.
So I thought: why not use this networking event to start?
The problem is, walking up to people and asking them to answer questions about your idea can feel awkward.
I wanted something lighter. Something that would make the interaction feel natural instead of forced.
So I built a simple app.
A spin-the-wheel game where people could either:
- win a prize
- or answer a short survey
It may or may not have been slightly rigged 🤫
But the goal wasn’t the prize.
It was to create a moment.
A small interaction that lowers the barrier, gets a smile, and opens the door to a real conversation.
And surprisingly, it worked.
It made approaching people easier, sparked a few genuinely interesting discussions, and helped me collect my first real signals on the idea.
The quick technical setup
I used:
- ChatGPT for ideation
- Codex for implementation
Stack:
- Expo
- React Native
- TypeScript
- React Navigation
- AsyncStorage
Here is me setting the content with Chat:
After the ideating, I find it useful to generate the prompts for Codex from Chat so I can just paste them over sequentially:
Then the implementation happens with Codex:
The app itself was simple:
- wheel screen
- short survey
- responses view
- profile screen with a QR code for LinkedIn
Expo Go was what made this possible in such a short time. Instead of building a full native app, I ran the Expo dev server locally and opened the project on my phone through Expo Go.
In practice, Expo Go provides the native container, while my app code is loaded as a JavaScript bundle from the local development server. That meant I could build and test the app on a real device almost instantly, without dealing with native build setup.
For a low-stakes prototype like this, that tradeoff was perfect:
fast iteration, real-device testing, and just enough functionality to get the job done.
Here is a quick visual recording of the app itself:
Learnings from this experience
For me, this is a great use case for vibe coding: building a very low-stakes prototype that solves a simple problem and can be put together quickly.
It also reminded me that small tools can make everyday situations more interesting. Sometimes the best projects are not the most ambitious ones, but the ones that make a real interaction easier, lighter, or more fun.
Discussion
How do you approach networking in a more natural way?
Do you have any original tactics/stories to collect customer interviews?
And how are you using vibe coding in your day-to-day?
I’ll introduce the project I am ideating for in my next post, document the learnings as I go, and eventually open-source the project so others can learn from it, reuse it, or take it further.
If you had to guess, what do you think this project is about?
Curious to hear your thoughts 🙂
Top comments (6)
Interesting to read how you approached this: doing the ideation in ChatGPT, but also having ChatGTP generate the prompts for Codex!
Maybe/probably this works well because both tools (ChatGPT and Codex) are from the same company (OpenAI) ?
Yes I am sure there are many synergies there.
The combo works well because it plays on each other's strengths:
ChatGPT is a better prompt compiler and Codex performs best when given clear, specific instructions.
This is why I use ChatGPT for thinking and Codex for building.
Yeah I found that illuminating, pretty simple approach but seems to work well !
I like it when I see these simple tricks/patterns/rules of thumb within the "AI Coding" debate, rather than very complex and esoteric setups with MCP and whatnot, which are often hard to set up or to get working well - approaches which aren't complex or "high tech", but which are practical - call it "out of the box" thinking ...
I agree! I am tinkering and fine tuning as I go along, but this setup has been working nicely in the past weeks for me when it comes to prototyping and side projects.
I have used Claude in the past at my previous company but I was curious to try Codex to compare. Both feel similar. I noticed Claude tends to think longer and is better at big architectural changes.
Codex tends to execute faster, hence feeding it multiple scoped and clear prompts works best. They also released Codex Spark which is lower latency, very fast and convenient for quick troubleshooting and iterating on smaller changes. So I would make the bigger architecture changes with Codex and switch to Spark for simpler tasks.
The whole AI Coding thing is itself becoming an area of expertise, but the problem is that things change so fast, so when you're an "AI Coding Expert" it should be more about the abstract problem solving skills than about memorizing facts about tools X, Y or Z - because that detailed knowledge can be outdated in a month ...
It just requires an open mind an a willingness to experiment.
But yeah, Claude Code is known for its ability to "go deep" on architecture.
Very true!