We Can Build Anything Now. Do We Know What to Build?
Why human-centered design methods like the LUMA System matter more in the age of AI, not less.
I caught myself three weeks into building Sam, an AI admin tool for Australian builders, with a feature list that could have filled a roadmap for a 50-person team. Email drafting. Variation tracking. Subcontractor chasing. Budget reconciliation. Revenue recovery. Risk flagging. Supplier quoting. I had the tools to build all of it, and build it fast. Claude could generate working code in minutes. So I did what felt natural: I built everything.
Then I stopped and asked myself a question I should have asked on day one: do I actually know which of these things a builder in Adelaide needs first?
The honest answer was no. I had conviction, I had taste, I had a strong read on the problem, but I hadn’t validated any of it with the people who’d actually use the product. I was confusing the ability to build with the knowledge of what to build.
I’m not the only one making this mistake.
• • •
The Flood
In March 2026, Apple pulled a vibe-coding app called Anything from the App Store and blocked Replit from shipping iOS updates. The stated reason was Guideline 2.5.2, no dynamic code execution, but the subtext was louder. The App Store is drowning. Submissions jumped 84% year-on-year, driven by AI-assisted development. Indie developers who spent months on their apps now watch them disappear under a tide of near-identical wrappers with better keyword targeting and worse architecture.
The pattern is visible everywhere. As one Mac developer put it: “Legit indie apps are getting buried in search under a flood of near-identical AI wrappers. You can ship a solid utility and still lose to 10 clones with better marketing.” Another: “A lot of these vibe-coded apps hit a wall pretty quickly. The moment something non-trivial breaks, the original ‘developer’ often has no idea where to even start.”
The barrier to making software has collapsed. That’s a genuine gain. But the barrier to making good software — software that solves a real problem for a real person in a way they’d choose over the alternatives — that barrier hasn’t moved at all. If anything, it’s higher, because the noise floor rose with it.
Speed Without Direction
Here’s what I think is happening. AI tools compressed the build cycle so dramatically that the design and research phases now feel optional. When you can go from idea to working prototype in an afternoon, sitting down for a round of user interviews feels like overhead. When you can ship five features in the time it used to take to ship one, running a prioritisation exercise feels bureaucratic.
But the physics of product haven’t changed. Building the wrong thing fast is still building the wrong thing. Shipping ten features when users needed two doesn’t make users happier. It makes your product harder to use and harder to maintain. The speed increase is real, but it only multiplied our output. It did nothing for our aim.
That’s the gap. And it’s where structured human-centered design methods become more valuable than they’ve ever been.
• • •
A Quick Aside on Intuition
I want to be clear: I don’t think there’s anything wrong with building V1 from gut feel. Jason Fried has spent decades arguing that you should build for yourself, that opinionated software is better software. Rick Rubin’s entire creative philosophy centres on trusting your internal signal, leaning into what excites you, following the energy before you can articulate why.
I believe that. Conviction-driven building produces things with a point of view, and products with a point of view tend to be the ones people actually care about.
But Rubin also talks about the “seed phase,” collecting inputs with active awareness and boundless curiosity before committing to a direction. And Fried, for all his contrarianism, builds at Basecamp with a small team that uses their own product daily. That is user research. It’s just embedded so deeply into the process that it doesn’t look like research.
The question isn’t whether to trust your instincts. It’s whether you’ve earned the right to trust them on this particular problem, and whether you’re checking those instincts against reality at the moments that matter.
• • •
Enter the LUMA System
The LUMA System is a framework of 36 human-centered design methods, distilled by the LUMA Institute from over a thousand known design innovation methods. They’re organised into three fundamental skills:
Looking: Observing human experience Interviewing, contextual inquiry, fly-on-the-wall observation, think-aloud testing. Methods for stepping outside your assumptions and watching how people actually behave.
Understanding: Analysing challenges & opportunities Affinity clustering, stakeholder mapping, importance/difficulty matrices, problem tree analysis. Methods for making sense of what you’ve observed.
Making: Creating & testing solutions Storyboarding, rough & ready prototyping, creative matrices, concept posters. Methods for generating ideas and putting them in front of people.
LUMA’s creator, Chris Pacione, describes them as “design thinking’s equivalent to the periodic table, elemental methods which can be combined in thousands of different ways to tackle just about any work challenge.” Each method has a physical card: 5×3 inches, with a photo of the method in use, a short description, a quick guide, and helpful hints. You lay them out on a table and sequence them into a plan.
What makes this framework stick, and what makes it relevant right now, is that it treats design as a discipline, not a process. There’s no prescribed sequence. No twelve-step funnel. You pick the methods that match your situation and combine them. Three cards for a quick validation sprint. Eight for a deep discovery project. One card on its own when you need a focused answer to a focused question.
Combos That Work
The power is in the combinations. Here are a few sequences I’ve found useful at different stages of building Sam, and that translate to any product:
Early discovery: Contextual Inquiry → Rose, Thorn, Bud → Affinity Clustering Observe users in their environment, capture what’s working / broken / promising, then sort findings into themes. You walk out with a prioritised map of real pain points instead of a list of guesses.
Scoping an MVP: What’s on Your Radar? → Buy a Feature → Importance/Difficulty Matrix Have users rank what matters to them, then force trade-off decisions with play money, then plot the survivors by feasibility. What’s left is what you build first.
Ideation: Statement Starters → Creative Matrix → Visualise the Vote Reframe the problem as a design prompt, generate solutions across multiple dimensions, then let the team vote. Prevents the loudest voice from picking the direction.
ValidationL Rough & Ready Prototyping → Think-Aloud Testing → Heuristic Review Build something scrappy, watch users try it while narrating their thoughts, then audit it against ten usability heuristics. Fast, cheap, and devastating to bad assumptions.
Post-launch: Journaling → Bull’s-eye Diagramming → Abstraction Laddering Have users log their experience over time, rank features by actual importance, then zoom out to ask whether you’re solving the right problem at the right altitude.
None of these combos take more than a day. Most take a few hours. The investment is negligible compared to the cost of building and shipping the wrong feature, which, with AI-assisted development, you can now do at breathtaking speed.
• • •
With Sam, I’m pulling back. Instead of shipping the full feature set, I’m running a lightweight version of the second combo above: get five builders in a room, give them play money, and ask them to buy the features they’d actually pay for. The variation tracking I assume is the killer feature? It might not be. The email drafting I’ve been treating as a minor convenience? It could turn out to be the thing they’d pay the most for.
That’s the point. I don’t know yet, and I won’t until I sit down and ask. The speed increase from AI is real, but it only multiplied my output. It did nothing for my aim. Now more than ever, I need methods that sharpen the aim.
The Argument for Discipline
We’re at an inflection point. The tools to build production-quality software are available to anyone with an idea and an API key. That’s extraordinary, and the creative possibilities are real. But the App Store is filling with proof that building power alone doesn’t produce good products. Apple is literally pulling apps from the store and blocking development platforms.
The response shouldn’t be to slow down. It should be to pair the new speed with the kind of human-centred rigour that ensures you’re building something worth building. A deck of 36 method cards and the discipline to use three or four of them at the right moments can be the difference between adding to the flood and making something that matters.
Build from intuition. Ship with conviction. But check your aim before you fire. The tools have never been better. Make sure your direction is too.
