FAQ - Questions, answered plainly

Yes, that’s exactly who I work with. The tool you built it with doesn’t matter. If it’s a web app that people sign into and that stores data, I can get it online safely.

Often you should, and I’ll say so if that is where you are. That hosting is one button, it costs very little, and for a lot of apps it is all you ever need. What changes the answer is needing to say where your data is kept, needing an environment you can reproduce, or needing a release you can undo. Those are answers about the account your app runs in, not about your app. The longer answer is here.

Web apps: something people open in a browser, usually sign into, that stores their information. That covers the large majority of what people build with AI tools. If you’re not sure yours fits, send it over and I’ll tell you honestly.

Yes, I need your project files. You don’t need to set anything up first: a zipped folder, or whatever your AI tool exports, is fine. Putting your code somewhere safe and versioned is part of the work I do. The setup guide walks through everything you send.

Your code needs to live somewhere that keeps a history of every change and can put updates live for you. Azure DevOps is what I use for that by default. If you’d prefer GitHub, say so and I’ll set you up there instead. Either way the account is yours.

What it costs depends on the size of the work: how much there is to build, how much is already there, and what has to be sorted out first. You get a dated timeline in the written plan at the end of the first milestone, before any building begins. See how a deployment works.

Every engagement is quoted. Scope varies too much for a price list, and the only figure a list can honestly carry is the smallest job on it. What it costs depends on the size of the work: how much there is to build, how much is already there, and what has to be sorted out first. You get one fixed price before any building starts, and it does not move once agreed.

Because the honest number depends on what the work is, and a published figure would anchor every conversation to the smallest job on the list. A deployment is a fixed piece of work and carries a floor. Building a pipeline, taking over releases, or picking up a codebase is not, so it gets a quote instead.

Your cloud provider bills you directly, and you only pay for what your app uses. Picking the right size is part of what I do, because paying for capacity you never use is the most common way these bills get large. The written plan names every service you will be billed for, so you can price it yourself before you commit.

Yes, and it is a piece of work on its own. I read what you were billed against what the application actually used, and write up where the money goes, what could come off, and what each change would take. Every figure is an estimate rather than a promise, read-only access is all I need, and nothing is changed until you have seen the report and said so. If your bill is under about $500 a month I will tell you it is not worth buying.

Only what the work needs, and never the level of access that would let me lock you out or change your billing. The exact permissions are listed up front in the setup guide, before you grant anything.

Yes. Every permission is granted to my account from inside yours, so you can withdraw any of it at any time, and all of it the day we finish. Your app keeps running either way. More on how your project stays secure.

Checking it is part of the first milestone, before anything goes live. If something needs fixing, you hear about it in plain language, with what it would cost and whether it can wait. Nothing goes live until you have approved it.

Yes, and it is a common shape. They own the application code and I own the infrastructure, the pipeline and the release, which is a clean line because the two rarely need the same person. Where the line sits gets written down before the work starts.

Yes, that is exactly what it is for. It covers every account, password, and security setting in plain language, so anyone who needs to check what is in place can read it: your team, a customer’s security reviewer, or the next engineer. Here is an example.

Everything runs in accounts you own, so nothing depends on me still being here. Every permission I was granted is withdrawn the day we finish, and the handover is written so somebody else can pick it up. More on how your project stays secure.

You do. Everything is built in cloud accounts in your name: the servers, the place your code lives, and the app itself. I have access while we work together and none after, and nothing stops working when it ends.

Nothing ties you to me. When your app goes live you receive a written handover covering every account, password, and security setting, so you or whoever you hire next can pick it up without needing to ask me anything. Here is an example.

Usually, and in whatever size fits. That runs from a daily check that it is up and its security settings still hold, with a written report each month, through to an agreed number of hours a month for hands-on work. The first few months after a launch are when most of the questions arrive, so that is usually when it is worth having. It is quoted with the rest of the engagement.