I manage websites and applications for clients, many of which are built by subcontracted developers. Since AI-assisted coding became more accessible, I've started building smaller applications myself and am now considering rebuilding a client's website, too.
The project is for an industry association with a few hundred users. It will include public and member-only areas, event registration, a data portal, and a document library. I typically use an AI coding assistant to build features on staging, then manually push completed changes to production.
Would it be reasonable to have a web developer manage the deployment and production infrastructure while I continue developing and testing on staging? My concern is security: I have limited technical knowledge and don't want to be solely responsible for a system I don't fully understand. However, I'm also wondering whether a developer would be uncomfortable deploying code they didn't write, especially if it was largely AI-generated.
Would this work as a clearly defined deployment and infrastructure role, or should the developer also review the application code and security before anything goes live?
4 Answers
The setup is reasonable if the developer understands the architecture and gets involved early enough to review it. Asking them to take an unknown, AI-generated application and deploy it without authority to inspect or reject it is likely to create conflict later.
A good compromise would be to separate the work into two paid services: an initial technical and security review, followed by ongoing infrastructure and release management. That gives you help with the risks you’re worried about without requiring the developer to build the entire application.
It can work, but only if the boundaries are written down clearly. The developer could own the hosting, CI/CD pipeline, environment configuration, backups, monitoring, and rollbacks, while you remain responsible for application bugs. They should not be expected to debug broken JavaScript or incomplete features after every deployment.
A staging-to-production workflow with automated tests and a documented rollback process is much better than simply asking someone to press the deploy button. Make sure everyone agrees in advance about who handles outages, failed releases, and urgent fixes.
Deployment alone won’t address the main security risk. If the application has flaws in authentication, permissions, session handling, file uploads, or data access, a secure server cannot compensate for them. The developer may also be hesitant because they could end up carrying liability for code they were not involved in creating.
For this project, I’d budget for an application and security review before launch, not just deployment. At minimum, have someone inspect the authentication and authorization model, document uploads, database access, secrets, dependency vulnerabilities, error handling, and backup and recovery process.
For a simple static website, deployment-only is fairly routine. A member portal with registration, private documents, and user data is a different level of responsibility. I would treat the developer as a release gatekeeper rather than a deployment operator: they should be able to reject a release if it cannot be built reproducibly, fails basic tests, lacks health checks, or cannot be rolled back safely.
You can still do the hands-on AI-assisted development, but the production process should include a clean build from a specific commit, environment validation, migration testing, monitoring, and a tested rollback.
That arrangement has worked for some of my clients. The important part is making it clear that I deploy what is approved, but I’m not automatically responsible for fixing application-level problems in that code.