How I Show You Progress Before Anything Goes Live

One of the most common worries I hear before a project starts isn't about cost. It's about disappearing for six weeks and finding out at the end. You've paid a chunk of money, and the only proof of progress is an invoice and a promise. That fear is reasonable. Software is invisible until it isn't, and a lot of people have been burned by developers who go quiet for a month and then show up with something that doesn't match what they thought they'd asked for.

So I want to explain, plainly, how I actually let you see a build as it happens, and what the difference is between a quick look and something you should treat as real.

A quick preview isn't the same as a staging environment

There are two different things people mean when they say "can I see it?"

The first is a quick look at something running on my own machine while I'm actively working on it. Modern tools like Cloudflare Quick Tunnels make this easy: they take whatever's running on my laptop and give it a temporary public link, no deployment needed. I can send you a link mid-afternoon, you click it on your phone, you see the booking form or the dashboard exactly as it stands, and that link stops working once I close it down. It's useful for fast feedback on layout, wording, or "is this the flow you meant?" It is not something anyone should treat as a stable environment, and it shouldn't hold real customer data.

The second is a proper staging environment: a separate, password-protected copy of the application, running on real infrastructure, with its own database, that stays up between our conversations. This is where you'd actually test a booking flow end to end, try logging in as different types of user, or run a real invoice through the system before it goes anywhere near a customer. Staging is where sign-off should happen, not a five-minute tunnel link.

Both have a place. The quick link is for "does this look right, roughly, today." Staging is for "am I happy for this to go live."

Why this actually matters, beyond peace of mind

The point isn't just reassurance, though that matters too. It's that mistakes caught in week two cost almost nothing to fix, and mistakes caught in week eight can mean reworking things that other parts of the system now depend on.

Say I'm building a booking form for a trades business. If I show you the field order and the deposit step after a day's work and you tell me customers need to see the price before they enter their card details, that's a ten-minute change. If nobody sees it until the whole booking-to-invoice flow is wired up, the same fix might mean touching three other screens that were built assuming the old order. The cost of a wrong assumption grows the longer it sits undetected. Regular, real previews are how you keep that cost low, and they're one of the reasons I structure projects in stages rather than one long build followed by a reveal, which I go into more on how I work.

What to ask before you commit

If you're weighing up a developer or agency for bespoke work, it's worth asking a few direct questions before anything is signed:

• How often will I see something running, not just described? Weekly is reasonable for most projects. Monthly is too long to go without a look.
• Where will I be looking at it? A screen-share of someone else's screen isn't the same as a link you can click yourself, on your own laptop or phone, whenever you want.
• Is what I'm seeing safe to use with real data, or is it just for looking? A quick preview link with no login and no proper hosting is fine for checking a layout. It is not the place to test a real customer's payment.
• What happens to my feedback? Does it get written down and tracked, or does it evaporate into a chat thread you'll never find again?

If a developer can't answer these clearly, or the answer is "you'll see it when it's finished," that's worth pausing on. It's not necessarily a sign of bad work, but it does mean you're taking more on trust than you need to.

The same principle applies if I'm working under your brand

For agencies bringing me in as overflow or white-label capacity, this matters just as much, if not more, because your client's expectations still run through you. If a client asks "can I see it," you need a genuine answer, not a promise to check with the developer and get back to them. When I'm working this way I still build in the same regular preview stages, so you've got something real to show, under your own name, whenever it's asked for. I cover how that arrangement works on the partnerships page.

None of this is complicated engineering. It's just a habit of showing the work, not just talking about it. If you're about to commission bespoke software, that habit is worth as much as any feature list you're given up front.