7 Things You Should Know About Your App
Obvious, or pointless? This article sums up what's worth tracking, and why. If your app has been running for years, or you've ever taken over someone else's, you probably already know it pays to have a clear picture.
Overview & context
The classic: an app gets built, shipped to production, and in the best case just gets security updates from then on. Then two or three years later someone needs to add a feature, migrate to a better provider, a customer needs a deployment for a new branch and new people need onboarding, or someone just needs to figure out why the app does what it does. And suddenly there's a problem: the information probably exists — just scattered across different places and documents.
1. Basic identity
Name, a short description, author and license — the first things you want on hand. If you're in an app you don't know, this quick overview helps you get your bearings immediately. You'll know right away whether it's an internal tool, a commercial product, or someone else's code you're just maintaining.
2. How the app came to be
If it was built (even partly) with an AI tool, keep links to the AI project or the prompt archive. It makes later decisions easier, and if your AI agent didn't comment the code well enough, the original prompts can still tell you what functionality you actually asked it to build.
The original brief, early studies, analyses, architecture decisions — all of this information is deceptive, because at the time it's created, it all feels obvious. Document it carefully and you're most of the way there. Make sure it's easy for everyone involved to reach. And it matters even just to know that documentation exists, even if you don't personally have access to it!
3. Source code and architecture
A link to the repository or repositories, plus any helper scripts and tools the project relies on.
A developer always knows this — they can always find the project on GitHub, Azure DevOps, GitLab, or wherever it's hosted. But if you manage dozens or hundreds of projects with different code names or old working titles, finding your way to the right repo gets hard, and it only gets worse over time. Attach the repo directly to the app, and you save yourself time and nerves.
4. Documentation and API
Technical documentation, specifications, and API descriptions — not so they exist on paper, but so someone actually finds them when they need them.
Sure, Swagger's enough — just add `/swagger` to the base URL. And it's all in Postman too, just open the right collection. But what if you maintain several API versions, the docs live in an external service, and on this particular project you already switched to Bruno instead of Postman because you're planning to migrate? Attaching the links directly to the app heads off exactly this kind of confusion.
5. Where and in which environments it runs
Production, staging, test environments — where they run, who hosts them, and which version is currently deployed.
If you deploy to multiple environments, whether by hand or via CI/CD, you definitely already have this information. Or rather, your DevOps team has it. But your customers, support colleagues, and anyone else working with the app should have it too. It makes troubleshooting, planning new features, and checking everyone's on the right version much easier. And believe it or not, it's genuinely satisfying to see, from one place, exactly which versions are deployed across every environment for every customer.
6. Tasks, support, monitoring
Where do bugs get reported, where does the backlog live, and where does a user turn with a problem?
Links to your monitoring dashboard, task tracker, and user support — even for a purely internal app used by a handful of people in the company, add at least an email or some contact for the right person. And if you use Jira, YouTrack, or another helpdesk, link straight to where a new request gets filed.
7. Security, legal and business
If you publish the app publicly, there's no avoiding GDPR, terms of service, and various other descriptions of how the app is operated.
Does the app have specific security requirements? What are the legal terms of operation? What are the business terms and license agreements? Who's responsible for running and maintaining it? This information is worth having on hand — it's like insurance: you won't appreciate it every day, but when a problem hits, you'll be glad it's there.
Usually exactly at the moment of an audit, an inspection, or a security incident — when you need to respond fast. It's not enough to have this information; you also need to know where it is.
In short
You almost certainly already have all the information above — it's just often scattered across people's heads, a README, Slack, emails, discussions and notes. And all of it is about the app. Which is the whole point — keeping it together, in the app.
Want all of this in one place?
Add your first app to aboutthe.app for free and fill in everything from this article.