Ongoing support - How changes reach your live app after launch

Change Request Process

Will Pickeral, William Belle LLC · support@williambelle.co

How updates to your live app are handled after launch: a new feature, a fix, or a change you want released, including code you have generated yourself with AI tools.

Every change reaches production safely, you know what it 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 is who writes the code. Testing, deployment, the release to production and your sign-off are the same either way.

You write the code, I get it live. That is the process described here. You or a developer on your team make the changes. I review them, get them running on a private test address only you and I can see, 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 and nothing to reconcile.

Which one is right for you?

The process in this document will save you money, as long as you can send code that is ready to deploy. That means:

• The app runs from a fresh copy of the files you send, not only on the computer you built it on
• If your change means the app saves something new, the file that updates the database comes with it. Your tool creates that file; it is called a migration, and it is the thing most often left behind
• Every new file is included, along with anything new your app now depends on
• You start from the most recent version I sent you, rather than an older copy

You do not need to learn Git or any other developer tool for this. Export a zip from whatever AI tool you are building with and send it. That is the normal route, not a fallback. What matters is the state of the code inside the zip, not how it reaches me. You can ask your AI tool to confirm the four points above, and the free check below tells you for certain.

If you cannot send code that runs, the second option will serve you better. 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 unfinished because it will not run. Both of those climb as the app grows while the invoice stays flat. On one side: a lower price, your evenings, and no firm finish date. On the other: a higher price and a date.

Many owners start by writing the code themselves and hand it over as the app grows. That is normal. AI tools are genuinely good at building a first version. 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 starts happening, your app has reached the size where it needs an engineer. Ask me about switching.

How It Works

Every change request is quoted as one fixed price, split into equal milestone payments. 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 milestones below are otherwise the same either way.

Each milestone is agreed and paid for before that milestone's work begins, so you always know what the next payment is for.

Before Milestone 1: the free check

Send me the code before pricing 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 computer reported when it tried. There is no charge and no limit on how many times you can do this. Send it, fix it, send it again.

Nobody should be spending money to discover that the code was never going to run.

The free check does not include working out why it is failing. An error message names where things stopped, not what is wrong, and reading past it to the real cause is Milestone 1. 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. When you send the corrected version, checking it again is included at no extra cost.

If the corrected code still will not build, I will not send it back a third time. By then the problem is bigger than this one change: your app has grown past what an AI tool can reliably edit, and sending it back would cost you another weekend for the same result. I will quote the change as development work and build it for you instead.

Milestone 1: the production risk review

Code that runs is not the same as code that is safe to release. That check ran against an empty database and test settings. Your live app has your real data in it, your real settings, and your customers using it.

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

• The database changes, read against your real data. An automated check applies them to an empty database, where almost anything works. I read them against what is in your live one: whether the change deletes data you still need, whether it can be undone, and whether it will freeze part of the app long enough for your customers to notice. These changes run by themselves the moment the app starts, so this is the last point at which a bad one can be stopped.
• Settings. Any new setting, address, or key your code now expects has to exist on the live server before release. This is the most common way a change that ran perfectly for you fails the moment it goes live.
• Passwords and outside code. Any password or key that ended up written into the files, and anything new your app now depends on: whether it is still maintained, whether its license is safe for a business to use, and whether it has known security holes.
• Anything touching logins, payments, or sensitive data. These paths are read line by line, every time, no matter how small the change looks.
• What else the change touches, and the order to release it in. What other parts of the app share the code you changed, and what has to go out in which order so the app keeps working during the update.
• Calls and questions. Planning calls and walkthroughs for this change are part of this milestone, so bring your questions. That time is already paid for.

Deliverable: A written summary of findings and risks, with a plan for fitting the change in and putting it on the test address.

Milestone 2: fitting it in and putting it on a test address

This is where your code becomes a running app on a real server. Code that runs on your computer is not the same as code that runs in the cloud, and the work here is everything in between.

What is included:

• Recording your code alongside its history, so every change to your app can be traced and undone, whether or not you ever use those tools yourself
• Fitting the change into the live setup: every setting, address, and password it needs, held in a locked store rather than written into the files
• Applying your database changes to the test database in the right order, and confirming the database now matches what the code expects
• Releasing it to a private test address the same automated way it will later go live, then confirming the app starts, runs, and does the basics correctly
• You trying the new feature yourself on the test address
• One round of changes from your feedback, then another release to the test address for your final approval

Deliverable: A version you have approved, running on the test address and ready to go live.

What I need from you: Try the change properly on the test address and gather all your feedback into one list. That list is the included round of changes. Further rounds are quoted as their own milestone.

Milestone 3: going live and checking it

What is included:

• A final check of the approved version before anything moves
• Moving the version you approved from the test address to your live app, automatically
• Confirming afterward that the app is running normally and the new feature is working
• The previous version kept ready to put back, so if something is wrong it can be put back quickly

Deliverable: The new version live for your customers, confirmed working.

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.

A few fixes are cheaper than a Small change, because they are the same fix every time. Renewing a certificate before it lapses, adding a security header, moving to the current patch of what your app runs on, replacing a dependency with a publicly known flaw, correcting the records that let someone send email as your domain: each of these has a written procedure I have run before, and each is $150–$350 rather than a change request. If your fix is on that list I will say so and price it there. If it is not, it is a Small change, and no amount of it being quick moves it.

Small changes are collected and released together, up to three at a time. What a change costs is driven by releasing it, not by how much was edited: the test release, the live release and the checks around them happen whether the change is one line or one screen. 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.

Three is the limit for one group, because the review and your testing grow with each one 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. The group is fixed once the work is paid for, so anything you send after that goes into the next release. 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 the parts of a live app where a mistake is most costly, and are priced for the care they need. It works the other way too: a review can move a request into a smaller tier.

Writing the code yourself costs about half as much on the invoice. If you can clear the checklist below, that is a good deal and I am glad to keep working that way. If you cannot, the invoice is not the whole price, for the reasons in Which one is right for you? above.

What to Send When You Have a Change

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. 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

This gets your code accepted on the first try. If you are sending a description rather than code, skip it.

• It runs from a fresh copy. Send it and let me run the free check before pricing. 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 the easiest 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 an old copy silently undoes work that is already live.
• The database update file is included. If your change adds, removes, or alters anything the app stores, the file that updates the database has to come with the code. AI tools very often write the code and skip that file without saying so, and it is the most common reason a change that runs perfectly for you cannot be released.
• Nothing is missing. Every new file is in the zip, and anything new your app depends on is listed in the project rather than assumed to be there.
• No passwords or keys in the files. They belong in the app's settings, not written into the code. If you find one in there, tell me and send it separately.

This checks only that what arrived is complete enough to be worth reviewing.

If this sounds like more than you want to take on, hand me the code instead. For most owners it works out cheaper.

A Few Ground Rules

• Calls are part of Milestone 1. Planning calls and walkthroughs are already paid for.
• Checking whether your code runs is free. Working out why it does not is Milestone 1.
• Small changes are grouped, up to three, for one Small price. Urgent fixes go out on their own.
• You can switch between the two routes at any time, for any change. Decide per change; nothing locks you in.
• One round of changes is included at the test milestone. There is no limit on the total; each extra one is its own milestone.
• Nothing goes live without your approval on the test address.
• Small fixes are still changes. Even a one-line change goes through review and testing, because the risk is in releasing it, not in how much was edited.

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