Six Approvals Before the First Release: How an Enterprise Project Actually Starts

What each stage checks, why it matters, and what a vendor prepares for it.

In an enterprise project, the first line of production code arrives after a sequence of approvals. Each approval has an owner, and each owner asks a specific question. Teams that plan for the sequence from the first week keep to their schedule. Teams that discover it along the way spend the first months waiting.

We have worked with enterprise clients for more than ten years. This article describes the sequence as we usually meet it and what we prepare at each stage. The order differs from client to client, but the stages recur.

1. Procurement and contract

What happens. Legal and procurement review the vendor and the terms of cooperation: code ownership, confidentiality, and the liability of each party.

Why it matters. No access is granted before the contract is signed, so the project cannot start without it.

Our role. We record in the contract the terms for replacing a specialist, transferring knowledge, and up to 10 hours of consultations per month from our wider team of architects, tech leads, and domain experts.

2. Security review

What happens. The client’s security team checks how the vendor stores credentials, data, and code.

Why it matters. The result determines which access to the client’s systems the vendor receives and with what restrictions.

Our role. Our standard setup includes private repositories with restricted access levels, data encryption, secure CI/CD, regular backups, and no confidential data in source code. The review then checks what already operates in our daily work.

3. Architecture approval

What happens. The client’s architects check whether the proposed solution fits their landscape: integrations, standards, and constraints.

Why it matters. A solution approved once does not have to be reworked after the first release.

Our role. Our tech lead prepares a description of the solution, the rationale for the choices made, and the known trade-offs, so the architects can evaluate decisions rather than reconstruct them.

4. Environment access

What happens. The client grants access rights to the development, testing, and production environments.

Why it matters. These rights determine who can change what, and how safely.

Our role. We work on the principle of least privilege, so each specialist sees only what their task requires. We separate development from production, which keeps a mistake in development away from live users.

5. Change and release approval

What happens. Every change goes through review, testing, and sign-off before it reaches production.

Why it matters. In a large system, one failed release affects many processes and many teams.

Our role. Every code change passes mandatory code review with vulnerability scanning. QA checks the critical business processes, and the project manager sends a weekly status with risks and next steps.

6. Audit and compliance

What happens. The client has to show regulators and its own auditors that data is protected and access is controlled.

Why it matters. Requirements added shortly before release turn into rework, and the client pays for it.

Our role. We build data protection requirements into the planning stage, keep a log of actions, and maintain documentation that internal and external audits can rely on.

The seam between vendors

Many enterprise systems have more than one contractor. In that setup, the greatest risk sits at the seam between teams: who owns the integration, who fixes a failure at the boundary, and how data passes from one team to another. A seam without a named owner is usually the first place that breaks.

We record in writing the boundaries of our responsibility and the interfaces to neighboring teams, and we suggest that the other vendors do the same. A written boundary gives the client one person to call when something fails at the seam.

What to take from this when planning

• Start approvals in parallel with design, so waiting for sign-off does not consume the schedule.
• Bring the architectural rationale to the first review, so the discussion is about decisions.
• Settle access and environment separation in the first week.
• Ask each vendor what they prepare for each of the six stages. The answer shows whether they know the process from the inside.

Which approval stage takes the most time in your company?

Wamisoftware has been building software products since 2014. Our senior engineers work with enterprise clients on systems where documentation, security, and clear ownership decide how the product grows.