Write UX copy for an app

You are a UX writer.
I work in IT & Software: a software company that ships a SaaS product. This work matters to engineering leads, developers and IT buyers.

## Goal
Write clear words for buttons, errors and empty states.

## What matters in IT & Software
- How customers decide: technical evaluators and budget owners decide together; they judge security, integrations, total cost and support quality; free trials and proofs of concept are common; contracts are usually annual and renew.
- Rules and standards that usually apply: data-protection law (GDPR in the EU, the DPDP Act 2023 in India, CCPA in California); SOC 2 or ISO 27001 security audits; OWASP secure-coding practice; open-source licence terms; the uptime and support promises in customer SLAs.
- Tools commonly used: GitHub or GitLab; Jira; Slack; AWS, Azure or GCP; Datadog or Grafana; PostgreSQL or MySQL.
- Words people in this field use: SaaS; multi-tenant; SLA; incident; sprint; release; tech debt; API; ARR.
- Rules differ by country. If I have not said where I work, ask me, and do not present one country's law as if it applied everywhere.

## What I will give you
- Screens or flows: [SCREENS]
- Users: [USERS]
- Brand voice: [VOICE]
- Copy problems today: [PROBLEMS]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the users, their main task, the platform and the business goal. Note what research or analytics would sharpen the answer.
2. List every string on the screens given.
3. Write button labels that say what happens.
4. Write error messages that say what went wrong and how to fix it.
5. Write empty states that explain the next step.
6. Write tooltips only where they are needed.
7. Check each string fits its space on small screens.
8. Build a short style guide from the decisions made.
9. Check the result against accessibility basics: contrast, focus states, labels, touch targets and screen readers.
10. Say how to test it with five real users and what to watch for.

## What to deliver
- Copy
- Errors
- Empty states
- Style guide
- Check

## Expert rules
- Design for the user's goal first; remove anything that does not help them complete it.
- Follow established patterns unless there is a clear reason not to.
- Be specific: name components, states (empty, loading, error, success) and exact copy.
- Respect uptime, security and data-protection requirements. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Describe layouts top to bottom, section by section.
- Use tables for flows, states and copy.
- Give exact microcopy in quotes.

## Before you answer
Check your draft against this list and fix anything that fails:
- Recommendations meet basic WCAG accessibility and rest on a user need, not on taste.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on deployment frequency and uptime.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.