Ongoing support - How changes reach production after go-live

Change Request Process

William Belle — Deployment and Infrastructure Services Support: support@williambelle.co

This document explains how updates to your deployed application are handled after go-live. It applies whenever you have new functionality, fixes, or changes you would like released to production, including code you have generated yourself with AI tools.

The goal of this process is simple: every change reaches production safely, you always know what a change will cost before work begins, and nothing goes live without your approval.

First: Who Is Writing the Code?

There are two ways to work with me after your app is live, and the only difference between them is who writes the code. Everything else (testing, deployment, the release to production, your sign-off) is the same either way.

You write the code, I get it live. That is the process described in this document. You (or a developer on your team) make the changes, and I review them, get them running in a real environment, test them, and release them safely to production.

I write the code and get it live. You describe what you want the app to do, in plain language, and I build it, test it, and deploy it. There is no code to send, nothing to review, and nothing to reconcile.

Which one is right for you?

The process in this document works well, and it will save you money, as long as you can send code that is ready to deploy. Concretely, that means:

• The code builds from a clean copy of the project, not just on your machine
• When your change touches the database, the migration that makes that change comes with it
• New files, and any new library your code depends on, are all included
• You start from the most recent version I sent you, rather than an older copy

You do not need to learn any developer tools for this. Export a zip from whatever AI tool you are building with and send it to me. That is the normal way to do this, not a fallback, and it is what most owners do. Handling it from there is my job. What matters is the state of the code inside the zip, not how it reaches me.

If that sounds manageable, read on. This process is built for you, and it is the cheaper option.

If you cannot, the second option will serve you better, and it is worth being honest about why. Writing the code yourself looks cheaper, and on the invoice it is. But the invoice does not count the evenings you spend building the change, and it does not count the weeks a change sits stuck because it will not build. Both of those costs climb as the app grows while the invoice stays flat. The real comparison is not two prices. It is a lower price plus your evenings and an uncertain outcome, against a higher price where the feature simply arrives.

A lot of owners start in the first mode and move to the second as the app grows. That is normal, and it is not a failure. AI tools are genuinely good at building a first version of an app. They get less reliable as the app gets bigger, because there is more of it than the tool can hold at once, so it starts changing things without seeing what else it affects. When that begins happening, it means your app has grown up. Get in touch and we will talk about the switch.

How It Works

Every change request is quoted as one fixed price, split into equal milestone payments, so the cost is spread evenly and is easy to budget. When you write the code there are three milestones. When I write the code there are four, because building the feature is its own substantial piece of work. The stages below are otherwise the same either way.

Milestones are scoped and funded up front (for example, through Upwork escrow) before work on that milestone begins.

Before Milestone 1 — the build check, which is free

Send me the code before we talk about price and I will build it. A zip exported from your AI tool is fine. You get back a plain yes or no, along with whatever the build itself reported, and it costs you nothing. There is no limit on how many times you can do this. Send it, fix it, send it again.

A build that passes is the entry requirement for this process, and the check is deliberately free. Neither of us should be spending money to find out that the code was never going to run.

What the free check does not include is working out why it is failing. Reading past the error to the actual cause, and telling you what has to change, is expert work: that is Milestone 1, and it is quoted before it starts. You get a written report of what is wrong and what is missing, and the code comes back to you to fix. Once you re-submit, one re-check is included at no additional cost.

If the corrected code still will not build, I will not send it back to you a third time. At that point the problem is not the code, it is the arrangement: the app has grown past what an AI tool can reliably change, and asking you to keep fixing it is asking you to keep losing. I will quote the change as development work and build it for you instead. You are never stuck in a loop, and you are never paying to be told "no" over and over.

Milestone 1 — Production Risk Review

A green build means your code compiles. It does not mean the change is safe to release. That build ran against an empty test database and a test configuration. Production has your real data, your live settings, and your customers on it.

This milestone is the review that stands between those two, and it is the part no automated check can do for you:

• Database migrations read against your live data. Automated checks apply migrations to an empty database, where almost anything succeeds. I read them against what is actually in production: whether a migration removes data you still need, whether it can be undone, and whether it will lock a table long enough for your users to notice. Migrations run automatically when the app starts, so this is the last point at which a bad one can be caught.
• Configuration and environment. Any new setting, connection string, or key your code now expects has to exist in the deployed environment before release. This is the most common way a change that built perfectly fails the moment it goes live.
• Secrets and dependencies. API keys or passwords that ended up in the source, plus any new library your code pulls in: whether it is maintained, safely licensed, and free of known vulnerabilities.
• Anything touching logins, payments, or sensitive data. These paths are read line by line, every time, no matter how small the change looks.
• Blast radius and release order. What else in the app shares the code you changed, and what has to go out in which order so the app keeps working while it is being deployed.
• Technical consultation and planning. Scoping calls and walkthroughs for the change are part of this milestone, so please bring your questions. That time is already accounted for.

Deliverable: A written summary of findings and risks, with a plan for integrating the change and deploying it to the test environment.

Why this milestone matters: Code that works in isolation often behaves differently in a live, deployed system, in ways that are not visible until release. This is what prevents an update from breaking the application your business depends on, and it is the only step where a bad database migration can still be stopped. After this, it runs.

Milestone 2 — Integration and Test Deployment

This is where your code becomes a running application in a real environment. Code that builds on your machine is not the same thing as code that runs in the cloud, and closing that gap is the work here.

What is included:

• Taking your code into version control on my side, so every change to your app is tracked and reversible whether or not you ever touch those tools yourself
• Wiring the change into the deployed environment: configuration, environment variables, connection strings, and secrets stored securely rather than in the source
• Running your database migrations against the test database in the right order, and confirming the schema matches what the code expects
• Deployment to the test environment through the release pipeline, with confirmation that the application builds, runs, and passes smoke checks
• Your hands-on validation of the new functionality in the test environment
• One round of revisions, based on your consolidated feedback, followed by redeployment to test for final sign-off

Deliverable: A build you have approved, running in the test environment and cleared for production release.

Your role in this milestone: Please review the change thoroughly in test and gather all of your feedback into a single list. That list is worked through as the included revision round. Additional revision rounds are welcome and are scoped as a separate milestone.

Milestone 3 — Production Deployment and Release Verification

What is included:

• Pre-deployment checks
• Promotion of the approved build from test to production through the release pipeline
• Post-deployment verification that the application is healthy and the new functionality is live
• Rollback readiness in case an issue is found after release

Deliverable: The new version live in production, confirmed healthy.

What to Expect on Pricing

Every change request is quoted as one fixed price, split evenly across the milestones. No hourly billing and no surprises. Most requests fall into one of three tiers, and the price depends on who writes the code.

Small changes are collected and released together, up to three at a time. What a change costs is driven by the release, not by the size of the edit: the test deployment, the production release, and the checks around them happen whether the change is one line or one screen. So rather than paying for three separate releases, send small changes as they come up and I will group them into a single release at one Small price.

A few practical notes on that. Three is the limit for one batch, because the review and your validation do grow with each change added; a fourth makes it a Standard change request. If several small changes together end up touching the database, logins, or payments, they are priced as the larger request they add up to rather than as a batch. The batch is fixed once work is funded, so anything you send after that goes into the next release rather than delaying the current one. And anything urgent still goes out on its own, immediately.

I confirm the tier and the exact milestone prices after reviewing your request. Some changes that look small touch critical parts of a production system and are priced for that responsibility. The reverse happens too, so a review can also move a request into a smaller tier.

Read that table honestly. Writing the code yourself costs about half as much on the invoice. If you can clear the checklist below, that is a genuinely good deal and I will happily keep working that way with you. If you cannot, the invoice is not the price you actually pay, for the reasons in Which one is right for you? above.

What to Send When You Have a Change

To get a change request started, send the following to support@williambelle.co:

1. The code or a description of the change. A zip exported from your AI tool is the easiest way to send code and it is perfectly fine. Please build the change against the most recent version I sent you. I can get you that version any time you ask.
2. What the change should do, in plain language, from the user's point of view.
3. Any deadline or timing constraints.

I will respond with the scoped milestones and pricing. Work begins once Milestone 1 is funded.

Before you send code: a quick self-check

Running through this list will get you a green build on the first pass and keep your change moving. If you are sending a description rather than code, you can skip it.

• It builds. Send it over and let me run the free build check before we talk about price. If it comes back failing, fix it and send it again. There is no charge and no limit.
• It started from the version I last sent you. This is the one that matters most and it is easy to get wrong. Before you start a change, ask your AI tool to work from the most recent copy I gave you, not from an older version still sitting in the tool. Building on a stale copy quietly undoes work that is already live, and it is the most expensive mistake on this list.
• Migrations are included. If your change adds, removes, or alters anything in the database, the migration that makes that change has to come with the code. AI tools very often write the code and quietly skip the migration, and this is the single most common cause of a change that builds fine and then cannot be released.
• Nothing is missing. New files are all included, and any new package or library your code depends on is declared, not just assumed.
• No secrets in the code. API keys, connection strings, and passwords belong in configuration, not in the source. If you find one in there, send it separately and let me know.

This is not a high bar and it is not a code-quality review. It is only a check that the code is complete enough to be worth reviewing for release.

If working this way sounds like more than you want to take on, that is a completely reasonable answer. Having me write the code is not a failure mode. For most owners, it is the cheaper end state.

A Few Ground Rules

• Consultation is part of Milestone 1. Planning calls, code walkthroughs, and scoping discussions are professional services and are included in the review milestone, so please bring your questions. That time is already accounted for.
• Checking whether your code builds is free. Fixing it is not. The build runs automatically and you can watch it as often as you like at no charge. If you need me to work out why it is failing, that is Milestone 1: you get a written diagnosis and one re-check of your corrected code. If that still will not build, I stop sending it back and quote it as development work instead.
• Small changes are batched, up to three. Three small changes released together cost one Small price rather than three. A fourth makes it a Standard request, and the batch is fixed once work is funded. Urgent fixes always go out on their own.
• You can switch modes at any time, for any change. This is not a contract you are locked into. Some changes you may want to make yourself; others you may want to hand to me. Decide per change.
• One revision round is included in test. This keeps the milestone predictable for both of us. There is no limit on total revisions. Additional rounds are simply scoped as their own milestone.
• Nothing reaches production without your sign-off. Production deployment only happens after you approve the build in test.
• Small fixes are still changes. Even a one-line change goes through review and test, because the risk to a production system is in the deployment, not the size of the diff. That is exactly why batching small changes saves you money.

This process is part of the ongoing support arrangement described in your production handoff document. Questions are always welcome at support@williambelle.co.