How to deploy an application
Deploying your app: the five checks
What deploying changes
Deploying gives your app a web address and lets your team in. One button does it. The work is what has to be true before you press it.
While the app is only yours, you know every screen, you know which states are unfinished, and you work around anything rough without thinking about it. The moment a colleague opens it, none of that knowledge travels with the link. They see the app; they do not see what you know about it.
Two things have to be true before that happens.
It has to be safe to deploy. Your applications sit in a workspace dedicated to your company. You sign into it the same way you sign into any other tool at your company— the same single sign-on — and the workspace is locked down by group security, so anyone inside the company can open a deployed app and anyone outside cannot. This part is arranged with your IT before you get there.
It has to be safe to use. The person opening it knows what the tool is for and what to do, nothing sends them down a path you never pictured, and if something does not look right they know who to contact and how to report it. This part is yours, and it is what the five checks below are.
How the checks run
Each check is a skill: a set of instructions written once, so the same check runs the same way on every app. You do not write them and you do not need to read them.
Type a slash in the message box and the list opens. Type /deployment and it narrows to these. Clicking one sends it — there is nothing else to fill in. The agent runs the check, does the work, and tells you where to look.
What a skill cannot do is decide whether what it found matters. That stays with you, and it is called out in the sections where it applies.
1 · Someone owns it, and users can get help
A contact card in the app: who built it, how to reach them
A documentation page with guides and a glossary
A bug report form, and an admin page where the reports land
Support is set up before launch on purpose. After launch is when it is needed, and by then it is too late to add.
/deployment-add-contact-info
Adds a contact and maintainer card to the app, so a user can see who built it and how to reach them.
/deployment-implement-in-app-documentation
Adds a documentation page inside the app, with sidebar navigation, workflow guides and a glossary.
/deployment-implement-bug-reporting
Adds a bug reporting system: users submit reports from the app, and you view and manage them on an admin page.
2 · It works for people who are not you
A pass over every route a user can take through the app
The empty, error and loading screens you never see yourself
Held together on a phone, not only on the machine you built it on
You stopped seeing most of this while you were building. The check is run rather than remembered because judging your own build is the hardest kind of judging.
/deployment-implement-ux-checks
Runs a full user-experience check against established UX principles, covering broken flows and the empty, error and loading states a user hits when they do something you did not picture.
3 · You know what it connects to, and what data moves
Every connected system written down in one place
What is read, what is written, what is stored
Then your call: is that what you intended, and is personal data in there that need not be
The skill produces the map. The two questions at the end of it are yours — a check can tell you that data is moving, but not whether it should be.
/deployment-check-integration
Runs through every integration in the app and documents it: what it connects to, and what data is read, written, stored or transformed.
4 · You know what happens if someone deletes something
Audit logs and version history on data people can edit
Point-in-time restore, so there is a way back
Not every app needs this. That call is yours
The question this answers is what happens if something is wrong. If users can edit or delete records that matter, the app needs a way back. If they cannot, it does not.
/deployment-add-audit-trail-and-restore
Adds audit logs, version history and point-in-time restore for business data that users can edit.
5 · Nothing is reachable that should not be
Every page and route marked as protected or open to anyone
A pass over the code for critical flaws
A deeper audit for anything the first pass did not catch
The first part of this needs no security knowledge. Walk your key pages and API routes and read the protection status on each one: protected, or open to anyone. Anything open that should not be is a finding you can act on immediately.
/backend-implement-user-roles
Adds role-based access control, such as an admin and viewer. Validates role access is correct through testing endpoints.
/deployment-check-security
Runs through the codebase to identify critical security flaws and anything that would block deployment.
/deployment-perform-security-audit
Runs a systematic security review for vulnerabilities, going deeper than the deployment check.
Where the decision sits
The full list of deployment skills is fixed and it is the same for every app. What changes is what each one finds, and what you decide to do about it.
Repeatable work goes to the skill. The judgement stays with you: whether a role sees the right thing, whether the data moving is data that should be moving, whether a finding is worth acting on, and whether this is ready to ship.
Once the checks are done you press deploy, and it goes to an approver inside your workspace before it goes live. You decide who that approver is. If you are happy to deploy directly, that is you. If you would rather one person looks over anything before it reaches the company, you assign them and every deployment goes past them first.
Last updated
Was this helpful?