It has been at 90% for months, and every change breaks something else.
It was built in a tool that promised software without needing people. It worked up to a point. After that, every small adjustment knocks over something that was already right, and nobody can say why.
Before deciding whether to fix it, rebuild it or stop, you need someone to open up what is in there and tell you what they found.
Five questions about what is already built.
- What is exposed. An access key inside the code, a database open to the internet, customer data within reach of anyone who knows where to look.
- Whether it holds up. What happens with 100 people inside at once, and what is still pointing at test data.
- Whether it can be changed. Whether a small change can be made without knocking something else over, and what exists today that would warn you when it does.
- What it costs to run. The monthly bill for the infrastructure and the services, and how much of it is waste.
- Who owns the accounts. Domain, repository, database, payment provider — whose name they are in today, and what it takes to move them to yours.
The list is the same in every audit. It covers what most often goes wrong in this kind of build: production configuration still running on test data, a service key kept inside the repository, next to no automated tests.
A written diagnosis, and a price to fix what it found.
The audit is paid work and it ends in a document: what was checked, what was found, what is urgent and what can wait. Written for you to read, not for a programmer to translate afterwards.
With it comes a proposal at a fixed price to fix what was found. Accepting is optional.
It is not free, and that is deliberate. A serious audit costs the time of people reading what is in there, and the result is yours to use however you like.
The diagnosis is yours, and the fix is the size of its scope.
The document is yours the moment it is finished, and it works just as well if you take it to someone else to fix. What was found about access goes with it: what is in someone else's name, and what it takes to move it to yours.
If the fix follows, it gets a written scope and a fixed price like any other job, and the same guarantee. What the scope says is what ends up running, and the difference is corrected at no cost.
The limit is the same too: the scope. Whatever the audit found and you decided not to fix stays outside it, and becomes new work on the day it goes in.
At the end you have the code, the accounts in your name, a build that runs, and someone who answers for it.
Send the address of what is live.
The link to it, which tool it was built in, and what stopped working. That is enough for a first answer.
What we do with the message is on the privacy page.
hello@30labs.com.br