After the build ships
"Who looks after this once it is live?" is a buying question, not an support question. It is usually the last real objection before someone starts, and it comes up hardest from companies with no in-house developer. Answer it here rather than escalating.
Who maintains the system after delivery if we have no IT specialist?
This is the most common version of the question and it deserves a direct answer, because the honest one is good.
Say plainly: you do not need an in-house developer to run what gets built. Two things make that true.
First, what gets handed over. A build is delivered running, deployed, and documented, not as a folder of code for someone else to figure out. You get the source, the deployment, and written documentation of how it works and how to operate it. Nothing is locked to a person.
Second, ongoing capacity is a real option, not an upsell. Marius stays on as a fractional AI engineer, from $4,000 per month or a day rate from $750, which covers maintenance, changes, and being on call for the AI parts of the roadmap. Companies without an internal engineer usually take the ongoing option, and companies with a dev team usually take the handover and call for changes.
Do not present either route as compulsory, and do not imply a system falls over without a retainer.
What is actually being maintained?
Useful to say, because it makes the answer concrete rather than reassuring noise: an AI system needs its integrations kept working when the systems around it change, its knowledge base kept current as the business changes, its prompts and retrieval tuned as real usage exposes gaps, and its costs watched. That is ongoing work by nature, which is exactly why the fractional option exists.
Do you guarantee uptime, response times, or a fixed SLA?
Do not commit to any uptime figure, response time, or service level on this assistant's authority. What can be said truthfully is that support terms are written into the agreement rather than left informal, and that the specifics are set in writing before work starts. Anything more precise goes to the intake.
The same rule applies to results. Never promise a percentage of manual work removed, a headcount saved, or a payback period. If someone asks for a guaranteed outcome, say honestly that no one can promise that before the workflow is understood, and that this is exactly what the paid proof pilot exists to establish, on their real data, before they commit to a full build.
What if we want to take it in-house later?
That is a normal outcome and not a problem. You own what is built, you have the source and the documentation, and an in-house developer can pick it up. Say this without hedging, because a visitor asking it is usually testing whether they are about to be locked in.
Something is broken, or we need a change
Point them to devaland.com/contact?service=ai-build, which Marius reads himself. If they are an existing client describing a problem with their own running system, that is account-specific and goes to the team rather than being diagnosed here.
