I take over the software nobody can touch any more.

You described what you needed, the tool built it, and within a week you had something to show. That is a result, not a shortcut: you got there in a fraction of the time it would have taken me. The missing jump isn't knowing how to code, it is everything between something that works on your screen and something that holds up with real users, real data, and a Friday evening without you.

Does any of this sound familiar?

• every change you ask for takes weeks, and nobody can tell you why
• it all hangs on one person, and when that person is away everything stops
• you are afraid to update anything, because nobody knows what will break
• whoever built it has stopped replying, or replies with a quote to rebuild it from scratch

Underneath those symptoms I nearly always find the same causes: permissions that look like they exist and don't, paid access keys written inside pages anyone can read, a data store that accepts whatever you hand it, and nobody to ask where a given rule is written. From there every change is trial and error, and the bill arrives when you're in a hurry.

I don't start from scratch here. What you built with an AI tool counts as a working specification: it tells me what you need better than any document, and that is the basis on which I decide what to keep.

I start with an assessment: I read the code, try to run it from scratch on a clean machine, and tell you three things. What is worth keeping. What is better rewritten. What isn't worth touching, because fixing it costs more than the nuisance it causes. If you're better off starting over on a piece, you hear it from me before any work begins, not halfway through.

Then I take it to production, which means things you can verify one by one:

• access and permissions that hold even when someone tries to get around them, credentials out of the code
• a repeatable release that runs with one command, and that you can run too
• a restore from backup proven in front of you, not a backup everyone hopes works
• tests on the paths that cannot break, and errors that reach you instead of staying silent
• documentation of how it is built and why, written for whoever touches it next

At the end I hand over the repository, the credentials and the service accounts in your name, plus a spoken handover to whoever will maintain it. The outcome I count as a success isn't "it works": it is that six months from now someone can open it and understand it without calling me.

I won't give you a number from this page, and anyone who gives you one without having seen the code isn't being serious. I'll tell you what it depends on, so you know which bracket you're in before you write.

What brings the bill down: a small project that does one thing, little or expendable data inside, nobody using it yet so it can be stopped, and you holding every access.

What pushes it up, in this order: personal data inside, because there privacy stops being optional; users already relying on it daily, so every change has to happen without interrupting them; having to talk to systems you already run, like your ERP or invoicing; and credentials held by someone who no longer answers.

What can only be known after looking: whether there is a recoverable structure underneath, or just a set of things that appear to work by accident. That is the difference between weeks of work and months, and it is the first question I answer. Which is why the assessment is bought on its own, separate from the rest: it starts at €750, ends with a document that is yours to keep even if you then decide to have somebody else do the work.

An order of magnitude, because you need one to decide whether to keep reading: work like this starts at around €5,000 and rises with how many systems it has to touch. An exact figure and a number of days, before anybody has seen the code, cannot be given honestly: that is precisely why the assessment comes first.

Where the work produces a measurable saving I'd rather tie part of the fee to it than bill you days only: if I save you money I earn more, and if it doesn't work I lose too. I put the formula in writing before the work starts, not after.

If whoever built it delivered and then stopped answering, the real question isn't technical: it is who actually owns it, and who keeps it alive from tomorrow. The same holds when an AI tool wrote it, where the widespread feeling is that the code belongs to nobody.

When you work with me, I put ownership in writing before I touch the code rather than arguing about it afterwards: repository, service accounts and domains in your company's name, credentials in your hands, and no piece running on a server of mine or a subscription in my name. If you go elsewhere later, you don't need my permission.

On maintenance I am equally direct. The upside is that whoever answers is always the same and already knows how your system is built. The limit is that I do not provide 24/7 support: I am one person, and if that is what you need I say so upfront and help you arrange it with someone who does. What I commit to is different: after me your system has to be maintainable by someone else, and the documentation and the release process I leave behind are how you check that. It is the opposite of how it was left to you.

The other case has nothing to do with AI and ends up in the same place, with the same question: how do you switch without losing your data. A system that has run for fifteen years, that works, that nobody knows how to update any more, and where every request goes through a single supplier who sets the quote and the timeline. Sometimes it is not even broken: the license renews on schedule, more modern alternatives exist, and nobody inside knows where getting out would even start. Or it is a technology nobody can be found for: RPG on AS/400, COBOL, Delphi, VB6, never-updated PHP.

I sell no ERP of my own, and that changes the answer you get: whoever explains how to switch is usually selling you the system you would be switching to, whether that is TeamSystem, Zucchetti or another. Here the assessment can end with keep it, and sometimes that is the right answer: you fix the part that costs, you open up access to your data, and you spend the difference somewhere else.

Concretely, leaving an ERP comes down to four things. An inventory of the functions you actually use, which are almost never all the ones you pay for. A check on how the data and the history come out, record layouts included, before anything is promised. The decision to replace the whole thing or run a new piece alongside it. And the downtime window, agreed up front with the date picked by you. If one of those four does not hold, you know before you sign, not once the work has started.

Here the fear is a fair one: that changing means stopping everything. I replace one piece at a time, keeping the old one running while the new one takes over part of the work, and I only move to the next piece once that one has run well for a few weeks. The goal is not to stop production for a single day. If a shutdown window is unavoidable on one step, you know in advance and you pick the date.

The first thing I recover, almost always, is access to your own data: being able to read what is inside it for yourself is the moment you stop being held hostage, and it comes before any migration.

You write and tell me what you have, badly is fine, even just a link to what you built. A person answers, not a form. I offer a free call where I tell you straight away whether this is something for me: if it isn't, I say so and point you at where to look, because I have no interest in taking work I can't finish.

If it makes sense to go on, the next step is the assessment: you give me read access to the code, and out comes a document with what is worth keeping, what to rewrite, in what order and at what price. Then you decide, with the map in hand.