A client of a software project is often in an awkward position. They pay the money, yet it is hard to see what is going on inside: you cannot read the code, and “everything is on schedule” sounds the same whether it is true or not.
The good news: you do not need to understand programming to keep a project under control. You need the right rhythm and a few agreements with the contractor at the very start.
The main tool is a working version
The most reliable way to know how development is going is to see the result with your own eyes, regularly. Not a presentation and not a report about a percentage of completion, but a working version of the product where you can press the buttons.
That is why it is convenient to run development in two-week iterations. Each one ends with a demo: the team shows what has been done, you try it yourself and give feedback. Two weeks is long enough to get a noticeable part of the work done and short enough that a misunderstanding does not become expensive.
What to look at in a demo:
- does what was built work the way you expected — in your scenarios, not only the showcase ones;
- does it match the iteration plan, and if not, why;
- what the team plans for the next two weeks, and whether you agree with the priorities.
If the demo keeps being postponed, or mockups are shown instead of a working version, that is a reason to ask questions.
The report: short and to the point
The demo shows the result; the report gives the context. A good iteration report fits on one page:
- what is done and what you can look at;
- what was not finished, and why;
- which decisions are needed from the client;
- which risks have appeared — a delay in an external system, an unclear requirement, a new task;
- what is planned next.
The point about decisions is especially important. A large share of project delays comes not from developers but from questions that wait weeks for the client’s answer. The report makes those questions visible.
Acceptance: by scenarios, not by feel
Acceptance is the moment you confirm that the work is done. To keep it from turning into an argument, describe the criteria in advance — during the requirements and the specification.
Scenarios are a convenient form: “a manager creates an order, the customer gets a notification, the status changes after payment”. If the scenario passes, the feature is accepted. If not, it is clear what exactly does not work.
Before launch, it pays to check the product on your own real scenarios. The contractor tests on their side — functional, unit and load tests — but only you know how the product will actually be used.
What to ask a contractor before the start
A few questions at the selection and contract stage save a lot of nerves later:
- How often will I see a working version? A good answer is every one or two weeks.
- What will the reports look like? Ask for an example.
- Who is my contact on the team, and how quickly do they reply?
- How are changes to requirements handled, and how do they affect timeline and cost?
- How does acceptance work, and what counts as done?
- Where will the system run, and who will have access to the servers?
- What documentation will I get — architecture, API, deployment?
- What does the warranty cover, and for how long?
The answers show not only the terms but also how used the contractor is to working transparently.
What to ask during the project
At every demo and with every report, it helps to come back to three questions:
- Are we on track for the deadline? If not, what do you suggest: move the date, simplify the feature or postpone it?
- What is blocking the team right now? Often it is your own answers or access.
- What has changed in the plan since the last iteration, and why?
These questions need no technical knowledge, but they quickly show the real state of the project.
Signs that something is going wrong
Be careful if:
- you have not seen a working version for a long time;
- direct questions about the timeline get vague answers;
- every demo is mostly “almost ready”;
- risks have disappeared from the reports — a live project always has some;
- you learn about problems on your own rather than from the contractor.
None of these signs means the project has failed. But each one is a reason for a direct conversation while fixing things is still cheap.
Your part of the work
Control works both ways. For the project to keep its rhythm, the client has a part to play too:
- one person who makes product decisions and can answer the team’s questions;
- feedback after a demo within a few days, not weeks;
- access on time — to servers, external systems, app stores;
- approval of requirements and mockups before development starts.
It takes little time, but these are the things that most often decide whether the product ships on time.
How we do it
We work in two-week iterations and show a working version and a report after each one. Before development we agree on the requirements, mockups and specification; before launch we check the product on your scenarios; after launch there is a 6-month warranty. More about our services is on the services page.
Keeping control of development does not mean watching every step. It means regularly seeing where the team has got to. Every two weeks. With your own eyes.
