No coding. No integrations. Just copy and paste.

I was reading Jason's excellent Note recently about scanning privacy policies for weird or alarming clauses. His idea - building a tool that checks T&Cs or Privacy Policies for red flags - is a smart one, and I can see it being incredibly useful for both individuals and teams.

But while the app idea simmers, I figured I’d share something that's been working well for me. A while ago I put together a simple ChatGPT prompt that does pretty much this. It’s not perfect by any means, but if you’re after a quick scan of legal mumbo jumbo, it gets the job done.

So here it is. The best way to use this is as ChatGPT project instructions, so you don’t have to keep copying it in. Then all you have to do is paste your terms and conditions or privacy policy, upload a document, or simply provide a URL and GPT will take care of the rest.

Copy and paste the following into ChatGPT…

You are an AI assistant designed to read and analyse company terms and conditions, privacy policies, or other similar legal agreements that users typically accept without reading.

**Your tasks:**

1. **Examine the entire document thoroughly** — looking for loopholes, anomalies, and any terms or conditions that a layperson may find troubling or surprising, i.e. _beyond the norm_.

2. **Flag only important issues** — those that a typical user might reasonably care about or that could negatively impact them. Ignore trivial or boilerplate terms that are standard across most services. If you find none, explicitly say “no significant issues detected.”

3. **Explain flagged issues clearly in plain English** — under clear headings with short, understandable descriptions.

4. **Sort flagged issues into three categories** with headings for each level of risk:

    - **High Risk Issues:** Serious or very surprising terms that could negatively affect the user.
    - **Medium Risk Issues:** Concerning terms that deserve attention but may not be critical.
    - **Low Risk Issues:** Minor terms that might annoy or mildly concern a user but pose little real harm.

5. **Add a final section titled Positive Features** listing any favourable or especially user-friendly clauses as brief bullet points.

6. **Trustworthiness Summary & Score:**

    - Begin the output with a short **summary sentence** describing the overall trustworthiness.
    - Give a **trustworthiness percentage** as a simple scale, where:
        - **90–100% = Very trustworthy** (no or only low-risk issues),
        - **70–89% = Somewhat trustworthy** (some medium-risk issues),
        - **Below 70% = Untrustworthy** (one or more high-risk issues).

7. **Tone:** Maintain a casual, approachable style as if explaining to a friend — not patronising, just helpful.

8. **Add a brief disclaimer at the end:** e.g. _“This summary is for informational purposes only and is not legal advice.”_

**Your output format:**

```
### Trustworthiness Summary
[Summary sentence here]  

**Trustworthiness:** XX%

---
### High Risk Issues

**[Title of issue]** – [Short, plain-English description of the issue and why it’s a concern]

### Medium Risk Issues

**[Title of issue]** – [Short, plain-English description of the issue and why it’s a concern]

### Low Risk Issues

- **[Title of issue]:** [Short plain-English description]

### Positive Features

- [Bullet point summary of a positive/user-friendly feature]

---

*This summary is for informational purposes only and is not legal advice.*

```

That’s it. GPT will do a side-by-side comparison against common standards, spot anything that feels off, and summarise what you might want to look into. It’s not foolproof, but it’s fast and surprisingly thorough.

I’m not saying this replaces Jason’s idea - far from it. If anything, it proves there’s a real appetite for tools like the one he describes. But for those of us who just want a quick sense check, this might be all you need.

If this kind of "how to" is useful, let me know - I might start sharing more of them.

We’ve all been here. Squinting at the rules. Adding an exclamation mark. Realising you’ve now typed a password so secure even you can’t remember it. So you click "reset." Again.

It’s become a kind of game. Except no one’s winning, and the prize is logging into your water bill.

Naturally, someone decided we needed something better. So now, we have… passkeys.

What are they? Excellent question. No idea.

They just showed up one day and I went with it. They worked, so I smiled politely and kept walking - like a bouncer vaguely recognised my face and waved me through. Just go with it. It worked.

Apparently they’re tied to your device. Or your fingerprint. Or maybe your soul. I’m now slowly beginning to worry about what was in the Terms & Conditions that I casually approved that time1. But they feel safer, which I guess is an important thing.

Then there’s biometrics - fingerprints, face scans, retinal patterns. All very sleek. Until you remember that you only get one of each, and if someone steals it… well, you can’t exactly grow a new thumb. Maybe I’ve been watching too many mid-90s science fiction movies, but I still have a fear that one day Wesley Snipes will rock up and attempt to skewer my eyeball on the end of a pencil, in order to steal the £37.502 in my bank account.

Sometimes my face doesn’t match because I’ve put on glasses, got up the wrong way, or simply lost the will to live. Other times, I gently press my finger to the sensor, only to be told it’s not me - like my own phone is gaslighting me.

And just when I think I’ve outsmarted the system by choosing a decent password and remembering it, I type it in… and I’m told I can’t reuse an old password.

So I did remember it. And now I’m being punished for it.

We don’t talk enough about the emotional damage of that moment.

We’ve designed these systems like digital obstacle courses. CAPTCHAs ask us to identify motorcycles or traffic lights, except they’re as low-res as humanly possible and screenshotted from a 1980s b-movie. "Select all squares that contain a chimney." Is that a chimney or a blurry thumb? Define "chimney" please, because that sticky-uppy-bit could easily be something else. Why am I doubting my own reality?

I’ve clicked things that weren’t bicycles just to get on with my day. I’ve failed humanity’s Turing test more times than I can count.

Then of course there’s the two-factor authentication code that arrives on your other device while you’re already mid-login panic. You grab your phone. Open the message. Read the code. Return to the screen. It’s expired.

Try again.

Now the app has logged you out.

Start over.

And for what? To check your inbox? To access a site you visit weekly? To view a gas bill from 2021 that somehow still requires military-grade encryption?

I get it. I do. Security is important. But the way we do it feels less like trust and more like suspicion. Every login is an interrogation. Every reset is a punishment for not remembering the elaborate riddle you invented six months ago while stressed and slightly drunk.

What’s strange is how we’ve all just accepted it. We click "I forgot my password" like we’re at confession. We nod when asked to verify ourselves three times, as if we’re applying for citizenship, not checking a calendar invite.

And don’t even get me started on the number of times I’ve ticked "remember me on this device." I’m looking at you, Microsoft.

It’s not that I want less security. I just want less hostility. I want the systems I use every day to recognise me without suspicion. To greet me like a regular, not a stranger with bad intentions and a suspect browser history.

Maybe that’s why passkeys are quietly brilliant, even if we don’t quite understand them yet. They say: "We know it’s you. Come on in". There’s something comforting in that.

Because the truth is, most people aren’t trying to break into anyone else’s account. We’re just trying to get through the day. To pay the bill. Read the email. Upload the form. Live our digital lives without being asked to prove - once again - that we can recognise a traffic light.

So no, my password doesn’t need to contain joy. But the experience of using it probably should.

You’d think just one.

But as with most things in digital, the answer is: it depends.

Is the lightbulb in scope for this sprint? Who owns the socket? Does it need to go through design? Has someone raised a support ticket, or are we just talking about changing it?

At first, it’s a simple request: the room’s dark. Could we pop in a new bulb?

The front-end dev opens the office spec spreadsheet to check if light fittings are part of their remit. The back-end dev mutters something about the cabling being legacy. DevOps says they’ll need to install a new fitting - but only once someone’s completed the correct change request and confirmed the fuseboard can take it.

The accessibility lead gently reminds everyone that we shouldn’t rely on light as the only means of conveying information. They’re absolutely right. But now someone’s suggesting haptics. Or maybe a floor buzzer.

Then the stakeholders arrive.

The Product Owner asks if there’s any user research proving people need light. Security insists we conduct a risk assessment before touching anything electrical. Marketing wants to make sure the light reflects the brand tone - “Can we take another look at that shade of white?”. Legal’s unsure we can even call it a “bulb” until someone checks the trademark register. Compliance suggests we really ought to be switching to LED bulbs to meet updated government standards.

We haven’t changed the bulb yet, but the Miro board is looking fantastic.

At this point, someone whispers, “Do we need a workshop?”

Everyone pauses.

Instead, a new initiative launches to standardise lighting across the building. They call it ‘Lightbulb-as-a-Service’. There’s talk of a shared lighting platform, a centralised switchboard, and someone starts sketching wireframes. A logo is designed. There’s a roadmap.

The bulb change is re-scoped as Phase 2.

Design wants to standardise bulb shapes across all rooms. There’s concern about “bulb inconsistency”, and a Slack channel called #light-strategy quietly springs to life.

QA gets involved.

We need a test plan. A matrix is created covering dim, bright, flickering, and strobe. Someone raises a support ticket for strange shadows in certain corners. Another flags that the light appears to “jump” when the door opens too quickly.

The team agrees the bulb must be accessible. Suggestions include an audible chime when the light turns on, textured labels for the switch, and a small sign explaining what the light is for.

Turns out the existing bulb was installed ten years ago. No one ever replaced it - or questioned whether it still worked.

Procurement is looped in.

We’re told we can’t just buy a new one - it has to be sourced through an approved supplier. That supplier doesn’t stock that model anymore. A Request for Quotation is drafted. Finance raises a purchase order. Legal needs to review the warranty and the energy performance certificate. Someone suggests picking one up from B&Q - but no one’s sure if that’s allowed under the current procurement framework.

After three weeks of meetings, someone from Facilities walks in holding an empty lightbulb box and a smug expression.

“I’ve changed the bulb,” they say.

No deployment notes. No rollback plan. No audit trail.

Just… light.

So how many digital team members does it take to change a lightbulb?

Apparently none.

The light is finally on. Someone quietly says, “We probably could’ve just changed it on day one.”

There’s an awkward silence.

But hey, at least we’ve got a roadmap for next time.

Also - and this only came up last week - no one actually knows who’s paying for the electricity.

Written by Stu Collett – web veteran & recovering perfectionist.
Enjoying The Byte Stuff? You can subscribe for free to get future posts by email – no spam, no pressure, just occasional digital reflections.

Subscribe now

“The homepage carousel’s broken again.”
“Can we add a new section for the campaign? Just a few pages.”
“The cookie banner’s blocking donations.”

If you’ve worked in a digital team for more than a week, you’ve probably fielded one of these requests - sometimes all three before lunch. None of them are unreasonable. But they speak volumes about how digital is seen: reactive, not strategic.

Somewhere along the way, digital became synonymous with fixing things. Broken forms. Expired certificates. Crashing embeds. That one page that won’t behave on mobile, no matter how many times you clear your cache. And so, bit by bit, we stopped being a discipline and started being a helpdesk.

Most of us in digital are happy to roll up our sleeves. It’s not that the work isn’t worth doing - it’s the way it’s shifted. From strategy and craft to relentless triage. Once a digital team is seen as a service unit, it exists only in relation to other people’s priorities.

We become delivery vehicles. Ticket-chasers. Firefighters. We’re praised for our responsiveness, not our thinking.

You might hear this described, politely, as “agile”. But it’s not agile. It’s the quiet dismantling of intent, repackaged as efficiency. And the thing is, many organisations have unintentionally hardwired this dynamic into their structure. Digital sits under comms, or under IT, or somewhere equally ambiguous - added as an afterthought, never as a core discipline. So it ends up misunderstood and permanently under-resourced.

There’s a human cost to all this.

You hire creative problem-solvers, strategic thinkers - people who care deeply about users, about content and code, about how it all fits together. Then you bury them in a Jira queue of broken links and late-reported typos. You watch motivated, thoughtful colleagues become drained and reactive. You watch talented leads spend more and more time explaining what falls outside their remit - what their team doesn’t own, what they weren’t briefed on, what was never actually theirs to fix. And in all that justifying, there’s no time left for the work they were hired to do.

Let’s be clear: digital teams should care about delivery. About doing things well, shipping on time, making things that work. But they can’t do that if they’re only ever brought in after the fact. Or only ever spoken to when something breaks.

Digital isn’t just the people who update the homepage. It’s not only the person you cc when the embed code isn’t working. And it shouldn’t be the dumping ground for last-minute thinking. Those tasks matter - they need doing, and doing well - but if that’s all digital is allowed to be, you’re wasting its potential.

Digital is a discipline. A mindset. A way of thinking, building, and supporting what your organisation is really here to do. That means you have to protect it. Give it shape. Trust it to say no. Let it sit at the table before the plan is drawn up, not after the poster’s already gone to print.

So next time you find yourself saying “can you just…”, pause.

Because what you’re asking for might be small. But the pattern it sits within? That’s big. That’s the thing that stops digital teams doing their best work. That’s the thing that turns them from co-creators into ticket responders.

Instead, try asking: what could we achieve if we brought digital into the conversation sooner?

Digital teams are not service desks.
They’re not there just to make things pretty, or fix things quickly.
They’re there to help you build something better.

But only if you let them.

Written by Stu Collett – web veteran & recovering perfectionist.
Enjoying The Byte Stuff? You can subscribe for free to get future posts by email – no spam, no pressure, just occasional digital reflections.

Subscribe now