Skip to content
fulcrum
Contact

Studio notes

You shipped an app with AI and people use it. Here is the layer around it

Fulcrum KD · Studio · 2 October 2026 · 8 min read

You shipped an app with AI and people use it. Here is the layer around it: illustration

If you built an app with AI tools and strangers now rely on it, six things sit around the product that most builders have not put in place yet: a penetration test, SOC 2, terms of service, a true privacy policy, data protection duties by country, and the basics of secrets, backups, tests and authorisation. Do them in that order.

What you built, and what sits around it

Start with what is true. You have a working product. People you have never met sign in, do something they value, and some of them pay for it. You did that without a team, a funding round or a year of planning. Most software ideas never get that far, and plenty of funded teams never get there either. Nothing below takes that away.

What the AI tools did not build is the layer around the product. That layer exists because strangers now depend on you. It answers questions nobody asked while you were shipping: who else can read this data, what did the user agree to, what happens in the first 72 hours after a breach, and what does a bigger customer's procurement team want to see before they sign. Each answer is a piece of work with a known shape.

The order matters more than the speed. Fix the basics from You built an app with AI and people use it. Now what? first: secrets out of the code and rotated, a backup you have actually restored, tests around signup and payment. Then check for the authorisation bug yourself with a second account. Then a test by someone else. Then the paperwork. Then the audit, when a customer asks for one. This week: run the secrets search and the second-account check. Both are free and both fit in an afternoon.

The order to build the layer in

Each step makes the next one cheaper. A penetration test on an app that still has secrets in the bundle mostly finds the secrets.
Each step makes the next one cheaper. A penetration test on an app that still has secrets in the bundle mostly finds the secrets.

A penetration test

A penetration test is a person, paid by you, trying to get into your app the way an attacker would, then writing down what worked. It is different from a scanner. A scanner looks for known patterns. A tester reads how your app behaves, guesses at what the assistant left out, and tries it. The output is a report: what they got in through, how serious it is, and what to change.

What a test looks for has a public reference. The OWASP Top 10, which OWASP calls 'a standard awareness document for developers and web application security', lists the most serious web application risks by consensus. In the 2025 edition the first entry is Broken Access Control, the same class of bug as the authorisation problem above. Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection and Authentication Failures follow it. A tester works through those categories against your app, and a report that names them lets you check the coverage yourself.

This week: read the ten category names on the OWASP page and, for each one, write a sentence about where it could apply in your app. Where you cannot write the sentence, that is where a tester will look first. How to scope a test, what to ask for in the report and what one costs is in penetration testing an AI-built app.

SOC 2, and what it is for

SOC 2 is a report, not a certificate. An independent accountant examines the controls you run over your service and reports on them against the AICPA's trust services criteria: security, availability, processing integrity, confidentiality and privacy. The AICPA says these reports give users 'information that is needed to assess and address the risks associated with outsourcing services'. In plain words, a customer is about to rely on your system and wants someone independent to say what you actually do.

You do not need one on day one. You need one the day a customer's procurement team asks, and it is slow to produce, because the auditor looks at controls that have been running, not controls you set up last week. That is why it sits last in the order. The work that feeds it is the same work the earlier steps produce: access control, logging, backups, and a written way of handling incidents.

Something for this week: decide whether your customers are consumers or companies. If they are companies, name the largest one you would like to sell to and find out whether it asks suppliers for a SOC 2 report. What the report covers, what the auditor needs from you and how long it takes is in SOC 2 for an AI-built app.

Terms of service and a privacy policy that is true

Terms of service are the contract between you and each person who uses the app. They say what the service is, what the user may not do with it, what happens to their account and data when either side ends it, and how far your liability goes. If the terms were generated alongside the code, they may describe a different product. A clause promising 99.9% uptime you never measured, or a refund window your payment code does not honour, is worse than no clause at all.

A privacy policy is a statement of fact, and it has to be true. It says what personal data you collect, why, where it goes, how long you keep it and how someone gets it deleted. The list of third parties goes stale fastest. The analytics script, the error tracker, the email provider and the AI API you call all receive personal data, and each belongs in the policy. A policy that leaves them out is not true, and a policy that lists things you do not do is not true either.

This week: open your privacy policy and your dependency list side by side. Every service that receives a user's email address, IP address or content should appear in the policy. Write the gaps down. Which clauses matter for a small software business, and how consumers differ from business customers, is in terms of service for an AI-built app and a privacy policy that is true.

GDPR, the ICO and serving users by country

If you are in the UK and your app stores personal data, two duties already apply. The first is the data protection fee. The ICO's page says that 'organisations (including sole traders) that use personal information need to pay a data protection fee, unless they are exempt'. The regulations set three tiers. An organisation with turnover of £632,000 or less, or 10 or fewer staff, pays £52 a year, with £5 off for direct debit. The exemptions cover processing such as staff records, your own marketing and your own accounts. A product that holds users' data is doing something else, so run the ICO's self-assessment before assuming you are exempt.

The second is breach reporting. The ICO's guide says: 'You must report a notifiable breach to the ICO without undue delay, but not later than 72 hours after becoming aware of it.' The clock runs from discovery, not from when the breach happened. Not every breach is notifiable. If a risk to people is unlikely you do not have to report it, but you must document why you decided that, and you must keep a record of every breach either way. If the risk to people is high, you must also tell them directly, without undue delay.

Users outside the UK bring their own rules, and which ones bite depends on where your users are. The EU has its own GDPR, and a number of US states have passed privacy laws of their own. This week: check whether you have paid the ICO fee, and write a one-page breach plan that names who decides whether to report and where the record lives. The country-by-country picture is in GDPR by country for an AI-built app.

What Fulcrum does

Fulcrum is a UK software studio. The first step is the free Code Health Check at /code-rescue. The studio reads the codebase, runs the secrets and authorisation checks above, and sends back a plain-English note saying what is solid, what is fragile and what is dangerous. You keep the repo, the accounts and the keys throughout, and there is no obligation after it.

After the check, the work is fixed-scope. That means a scoped penetration test with a report you can hand to a customer, terms and a privacy policy written from what the code actually does, the ICO fee and a breach plan put in place, and the controls a SOC 2 auditor will later look for. Each piece is agreed before it starts, and you keep building the product while it happens.

If you would rather do it yourself, the pieces linked above are written for that, and the rest of the guides are on the tips page. Either way, the order holds: basics, authorisation, test, paperwork, audit. The product you shipped is the hard part, and it is already done.

Common questions

Do I need all six before I take money from users?
No. The floor is the basics and the authorisation check: secrets out of the code, a restored backup, tests on signup and payment, and a second account that cannot read the first account's data. The rest follow in the order above. SOC 2 only matters when a customer asks for it.
Does the ICO data protection fee apply to a one-person app?
The ICO says organisations, including sole traders, that use personal information need to pay unless they are exempt. The lowest tier, for turnover of £632,000 or less or 10 or fewer staff, is £52 a year under the 2018 regulations as amended. The exemptions are narrow, so use the ICO's self-assessment rather than assuming.
How long do I have to report a data breach in the UK?
The ICO's guidance says a notifiable breach must be reported without undue delay and not later than 72 hours after you become aware of it. If a risk to people is unlikely you do not have to report it, but you must record every breach and document why you did not report.
Is a vulnerability scanner the same as a penetration test?
No. A scanner matches known patterns and is poor at authorisation, because it cannot know that one record belongs to a different person than the next. A penetration test is a person working through the OWASP categories against your app and writing a report on what they got in through.

Written with AI assistance and edited by a human before publication.

// read next