Dream big. Build now.
Trust forever.

You cannot tell by using it. An AI-built application that works correctly tells you almost nothing about whether it is safe, and the gap between the two is wider than most people expect.

The SusVibes benchmark tested AI coding agents on 200 real feature requests drawn from 108 GitHub repositories. Of the solutions produced by SWE-agent with Claude 4 Sonnet, 61% were functionally correct but only 10.5% were secure. The app runs. The app ships. The app is not safe.

You are also likely to be more confident than you should be. A peer-reviewed study presented at ACM CCS 2023 found that developers using an AI assistant "wrote significantly less secure code" and "were more likely to believe they wrote secure code than those without access."

In practice the model's code is rarely the worst problem. Failures cluster in the layer around it: secrets committed to public repositories, database row-level security left open, authentication logic inverted, no rate limiting, backups nobody has ever restored. Invicti scanned 20,656 AI-generated web applications in November 2025 and found 1,182 of them used the literal string "supersecretkey".

This is not a hobbyist problem. Security firm RedAccess examined around 380,000 publicly accessible assets built on tools like Lovable, Base44 and Replit and found roughly 5,000 containing sensitive corporate data, including medical records, financial data and internal corporate documents (reported by Axios, May 2026). Somebody in your organisation has almost certainly built something this way already.

Finding this requires somebody to actually look. That is what our first gate, Mitigation and Security, is for. We check your code against best-practice frameworks: OWASP Top 10 audits, PII leak checks and credential validation. We can test against international standards including ISO 27001, SOC 2 and HIPAA, and against your own internal standards if you have them.

Production ready is a checklist, not an adjective. If somebody tells you an application is production ready and cannot hand you the list, it is not.

The minimum list:

• No secrets in client-side code or in the repository. RedHunt Labs scanned around 130,000 published AI-built sites and found roughly 26,000, one in five, leaking at least one secret.
• Authentication and database access rules verified by someone who did not write them.
• Backups that have been restored. A backup nobody has restored is not a backup, it is a hope. If you cannot say when you last restored one, you do not have working backups.
• Monitoring with a human at the end of it. An alert firing into an unread inbox is not monitoring.
• Rate limiting, so one bad actor cannot run up your bill or take you down.
• A rollback path you have used at least once.
• Enough documentation that somebody other than the original author can run it.

Most AI-built applications fail on secrets, backups and monitoring. Most legacy applications fail on documentation and rollback. Both fail on the same thing underneath, which is that nobody was ever given the job of checking.

We run every application through five gates and issue a production-ready stamp when it passes: Mitigation and security, Efficiency and cost, Stability and architecture, Surveillance and maintainability, Yield and integrity.

Answer it honestly and fix what it exposes. In that order.

The questionnaire is not really a test of your paperwork, it is a proxy for one question: can this supplier be trusted with our data. Founders consistently report that certification does not make the questionnaire go away. One founder on Hacker News: "In my industry they still ask for the questionnaire even if you have a SOC2 report!" Another, on the alternative: "Without a SOC2 you will be asked to fill out an insane 200+ questionnaire."

You do not need SOC 2 or ISO 27001 to answer a security questionnaire. You need to be able to answer the questions truthfully, and that is where AI-built applications tend to come apart. The questionnaire asks who has access to production, how secrets are managed, how often you patch, what your backup and recovery process is, and whether you have logging. If the honest answer to several of those is "I am not sure", the problem is not the questionnaire.

The fastest route through is usually not certification. It is getting the underlying answers to be true, then having something credible to point at.

That is what our production-ready stamp is for. It gives you documented, auditable confirmation that the product is safe to deploy, in a form you can show to stakeholders inside and outside your business. We can also help you complete the questionnaire itself, using the output of the five gates as the evidence base.

Almost always fixed. The problems in AI-built applications are overwhelmingly configuration and deployment problems, not architecture problems, and configuration is cheap to fix.

Look at what has actually gone wrong in public:

• CVE-2025-48757. Researcher Matt Palmer scanned 1,645 Lovable projects in March 2025 and found 303 endpoints across 170 projects, about 10.3%, with inadequate database row-level security. That is a settings problem.
• A Lovable-built app exposed 18,697 user records in February 2026, including 870 with full personal data. The cause, per the researcher who found it: "The guard blocks the people it should allow and allows the people it should block. A classic logic inversion that a human security reviewer would catch in seconds."
• Base44 had an authentication bypass in July 2025 where an attacker could create a verified account on a private application using only a non-secret app ID. Reported on 9 July, fixed on 10 July.

Those look like consumer-tool stories until you notice where these applications end up. The same tools are used by product managers, analysts and operations teams inside established companies, usually without anybody in engineering being told. That is what makes a settings-level mistake expensive: it is not a side project that leaks, it is a real customer list.

None of those needed a rewrite. They needed somebody to look.

Rebuilding also throws away the thing that is genuinely valuable, which is the business logic you have already proved works, and it puts you back at the start of the same class of mistakes. Our starting point is always to learn what you have before touching it.

There is occasionally a real case for rebuilding, and it is almost always architectural rather than cosmetic. The clearest example is a monolithic application sitting on a single shared database when the business actually needs a multi-tenanted one. No amount of hardening fixes a data model that cannot do what the business needs it to do. We will tell you when that is the situation, because finding out eighteen months later is considerably more expensive.

There are 168 hours in a week. A standard working week covers 40 of them. Your team is covering less than a quarter of the time your software is exposed, and the other 128 hours are the ones nobody generally has a plan for.

Most companies solve this by quietly asking the same three or four engineers to carry the batphone. That works until it does not. It is one of the most consistently discussed problems in engineering: "Ask HN: Any luck negotiating better terms for on-call?" drew 120 comments, and "All Engineers are now expected to be part of a 24/7 on-call rotation" is a thread title that needs no explanation.

The maths of a rota is unforgiving. To put somebody on call every night without wrecking them, you need enough people that any individual is on the rota rarely. Below that number you are not running a rota, you are running a small group of people who never fully switch off. That shows up as attrition long before it shows up as an outage, and replacing a senior engineer costs considerably more than covering the nights.

Two things worth knowing before you shop. Cheap outsourced monitoring exists at sub $500 a month, and the people using it report quality varying sharply. There is a real difference between a team who can fix your application and one who can only acknowledge an alert and escalate it back to you. One founder searching for the former put it plainly: "I really want a service with a team vs an individual."

Ask any provider one question: when the alert fires at 4am, who acts on it, and what are they authorised to do without waking anyone on your side? If the answer is "we notify you", you have bought an expensive pager and your engineers are still on call.

We offer three levels of cover:

Level	What it covers
Business hours	Cover during the working day, alongside your own team.
Out of hours	Evenings, nights and weekends. Your team owns the working day, we own the other 128 hours.
24/7	Continuous cover, every hour of every week.

Out of hours is the one most teams actually need and almost nobody sells. You already cover your working day perfectly well. What you cannot staff is the rest of the week, and that is precisely the part that costs you people rather than uptime.

Response time is 15 minutes or less on every level, with immediate escalation to our engineers across multiple global locations (so they are awake and ready to go). That is not a promise to notify you within 15 minutes. It is a promise that somebody who can act has started acting.

All three, and the boundaries are worth being explicit about, because the industry documentation stops short of describing this case.

Every major cloud provider publishes a shared responsibility model, and all of them describe two parties. AWS: "Security and Compliance is a shared responsibility between AWS and the customer." Microsoft: "Regardless of the type of deployment, you always retain the following responsibilities: Data, Endpoints, Accounts, Access management." Google, on infrastructure services: "the bulk of the security responsibilities are yours."

None of them describes what happens when a managed provider sits in between. So here is our version:

Concern	Cloud provider	Messy Works	You
Physical infrastructure, hypervisor, network backbone	✓
Operating system patching and hardening		✓
Application configuration and secrets management		✓
Monitoring, alerting and incident response		✓
Backups, and testing that they restore		✓
Application code and business logic		✓ shared	✓ shared
Who has access, and to what			✓
What data you collect and why			✓
Your legal and regulatory obligations			✓

On that shared row, the split is simple. You own what the product does. It is your business logic, your roadmap and your decisions about what it should be. We own the condition it is in. We are responsible for changes we make, for the standard the code is held to, and for telling you plainly when something you have asked for creates risk. If you or your team push code we have not seen, that code is yours until it has been through the gates.

Two things stay yours no matter what: your data and your identities. Every cloud provider says so, and so do we.

You also keep the keys. We do not hold your infrastructure hostage, and if you host in your own cloud your bill goes to your provider on your existing terms, passed through at cost and never marked up.

Sources: AWS · Microsoft · Google Cloud

Yes for reading and documenting it. No for changing it unsupervised. The distinction matters more than anything else in this question.

AI is genuinely good at reading unfamiliar code and explaining what it does. Where it fails on old systems is context. A developer with twenty years of experience described the problem precisely on Hacker News, working on a twenty-year-old medical codebase:

"One of the reasons the AI fails constantly is that it has no context of the entire code base. It simply can't keep that context in scope for every session. So it actively adds bloat to the system unless it's guided by a skilled developer who already knows the system."

And from the same discussion, the real cost:

"we had to dif through the code base the old way to confidently accept/reject what Claude was telling us."

That is the honest position. The bottleneck is not whether AI can read your system. It is verification, and verification is expensive, which is why most teams start this and stop.

The problem is also getting worse on its own. A US Government Accountability Office audit examined ten critical federal legacy systems ranging from 8 to 51 years old, and noted that COBOL "has a dwindling number of people available with the skills needed to support it". Only two of the ten agencies had modernisation plans meeting best practice.

Our first stage is exactly this: learn your system, document it properly, and restructure it so AI tooling can work on it safely thereafter. We do the verification, so you get the output without the risk. In most cases that first stage takes less than two weeks.

No. This is one of the most common misconceptions we hear, and the UK's own guidance does not say what people assume it says.

The Information Commissioner's Office does not require personal data to remain in the UK. It defines a restricted transfer, which is sending personal information to, or making it accessible to, a separate organisation outside the UK, and sets out the safeguards you need when you make one. Its warning is about protection, not geography: "People risk losing the protection of UK data protection law if their personal information is sent (or made accessible) outside the UK."

UK government guidance is blunter still: "There is no government policy which directly prevents departments or services from storing or processing cloud-based data in any specific country." It goes on: "It is the responsibility of each government department to take risk-based decisions about their use of cloud providers for the storage of government data regardless of the geographic location of the data."

On the EU side, the European Commission's adequacy decisions for the UK were amended on 19 December 2025 and run until 27 December 2031, so EEA organisations can send personal data to the UK without additional safeguards during that period.

What this means practically: you have a choice, and it should be a risk decision rather than an assumption. Some contracts and some sectors do impose residency requirements, and those are real. A general legal requirement to keep data in the UK is not.

We can host in the UK, the EU or the US, in multiple locations across Australia, and elsewhere in Asia Pacific, including Singapore and Hong Kong. Where a customer specifically requires it and holds the relevant domestic registrations and representation, we can also host in China. We will tell you which we would pick and why.

This is general information, not legal advice. Take your own advice before relying on it. Sources: ICO on international transfers · ICO on receiving data from the EEA · GOV.UK cloud guide

No. This is one of the most common misconceptions we hear, and Australia's own guidance does not say what people assume it says.

The Office of the Australian Information Commissioner (the OAIC) is direct about it: "Generally, no. The Privacy Act does not prevent an organisation or agency from engaging a cloud service provider to store or process personal information overseas." The Privacy Act 1988 (Cth) does not require personal information to be kept onshore.

What it requires instead is Australian Privacy Principle 8 (APP 8), the cross-border disclosure rule. Before an APP entity discloses personal information to an overseas recipient, the OAIC's guidance says it must "take such steps as are reasonable in the circumstances to ensure that the recipient does not breach the APPs in relation to that information." Under section 16C of the Act, the entity stays accountable for what the overseas recipient does with the data afterwards. The principle is that protection travels with the data rather than stopping at a border.

What this means practically: you have a choice, and it should be a risk decision rather than an assumption. Some contracts and some sectors do impose residency requirements, and those are real. A general legal requirement to keep data in Australia is not.

We can host in the UK, the EU or the US, in multiple locations across Australia, and elsewhere in Asia Pacific, including Singapore and Hong Kong. Where a customer specifically requires it and holds the relevant domestic registrations and representation, we can also host in China. We will tell you which we would pick and why.

This is general information, not legal advice. Take your own advice before relying on it. Sources: Privacy Act 1988 (Cth) · OAIC on sending data overseas · OAIC on APP 8

Usually a service credit, and almost never compensation for what the outage cost you. This is the least understood thing in managed hosting and it is worth being direct about.

Read the AWS EC2 SLA, which is representative of the industry:

"Unless otherwise provided in the Agreement, this SLA sets forth your sole and exclusive remedies, and AWS' sole and exclusive obligations, for any unavailability, non-performance, or other failure by us to provide Amazon EC2."

If AWS misses its 99.99% target, you get a percentage of your bill back. If the outage cost you £40,000 in lost orders, that is your loss.

The percentages are also smaller than they sound:

Uptime	Allowed downtime per month
99%	about 7 hours 18 minutes
99.9%	about 43 minutes
99.95%	about 22 minutes
99.99%	about 4 minutes

The number to interrogate is not the percentage. It is these three:

1. How is downtime measured, and who measures it? Self-reported uptime measured only at the infrastructure layer can be 100% while your application returns errors.
2. What is the response commitment, as distinct from the uptime target? Uptime tells you how often things break. Response time tells you how long you wait.
3. Who declares an incident? If you have to notice and report it, your SLA starts when you wake up.

Here is what we commit to, and why it is split in two.

Response, on every level of cover: 15 minutes or less, with immediate escalation to our engineers across multiple global locations. This applies whoever owns the infrastructure and wherever it runs, because it is entirely within our control.

Uptime, when you host on the Messy Works platform: 99.95% as standard, or 99.99% on our high-availability offering. Those are real numbers because we own the infrastructure, we chose the architecture, and we can build in the failover that makes them achievable.

If you keep the application in your own cloud, we will not quote you an uptime percentage. Not because we are hedging, but because an uptime figure is a function of three things we would not control: who owns the infrastructure, where it is hosted, and how the application is architected. An application with no hot failover cannot deliver 99.99% no matter who is watching it, and any provider who tells you otherwise on infrastructure they do not own is selling you a number rather than an outcome.

What we will do in that case is tell you honestly what your current architecture can achieve, what it would take to reach the next tier, and whether that is worth the money for your business. Then we commit to the thing we genuinely control, which is how fast a competent human starts working on it.

The build was never the expensive part. That is why systems everyone agrees are terrible are still running.

The question gets asked constantly now. From Hacker News in August 2026:

"Now that apps can easily be re-implemented with AI, what is keeping businesses from rebuilding them? [...] the cost to rebuild and deploy is much lower than what they are losing."

The answer is in the risk list, which somebody considering exactly this move wrote out themselves:

"LLMs seem great at accelerating scaffolding and iteration, but unclear how much they reduce operational complexity, data correctness issues, migration risk, long-tail customer edge cases, and support and accountability costs."

AI has made writing code dramatically cheaper. It has not touched data migration, the decade of edge cases encoded in your current system that nobody documented, regulatory re-approval, retraining, or the fact that the new thing has to be right the first time because the old one is being switched off.

One honest note on the statistics. You will see rewrite failure rates quoted everywhere. We do not quote them, because we could not trace a single one to a checkable source. They all descend from the 1994 Standish CHAOS report, which was taken apart in a peer-reviewed paper: "we have attempted to provide reasons to doubt the 189% average cost overrun value as it is interpreted by most of its users" (Jørgensen and Moløkken-Østvold, Information and Software Technology, 2006, DOI 10.1016/j.infsof.2005.07.002). Anybody selling you a modernisation project on the back of a rewrite failure percentage has not checked where it came from.

There is a third option between leaving it to rot and rebuilding it. Learn the system properly, document it, harden it, and get it to a state where modern tooling and AI can safely work on it. That is usually faster, cheaper and very much less risky than starting again.

Your developers can almost certainly do this. The question is whether it is the best use of them, and whether they should be the ones checking their own work.

Three honest reasons companies bring us in anyway.

It is a different discipline. Your team is built to ship features, and they are measured on shipping features. Hardening, observability, incident response and compliance evidence are a separate craft with a separate set of habits. Asking a product team to do both usually means one of them gets done properly, and it is rarely the one nobody is chasing them for.

Nobody should sign off their own work. This is the same principle every serious engineering organisation applies to code review, and it is why our production-ready checklist includes authentication and database access rules verified by someone who did not write them. An independent pass finds a category of problem that a self-review structurally cannot, which is the thing you assumed was fine because you were the one who built it.

Rotas do not scale down. Covering nights and weekends needs enough people that no individual carries it too often. Most teams do not have that headcount to spare, so it lands on the same three engineers.

We are not here to replace your developers, and any supplier who suggests otherwise is selling you something worse. We are the people they hand the pager to, so they can go back to building the thing you actually hired them for.

You take everything and go, and it does not take a negotiation.

This matters more with us than with most suppliers, because we work on software you own rather than software we sell you. So the position is simple:

You keep the keys. Your cloud accounts, domains and repositories stay in your name throughout. We work inside your ownership, not around it.

If it runs in your cloud, your bill stays yours. It goes to your existing provider on your existing terms, passed through at cost and never marked up.

The documentation is yours. Everything we produce getting your system through the gates, including what we learn about how it works, is written down and handed over. That is the artefact that makes leaving possible, and it is the thing most suppliers quietly do not give you.

No exit fee, and no hostage period. Our notice period is 60 days and we agree a 12 or 24 month term up-front.

The uncomfortable question to ask any managed provider, including us: if we left tomorrow, what would we not be able to run without you? If the honest answer is anything at all, that is not a partnership, it is a dependency. UK government guidance names this directly, warning that lock-in is where "switching from one technology or provider to another is difficult, time consuming and disproportionately expensive".

We would rather you stayed because leaving would be easy and you chose not to.