What's the fastest way to see if an idea will actually work?
Build the riskiest part first as a working demo, not the easiest part as a polished screen. If the idea depends on an integration behaving, prove the integration; if it depends on people using it, put something clickable in front of them within days.
The first VX-N deliverable — a plan, a mock, or a working demo — lands within 24 hours of the first call, precisely because arguing about a specification in the abstract is slower than looking at something real. People cannot react accurately to a description; they react precisely to a screen. Half of what a demo produces is not validation but correction — 'that's not what I meant' arriving in week one, when it costs a conversation, instead of month three, when it costs a rebuild.
Ranking by risk is the skill. The riskiest part is whichever assumption kills the idea if it is false: sometimes technical — will the vendor's API return the data we need, will extraction be accurate on our real documents; sometimes human — will clients actually upload files themselves, will reps enter the data. Building the easy part first produces motion without information; you end a month with a login page and the fatal question still open. A demo that fails in week one is a cheap and genuinely good outcome. The expensive version is finding out in month five.
Be disciplined about what the demo must prove versus what it can fake. Real: the risky integration, the core action, real data from your operation — canned data hides exactly the mess that kills systems in production. Fake or skip: visual polish, settings, admin screens, every edge case. A demo is an experiment with a question attached; write the question down before building — 'will this parse our supplier invoices?' — or the demo drifts into a small, unfocused product.
This is also where AI has most visibly changed the work. A working demo — real screens, real logic, wired to a real system — now takes days, roughly ten times faster than the pre-AI norm, which quietly overturns the old validation playbook. When demos cost weeks, you economized with slide decks and mockups; when a demo costs days, testing the real thing is usually cheaper than describing it, and the mockup stage can often be skipped entirely.
One warning made cheap by that speed: decide in advance whether the demo is scaffolding or foundation. Demos get promoted into production by enthusiasm, and code written to answer a question is rarely built to carry permissions, failure handling, and real volume. The honest move is to treat the demo as the proof, then build the system properly on what it proved — at current build speeds, that discipline costs days and prevents the brittle-system tax that lasts years.
Last reviewed 28 August 2026