Like many people, I recently thought I had the idea: an app that gives you a condensed version of any podcast you are listening to and keeps you up to date on whatever topics you care about.
Instead of scrolling through Instagram in the bathroom, you would scroll through useful, curated information drawn from all the podcasts, YouTube videos and articles you keep meaning to consume but never have time for.
So I gave myself a weekend to build it.
Plot twist.
I didn’t end the weekend with the curated platform I had imagined. I did, however, learn quite a lot.
1. It is remarkably easy to get lost in the visuals
I spent an entire evening trying to get the background image right, choosing a font that looked suitably impressive and making sure the colours matched the atmosphere I was going for. There were hours of back and forth with ChatGPT generating images, reading about typography and testing different combinations.
Almost none of it mattered at the stage I was at.
The app didn’t need to look good yet. It needed to work, and I needed to establish whether the idea was actually useful. Even though I knew that, I still spent most of the evening polishing it.
Vibe-coding tools make it possible to produce something functional and visually convincing extremely quickly. That makes it dangerously tempting to move straight into aesthetics and mistake visible progress for meaningful validation. The easier it becomes to make something look finished, the more discipline it takes to ask whether the underlying idea actually works.
Which leads to my second point.
2. The medium no longer tells you how finished something is
My app looked finished and, in a narrow sense, it worked. You could enter content, generate condensed information and move through a polished-looking interface.
But using it made me realise that a feed of summaries wasn’t necessarily the same thing as a genuinely curated view of a topic.
What should the app include? What should it leave out? How should it decide that one source matters more than another? How would it distinguish between useful repetition and several sources saying essentially the same thing? And how to make the whole process automated rather than having to paste the links?
This became much clearer once I could interact with the idea rather than merely describe it. On paper, “an app that condenses everything you want to keep up with” sounded coherent. In practice, it was much more difficult and I recognised that my idea still had some gaps I hadn’t figured out in order for it to become useful for me.
A functioning application used to be a reasonable indication that a product had reached a certain level of maturity. Building one required enough time, money and technical effort that it was fair to assume a significant amount of thinking had already happened behind it.
That assumption is becoming less reliable. With vibe coding, something can resemble a finished product while still being an early hypothesis.
This isn’t necessarily a weakness. Building the app exposed holes in my thinking that might have remained hidden in a product requirements document. I could experience it from a user’s perspective and see where the idea became repetitive, confusing or incomplete.
That experience made me think differently about the role of prototypes. A functional prototype is becoming a medium for communicating product ideas, not just a stage in the engineering process. Rather than relying entirely on PRDs and static documentation to describe an intended experience, teams can create an interactive artefact that people can explore, criticise and revise.
The prototype doesn’t replace the thinking, however. Teams still need a clear vision, a strategy and an understanding of their users. The prototype reveals what works and what doesn’t; documentation captures those discoveries and records why decisions were made.
Without that discipline, it is easy to keep “improving” a product without knowing whether it still aligns with the original vision or the goals of the business.
3. You pick up technical concepts along the way
Would I describe myself as technical? No. But I know considerably more now than I did before.
I learnt how to put code on GitHub. I also learnt that putting code on GitHub and successfully hosting an application are two very different things. I also learnt why it is important to put code on Github.
More importantly, I have started to understand a little bit the changes that coding tools propose. I now ask Claude/ Codex to explain what it intends to do and to check with me before editing files or running commands. Rather than blindly approving every change, I try to understand what is being altered, why it is necessary and what might happen as a result.
That process has taught me more about programming than simply watching the app appear. I am beginning to recognise which files are being changed, what a command is likely to do and what I am actually agreeing to when I approve it.
Now what?
The weekend didn’t prove the idea was brilliant but rather it proved that the idea still had several unanswered questions and needed more scoping. The thing I thought I wanted turned out not to be the thing I wanted. I thought I wanted a working app. I thought I had a solid idea and a use case that I was eager to build for myself. But in the end, building the app allowed me to actually understand my own idea better and face the gaps in my own proposal and thinking. It reminded me to explore and focus on the why and the value a product or feature brings, rather than build things for the sake of building (as much fun as that is!). And along the way, while I was figuring all that out, I had a fun tool to help with that.
So it’s back to the drawing board for me, focusing on the rough edges and what isn’t working, and bringing all of it into v2.