For systems you built yourself

You built it with AI and it works. Now the shop depends on it

You knew what your shop needed, which is the part nobody can generate for you. What AI never volunteers is the unglamorous layer underneath: backups you have actually restored from, a login per person, an audit trail, migrations, and a test on the arithmetic you trust without checking. That is what we add, and you keep everything you built.

Have us look at it What it costs

Who this is for

It works. That was never the hard part

You described your shop to an AI, it wrote the thing, and now people other than you are using it every day.

That is a real achievement and we are not going to pretend otherwise. You knew what your shop needed, which is the part nobody can generate for you, and you got a working system out of it in weeks instead of a twelve month implementation.

The problem arrives later, and it is not a missing feature. It is the day the shop depends on it. A spreadsheet that breaks costs you an afternoon. A system that issues the job numbers, holds the hours and prints the packing slips cannot break, and the distance between those two situations is not more code. It is eight or nine unglamorous things that nobody puts in a prompt, because you only learn to ask for them after they have bitten you.

What breaks

Roughly in the order it tends to happen

These follow from how these systems get built, not from anything being badly written. Some will not apply to you.

A backup nobody has ever restoredA backup you have not restored from is a belief, not a backup. Half the ones we look at are writing to a folder on the same disk as the database, which covers you for an accidental delete and for nothing else.

Everyone is the same userSo when an operation gets voided, or an hour gets moved from one job to another, there is no answer to who did that and when. This is the one that ends arguments, and it is the cheapest thing on this list to add.

Nothing stops bad data at the doorTwo part numbers that differ by a trailing space. A quantity typed into the hours field. Once a few thousand of those are in, reports stop agreeing with each other and people quietly go back to the whiteboard.

It lives on a computer under a deskWhich is fine until the desk is in a building with one internet line, or the machine is also somebody's CAD workstation, or it is quietly the only copy.

The schema can only be changed by handSo you stop changing it. That is the moment the system starts working around the shop instead of the shop working through the system, and it is the most expensive item here because it is invisible.

Login is a shared password, or nothingUsually because the first version ran on one tablet by the saw and it never came up again. It comes up the first time you have to let a customer or an auditor see part of it.

No test on the arithmetic that mattersThe price roll up, the hours total, the quantity remaining. These are the numbers you will trust without checking, which is exactly why they need a test that fails loudly when somebody changes something nearby.

One person can read itYou. Which is fine right up to the week you want a holiday, or the day you want to sell the business and somebody asks what runs the shop floor.

What we do

Harden it. We are not here to rewrite your system

You keep the code, the data and the design decisions. The shop keeps using it while we work.

Read it and write down what it doesOne document: what the tables mean, what the screens do, where the money and hours are calculated. This usually takes a few days and it is the thing that makes everything after it cheap.

Backups, and one restore you watch us performOffsite, automatic, and tested in front of you once so you know what the bad day looks like before you have one.

A login per person, and an audit trail where it countsNot on everything. On the rows where somebody will eventually ask who changed this: hours, quantities, prices, voids.

Constraints and migrationsSo the database refuses obviously wrong data, and so the schema can change next year without you holding your breath.

Tests on the numbers you trustThe ones that would cost you money if they were quietly wrong for a month.

Move it somewhere it belongsYour own server or your own cloud account, in your name, with the floor still able to work if the internet drops. Not our hosting, not our account.

A runbook and a second pair of handsHow to restart it, what the alerts mean, what to check first when a number looks wrong, written so somebody who is not you can follow it.

Scope is usually three to six weeks, and it is deliberately boring work. Nothing on that list makes the system do anything new, which is the point: you already built the part that needed to know your shop.

Being straight with you

Three things worth saying before you call

Sometimes the answer is to carry on alone. If you are the only user, the data would fit in a spreadsheet, and losing it would cost you a weekend, you do not need us. Set up a real offsite backup, test restoring it once, and get on with your week. We will tell you that on the call rather than after an invoice.

Sometimes it genuinely should be replaced. If the thing has no clear boundary between the screens and the data, so that every change risks something unrelated, hardening it costs more than rebuilding the same design properly. That is an uncomfortable answer and we would rather give it in week one than discover it in month three.

We are not going to be rude about AI generated code. We use the same tools. The part that decides whether one of these systems is any good is whether the person driving it understood the problem, and you did, or the shop would not be using it. What AI does not give you is the operational scaffolding above, because nobody knows to ask for it the first time.

FAQ

Common questions

Are you going to tell me to throw it away and buy something?

No. In most cases the system already encodes how your shop actually runs, which is the expensive part and the part a commercial package will fight you on. We would rather make what you built dependable. If we do think it should be rebuilt, we will say so in the first week and explain exactly which part forces that conclusion.

Is AI generated code a problem to work with?

Not in itself. We use the same tools daily. What we find instead is that AI writes the features you asked for very well and never volunteers the things you did not know to ask for: backups, migrations, per user access, constraints, audit trails. That gap is consistent, which is what makes this work predictable to scope.

How long does it take and does the shop have to stop using it?

Three to six weeks for most of them, and no. Everything here is additive, so people keep booking jobs while we work. The one step that needs a quiet hour is moving it off the machine under the desk, which is usually a Saturday morning.

Do we have to move to the cloud?

No. Plenty of shops have a good reason to keep it on site, and a system the floor cannot reach when the internet drops is worse than one on a local server. What we insist on is that the backups leave the building and that the thing is not running on somebody's CAD workstation.

Who owns it when you are finished?

You do, the same as before. The code goes in your repository under your account, it runs on your infrastructure in your name, and the runbook is written so another firm could pick it up. There is no licence on our work and nothing that makes leaving expensive.

Keep exploring

ERP reportingReports your team can change
Systems integrationMaking two systems agree
Manufacturing softwareShop floor, scheduling and ERP gaps

Next step

Send us the repository and a description of your shop.

A free call, about forty minutes. If the honest answer is that you should carry on alone and just set up a real backup, that is what you will hear.

Email usmail@voliom.com