The thing to find out is what each part actually does. Does it read or save real data? Does it call the service it will use later? Does it remember a change after you reload the page? Does it check who is allowed to do what?
What kind of demo are you looking at?
These stages can look similar in a screenshot, but they answer different questions:
• A wireframe shows layout and navigation. The buttons may not do anything yet.
• A clickable prototype lets someone try the flow. It may use fixed screens or sample data.
• A hard-coded demo can respond to clicks without saving data or connecting to the real services.
• A working slice completes one part of the job using the app's real code and test data.
None of these is automatically a problem. A prototype is often the right thing to build first. The important part is knowing which stage you are paying for and what it is meant to prove.
Walk through a button
Pick an action in the demo and ask the developer to show what happens behind it:
• What data does this screen read?
• Does this button save anything, or does it only change what is on screen?
• Is this result coming from a real service or a fixed example?
• What happens if you refresh, enter something unexpected, or lose the connection?
• Where are the tests for this part?
You do not need to understand every line of code. Ask to see the code that handles the action and where its data goes. If that part is not built yet, the developer should be able to say so plainly.
Ask to see the code
Agree who owns the source code and when you can access it. A repository under an account your business controls makes it easier to review the work, ask another developer questions, or change providers later. Access can still be limited to the people who need it.
Before the work starts, write down what the demo should prove, which parts use real code or data, and what is still mocked. Then you can decide whether the next step is more prototype work, a working slice, or a production release.