If the software is ready, hand me the mouse

If I'm paying for custom software, at some point I want the mouse.

Watching the person who built an application use it tells me something. Trying to complete my own work in it tells me something else. I want both before we call a milestone finished.

A good demonstration is useful. The developer can explain the decisions, show a new feature and point out what is still being built. But a customer shouldn't have to infer whether an application works for them from a sequence of clicks they never get to make.

That matters for an internal scheduling tool just as much as a new product. The people who will use it know the awkward cases: two appointments that overlap, a customer who changes their mind, a member of staff who must see the booking without seeing the invoice.

Cover: AI-generated illustration of a fictional software review, not a real client meeting.

A useful change in the release process

On September 28, Laravel described its preview environments alongside scale to zero: separate working deployments for proposed code changes, with supported resources sleeping when idle. A reviewer can open a link and use the application before the change reaches production.

The practical point for a buyer is access. Ask how you will try each meaningful piece of the product while there is still time to change it. Your project doesn't need to use Laravel, and a small team may use one well-managed staging environment instead of a separate environment for every change. The arrangement should let you evaluate the work without interrupting the live business.

A preview is also something to budget for. Someone has to prepare the accounts and sample records, keep the environment usable and deal with feedback. Ask which resources are billed, what happens while they are idle, and when they are removed. An inexpensive server does not make the whole review process free.

Give the reviewer a job, then let them do it

Consider a hypothetical appointment system for a small service company. The proposed milestone is rescheduling. A developer demonstrates opening a booking, changing its time and saving it. Everything looks straightforward.

For a customer review, I'd give the person who actually handles bookings a test account and a short task: move tomorrow's appointment to next week, assign a different employee, then check what the customer will be told. Let them work through it before explaining where to click.

They might discover that moving the appointment silently removes an important note. Or they might complete the task correctly but spend several minutes hunting for the confirmation. One is a functional defect; the other may be a design problem. A rehearsed walkthrough can pass over both.

Include an ordinary complication from the real job. Make the preferred time unavailable. Give the reviewer a booking that has already been cancelled. Use sample names and records that make those cases understandable.

The point is to learn how the workflow behaves, not to surprise the developer with an unlimited exam. Agree on the task, expected result and relevant user role beforehand. If this milestone only covers changing the time, say that. Reviewing an unfinished feature is perfectly reasonable when everybody knows what is unfinished.

Make room for mistakes without touching real customers

The reviewer needs to know what their test can affect. Can it send a real email? Does cancelling a booking alter the live calendar? Will changing an invoice create an actual charge? A reassuring preview banner cannot answer those questions.

Laravel's preview documentation illustrates the distinction: it supports separate resources, but also allows a preview to share a target database. In that configuration, changes can affect the shared data. The URL alone does not establish isolation.

For our hypothetical scheduling review, I'd use invented bookings, separate storage and test recipients. External services should use their appropriate test facilities or a clearly described substitute. Someone should verify where messages and calendar changes go before inviting a customer to experiment.

Access should match the role under review. An administrator account can hide the fact that the receptionist cannot complete a required step. Equally, an employee should not need administrator access just to move an appointment. Use distinct test accounts where those differences matter.

A preview has limits. A stubbed email service can show the intended message without proving delivery through the production provider. A small sample database cannot establish performance at full volume. Write down those limits and identify the separate checks needed before launch. There is no benefit in replacing an overconfident demo with an overconfident preview.

Agree on what happens after the review

A useful review produces decisions somebody can act on. Record the build or version tested, the task, the expected result and what actually happened. A short recording can help explain a confusing interaction, provided it contains no real customer information.

Then separate failures against the agreed scope from newly discovered requirements. If the agreed permission rule fails, that needs fixing. If trying the app gives the team an idea for a new feature, discuss its cost and priority. Neither side should have to pretend those are the same thing.

Give reviewers a sensible window and identify who can accept the work. Keep the tested version available during that window, or make changes explicit. Otherwise, someone can report a problem on Tuesday that nobody can reproduce against Wednesday's completely different build.

This isn't a substitute for code review, automated tests or specialist testing. It answers a question those activities cannot settle on the customer's behalf: can the intended person use this feature to do the agreed job?

For a custom application project, I'd put that review into the delivery plan from the beginning. A small usable slice gives the buyer something concrete to assess and the developer specific feedback to work with. It can also reveal that the requested workflow needs changing before the team builds the rest around it.

Rosecraft's web application development work includes turning business workflows into usable software. If you're commissioning a system or trying to get an existing build over the line, tell us what your users need to accomplish and what they can currently try. That's a useful place to start defining the next deliverable.