On the cheapness of ideas
If execution is everything, what happens when execution gets cheap too?
I was touring a gym on 14th St in Manhattan that I was considering joining when during some over-familiar banter the rep showing me around learned that I’m a software engineer, and he switched from his membership pitch to a more conspiratorial tone: “I have this idea for an app …”
It was the early 2010s when smartphones were still relatively new. It was not uncommon back then for friends and total strangers alike to seek my support for their idea, thanks to Steve Jobs who had recast software for them as apps, tangible little widgets that live on a glass pane in their pocket.
I don’t remember how I fended off the gym rep but I know what I would have been thinking while saying something more polite: Ideas are cheap. To this day I find an occasion to think it or even say it out loud at least once per month, usually in the context of startups: Ideas are cheap. It bears repeating often because it is such a counterintuitive notion to those who have no hands-on experience in either entrepreneurship or scientific discovery (and have been raised on misleading stories of eureka moments that result in history-altering inventions1).
What is meant by the cheapness of ideas in startups is that, fundamentally, by the time an idea has been expressed well enough to form a business around it many others will have considered the very same idea, and if not, they could certainly trivially steal it now. Not to mention, many ideas are bad, most are obvious and the truly original ones are those most likely to be dismissed out of hand.
In defense of my gym rep, he did intuit the punch line that often follows: Ideas are cheap — execution is everything.2 He knew that he couldn’t create his app himself and needed somebody to execute at a technical level. I bet he was still underestimating everything else that goes into successful execution though, product sense, go-to-market strategy, human capital, financial capital, perseverance, good timing and a dose of luck.
Another cheap idea
I’d been hatching an idea while I was traveling over Christmas and New Year, and like any half-decent and therefore cheap idea it’s easily explained: GeoGuessr but for code in GitHub — a game where you are dropped into a random location of a public GitHub repo with a few lines of code masked that you have to guess to score points.
So it’s a game but it’s not entirely frivolous. It’s designed to playfully train the reading of code, the quick orientation within unfamiliar code, the exact skill that I think will be critical for any programmer in the AI era. In contrast to traditional competitive programming games that I’m aware of it actually prepares the player for the real world because it operates on real code rather than synthetic problems.
I sat down to develop the game when I got back home in the second week of January. It’s now reached a state where I can open it up to play testers: I give you GitGuessr.
For now you’ll need an invite code to play. As a trusted reader of this newsletter you may use this invite code: NGOOF
GitGuessr differs from the small projects I’ve documented in this newsletter so far. I felt the idea warranted more than a simple prototype. It has a lot more technical complexity, a highly interactive game UI, user authentication and substantial use of external APIs. It’s not throwaway code; it has good test coverage and it’s production quality, in the sense that it could scale up to hundreds of thousands if not millions of users right now.
In the pre-AI era I would have estimated a project like that at 2 months of full-time work, as an experienced engineer going at it alone. Instead, with the assistance of Claude Code (Opus 4.5) it took me less than 2 weeks. I cannot overstate the productivity boost I get from Claude, especially in areas where I don’t have a lot of expertise, i.e., frontend engineering.3
Cheap execution
If execution is everything, what happens when execution gets cheap too? The typical tech startup founder lies awake at night and worries that somebody will copy their (cheap) idea and beat them in the open market. In the past, since execution was everything, this was an unfounded worry most of the time. I’m not so sure anymore now. A major part of execution, the software engineering bit, has become significantly less demanding in time and people. I think this is a seismic shift, the impact of which we barely understand yet.
Just as there is a serious business in GeoGuessr (subscription model, reportedly 40M+ users, currently 200K+ daily actives in competitive leagues), there is a potential serious business in GitGuessr. But the reality is, anybody with my level of skill can recreate the core of GitGuessr from scratch within a 2 week break from their regular job or over a few weekends, where previously they would have needed to set aside at least a couple of months. If I were to get serious about this, I’d need to shift focus from coding to business development and designing moats pretty quickly.
More emphasis on traditional moat construction right out of the gate is certainly one consequence of newly devalued execution. I’ve been following GeoGuessr since before they blew up during the pandemic, so absorbing lessons from their history there are three types of moats to consider:
Data: Fun game play depends on a large cache of suitable code locations, of varying programming languages and varying difficulty levels. I have already figured out that collecting those locations is very time and/or capital intensive.
Distribution: Stressing the genuinely educational aspects of the game, exclusive partnerships with schools and coding bootcamps can hook players young and en masse.
Network effects: GeoGuessr truly took off once they introduced multiplayer game modes with an inherent network effect, duels, battle royale and eventually leagues.
An obvious product feature that cuts across all of these is the ability for users to create their own “maps”, collections of code locations that they and others can play. GeoGuessr supported this early on and in my estimation it was critical in building the community around it. I’m at least implementing that before launching GitGuessr in some public fashion. How much energy and conviction I have to dig some moats after that I don’t know yet.
That gym rep with the app idea? Rather than chatting up random software engineers he is now probably vibe coding his personal lifting app, or whatever it is he wanted to create. And so he should! I love that for him.
Subscribe above for more of my explorations of how AI is impacting software engineering, always rooted in real code or at least prototypes that you can play with yourself. I’m afraid next up you’ll be subjected to at least one more update on GitGuessr before I get distracted by other … ideas.
—Nik
Read Scott Berkun’s The Myths of Innovation for one of the better treatments of this topic: “Epiphanies are a consequence of effort, not just the inspiration for it.”
In this or similar form attributed to venture capitalist John Doerr, though I have a hard time tracking down the original quote.
I hadn’t written any serious React code until a couple of months ago and certainly nothing as involved as this. To be clear, GitGuessr is not vibe coded, it’s too complex for that. But Claude Code did generate most of the code, mostly in small chunks which I reviewed and edited before merging, in order to end up with a maintainable codebase.