Ongoing code review or software maintenance?

Does your team continue development but need an independent technical perspective? The AI Code Review Retainer covers that role. If WZ-IT should implement updates, fixes and releases, software maintenance and ongoing support is the appropriate service.

The market uses code review, code care, software maintenance, application maintenance and technical support inconsistently. A service name is therefore not enough. What matters is who evaluates a change, who implements it, who tests it and who publishes it to production.

The shortest distinction is:

• Code review assesses and decides.
• Software maintenance changes and releases.
• Managed Operations runs and responds.

All three services may belong together, but they should remain traceable as separate responsibilities in the proposal.

Responsibility matrix

The matrix is not a universal definition used by every provider. It describes a clear and verifiable separation of WZ-IT services.

What an ongoing code-review retainer provides

A review retainer is a technical control function for teams that continue development themselves. Changes may come from:

• an internal product team
• an external software agency
• a solo founder using Cursor or Claude Code
• Lovable, Bolt, Replit or another AI builder
• several parties in a co-managed model

Within the agreed cadence, WZ-IT assesses risk-relevant changes and their effects on the overall system. This may cover source code, authentication, authorisation, data access, dependencies, APIs, migrations and release impact.

The output is not an anonymous scanner score. It supports decisions:

• remediate before the next release
• correct in the short term
• schedule as technical debt
• accept with documented rationale

The retainer reserves review and clarification capacity. It is not a freely spendable developer-hours package. That boundary protects both parties: the client knows independent review will actually take place, and review capacity is not consumed entirely by implementation work.

What software maintenance adds

Software maintenance begins where a finding needs to become a change. Typical tasks include:

• preparing dependency, patch and minor updates
• treating critical CVEs through a patch, update or mitigation
• analysing and fixing technical defects
• adding tests for changed or critical paths
• maintaining framework and runtime versions predictably
• preparing database migrations
• validating releases on staging and publishing them in a controlled process
• reducing small items of technical debt within the agreed allowance

A monthly price still cannot represent unlimited development. The scope requires a defined corridor based on repository, maintainability, test coverage, release frequency and expected change volume. Major upgrades, extensive refactoring or new product features are planned separately.

Unknown inherited code generally needs a baseline before ongoing care. The Production Readiness Audit establishes whether build, architecture, tests and deployment are sufficiently traceable.

Example: a critical dependency alert

A new CVE demonstrates how review and maintenance work together.

1. Capture the signal

Dependabot, another scanner or a vendor advisory reports an affected package version. The signal often includes a CVSS score, version range and general description.

2. Assess exposure

Review asks:

• Is the exact deployed version affected?
• Does the application use the vulnerable function?
• Is the code path reachable from external or untrusted input?
• Which data and permissions could be affected?
• Is there a safe target version or only a temporary mitigation?

This assessment is part of technical control. It prevents both alert fatigue and the neglect of genuine risks.

3. Implement the change

Software maintenance updates the package, adjusts code or configuration where required and handles incompatible changes. Where no patch is available, mitigation may require disabling a feature, constraining input or adding a network boundary.

4. Test and release

The build, relevant tests and critical user journeys are checked. The agreed staging and production path then publishes an identifiable version with rollback capability.

5. Observe operations

After release, the responsible operator monitors technical errors and key functions. Guaranteed response outside business hours does not come from review or software maintenance but from the commissioned Managed Operations service level.

Four useful collaboration models

1. Review only

Fits when: the client team can implement findings reliably but needs independent senior assessment.

Boundary: findings remain open if there is no internal implementation capacity.

2. Software maintenance only

Fits when: WZ-IT maintains a known codebase and most changes come from that agreed scope.

Boundary: if other teams develop in parallel, branch, review and approval rules must be explicit.

3. Review plus separate Software Care

Fits when: the client team develops, WZ-IT independently reviews and then implements selected findings.

Boundary: review and implementation capacity must be itemised separately. The same party that implements a fix should not silently become the only approver of that fix.

4. Review plus Software Care plus Managed Operations

Fits when: code, releases and production operations should be managed as one lifecycle.

Boundary: even with one provider, application, infrastructure and incident response need separate definitions in the service schedule.

What a co-managed process can look like

A small team can continue building with AI without handing product development to WZ-IT:

1. The team creates changes in its own repository.
2. Automated tests and scanners run on pull requests.
3. Agreed risk-relevant changes enter human review.
4. The team or Software Care remediates findings.
5. Approved versions deploy automatically to staging.
6. Critical user journeys and migrations are validated.
7. The release is promoted to production in a controlled process.
8. Managed Operations monitors agreed systems and responds according to the service level.

Development freedom remains intact while responsibility at every step is visible.

Which service is the right starting point?

Choose the entry point according to the actual constraint:

• Unknown baseline: one-time Production Readiness Audit
• Active team without independent technical control: AI Code Review Retainer
• Missing implementation capacity: software maintenance or development retainer
• Missing production operations: managed hosting or Managed Operations
• Immediate offensive security need: separately scoped penetration test

A retainer is productised responsibly when it does not claim to solve all five problems at once for a low flat fee.

Sources

• NIST Secure Software Development Framework, SP 800-218
• OWASP Software Assurance Maturity Model
• GitHub: About pull request reviews
• GitHub: About Dependabot alerts