The Best Question to Ask a Dev Shop Isn't About Features. It's How Soon You'll See It Move.

By the end of the first real build week on a recent project, the founder could open a single link, type a name into a form, pick a couple of colors, set a level with a dropdown, and watch the page in front of them rearrange itself as they did it. Nothing was "done" in the way a spec would recognize. The experience was rough in a dozen places. But the thing that mattered was already true. The founder could see the product respond to their own input, on a live URL, without waiting for us to schedule a demo or narrate a screen recording.

That moment is worth more than it looks, and most founders don't know to ask for it.

When people evaluate a shop to build their MVP, they lead with two questions: what will you build, and when will it be finished. Reasonable questions. They're also the two questions that tell you the least about whether the next three months are going to go well. A better one, the one that actually predicts how the build will feel, is quieter. How soon will I be able to open a link and watch it move?

The feedback loop is the first deliverable, not a feature

There's a version of an MVP build where the shop takes your requirements, disappears for six weeks, and comes back with something polished to show you. It demos beautifully. Then five real users touch it and it falls over, and you're now six weeks and a chunk of your budget into a direction you can't easily change. You bought a demo of a demo, and you found out too late.

The alternative doesn't start with features at all. It starts with plumbing that no founder ever asks about because no one tells them to. Before we build the first real screen, we stand up the code repository and wire it to hosting so that every single change produces a fresh preview on a live link. It's unglamorous. It doesn't show up in a feature list. And it's the difference between a build you can watch and a build you have to trust blindly.

Once that loop exists, the whole relationship changes. You stop waiting for demos. You open the same link we're working against, you poke at the newest thing, and your reaction becomes the next day's work instead of a note in a document that gets addressed in a month. The environment is what turns a six-week build from a black box into a running conversation.

What "seeing it move" actually requires

Notice what's not on this list: a finished product. Seeing it move in week one is not about having features done. It's about three things being true early.

First, a live URL that updates on every change. Not a staging site someone refreshes by hand on Fridays. A link that rebuilds itself the moment code changes, so what you're looking at is always current.

Second, a real slice of the core, not a clickable mockup. There's a meaningful gap between a screen that looks like it works and one that actually does something when you touch it. A customizer where your inputs genuinely change the output, even if the output is ugly, tells you the engine underneath is real. A prototype that just advances to the next pretty screen tells you nothing you didn't already know from the pitch deck.

Third, you in the driver's seat. The point isn't that we show you progress. It's that you cause it. You type the name. You change the color. You set the level. The product answers you directly, and you learn more in ninety seconds of doing that than in an hour of watching us present.

A good first week also quietly nails the boring stuff that would blow up later if it were wrong. On that same project, before anyone got precious about the reading experience, we confirmed the exact print page size the artwork had to hit and cleared that the display font was actually licensed for commercial print. Those are the kinds of details that don't feel like progress and absolutely are. They're the reason the pretty version, when it arrives, doesn't have to be torn apart.

Why the loop protects your money

A feedback loop compounds in your favor. When you can react in the first week, the wrong turns get caught while they're still cheap to fix. A misread requirement costs an afternoon on day four. The same misread requirement, discovered in a big reveal at the end, costs a rebuild and an awkward conversation about the timeline.

The founders who lose the most money on a build are almost never the ones who picked the wrong feature. They're the ones who couldn't see anything until it was expensive to change. Their runway got spent on a direction nobody could correct in time, because nobody could look at it until it was too far along. Every week you can see and steer is a week your money is buying something you can actually verify. Every week you can't is a week you're paying on faith.

This is why we treat "how soon can you see it" as a first-class part of the plan and not an afterthought. It's not generosity. It's the cheapest insurance policy on the build, for you and for us. We would much rather find out in week one that we read something wrong than defend a beautiful demo in week six.

Ask the question

The next time you're sitting across from a shop that wants to build your product, let them finish the part about features and timelines. Then ask the question that actually tells you something. How soon will I be able to open a link, change something, and watch it respond?

If the answer is "we'll have a demo ready for you in a few weeks," you've learned that you're buying a black box and hoping. If the answer involves a live link in the first week, a real interaction you can drive yourself, and a build you can watch the whole way, you've found people who plan to be accountable to you in public, every day, from the start.

Features are what you'll argue about later. The loop is what determines whether those arguments happen while they're cheap. Ask about the loop first.