How to track an outsourced software project through regular demos

You hired a team to build an order management app. Now and then you get a message: “Good progress. Invoicing 80% done.” Three months in, you finally see it. The invoice puts the discount after GST when your business applies it before. The dispatch screen has no approval step because nobody mentioned your manager signs off on large orders. Your warehouse staff can’t use it on their phones.

None of these is a big failure. Each was small and easy to fix in week two. Together, at month three, they mean rework and delay.

Progress percentages and screenshots miss this kind of drift. You find it by using the software while it is being built.

Use this list with any team you hire.

1. Screens you can click. Once the build has started, mockups don’t count as progress.
2. Sample data that looks like yours: your product names, realistic GST rates, Indian phone numbers and addresses. Toy data hides layout and logic problems.
3. The tasks from the scope of work, end to end. Create the order, raise the invoice, send the reminder.
4. A short list of what changed since the last demo, including the feedback you gave.
5. What is planned before the next one.
6. Open questions, with a date by which the team needs your answer.
7. A test version you can use after the call. Clicking through alone often shows more than watching someone else drive.

“Regular” means no long stretch passes without you seeing working software. Agree at the start what that means for your project, and put it in writing.

The owner often approves software that the front desk or the accounts team will use all day. Invite those people. They notice the missing field, the extra click and the report nobody can read.

Test on the phones, browsers and internet connection your staff really have. An app that is quick on office Wi-Fi can crawl on mobile data in a warehouse.

Keep feedback in one shared document or tracker, numbered, so each point can be ticked off. Voice notes and scattered chat messages get lost.

Then sort each point. If the software doesn’t do what the scope says, it’s a bug and the team fixes it. If you’re asking for something the scope doesn’t include, it’s a change. Changes are normal. They just cost time and money, so get a price before they are built. Our guide to scopes of work explains why a clear scope makes this sorting easy.

Answer open questions quickly. Slow answers hold up the build.

Some India-specific checks belong in early demos rather than launch week. Ask your accountant to review invoice formats and GST fields. If the app sends WhatsApp messages, review the message templates early, since Meta has to approve them before business-started messages can go out (WhatsApp template rules).

• Demos keep getting postponed. One delay happens; a pattern usually means there is little to show.
• Every demo shows the same screens with new colours.
• Months into the build, you have seen designs but nothing you can click.
• “It works on our side” is the answer when something fails.
• You can’t get access to a test version.
• Feedback you gave doesn’t appear as fixed, and nobody explains why.

If you see two or more of these, ask for a plain conversation about where the project really stands. Asking early leaves you more options, including changing the plan.

• How often will we see working software, and in what form?
• Will we have a test version to use between demos?
• Where is our feedback recorded, and how do we see what happened to it?
• How do you tell a bug from a change, and how are changes priced?
• Who runs the demo, and can they answer questions about how the software works?
• Who owns the code and the repository while the work is in progress?

Microsive works from a written scope and fixed quote, with regular demos along the way (how we work).