What the Client Must Provide for an IT Project to Succeed
Practice3 minInnovialabs editorial team
In short
The client owns fast decisions, content, system access, test data and regular feedback — each day of delay on the client side usually moves the whole project by at least as much.
The short answer
The contractor writes the code, but two parties build the project. The client needs to provide five things: one accountable person, fast decisions, ready content, access to systems and timely feedback. Without any one of them the team either sits idle or works blind and redoes it later.
One person with authority to decide
Appoint a single product owner from the business side. This person:
- answers the team's questions within an agreed time (for example, one working day);
- makes decisions directly instead of collecting approvals for a week;
- merges the views of sales, accounting and management into one position.
A common mistake is having several "clients" inside the company giving conflicting instructions. The team ends up with two versions of the requirements and has to wait while you reach agreement internally.
Content and materials
You cannot launch a website or app without texts, photos and product descriptions. Decide early who prepares:
- page copy and legal documents (terms of service, privacy policy);
- photos, logos, brand guidelines;
- the product catalog, prices and specifications;
- email and notification templates.
Content is the most frequent cause of late-stage delays. Design and code are done, but pages still show placeholder text because nobody wrote the real copy.
Access and integrations
The team will need access that only you hold:
| What | Why |
|---|---|
| Domain and DNS | Connect the site and email |
| Hosting or cloud | Deploy the project |
| Payment providers | Enable payments, obtain keys |
| CRM, 1C, ERP | Set up data exchange |
| Analytics, ad accounts | Install tracking and goals |
Contracts with payment providers and banks can take weeks to sign. Start these processes in parallel with development, not at the end.
Test data and acceptance
Testing needs real scenarios: sample orders, typical customers, exports from the old system. Without them, testing runs on made-up data and misses bugs that will appear on the first day of real use.
During acceptance you are expected to:
- review each finished block within the agreed time;
- send issues as a list, with steps to reproduce and screenshots;
- separate "this is a bug" from "this is a new request".
How delays affect the timeline
A client delay rarely equals a project delay — it is usually longer. Why:
- Context switching. A team waiting for an answer picks up other work and cannot return to yours instantly.
- Dependency chains. No approved design means no front-end work; no API from 1C means no data sync.
- Rework. A late decision often changes work that is already done.
It helps to state in the contract that deadlines shift by the time spent waiting for client input, and to record such pauses in writing.
Pre-start checklist
- One accountable decision-maker is appointed.
- There is a meeting schedule and a response time for questions.
- It is clear who prepares content and when.
- Access is collected or requested.
- Samples of real data are ready.
- The acceptance process and issue format are agreed.