The situation
You have an editor, an AI assistant, a code host, a deployment service and three dashboards open. They all promise to help you build, but it is unclear which one owns the code, which one runs it and which one only reports what happened.
The idea in one paragraph
A tool category is a job, not a brand. Editors change files, repositories preserve versions, runtimes execute code, databases keep structured data, hosting makes a result reachable, and observability tools report what the running system did. Name the job before choosing the product. That keeps a familiar logo from becoming the answer to every problem.
The jobs around a small project
| Category | Main job | Question it answers |
|---|---|---|
| Editor or agent | Change project files | What should we change? |
| Repository | Preserve versions | What changed, and when? |
| Runtime or host | Execute and serve | Where does this run? |
| Database | Keep structured state | What must survive? |
| Logs and monitoring | Report behaviour | What happened after launch? |
How it actually works
Most products combine several categories, which is why the boundaries feel blurry. An editor may run commands, a host may include a database, and an AI agent may reach all of them. The useful test is still the same: identify the underlying job, then identify which tool currently owns it and what access that tool has.
What this changes for you
- Describe the missing job before searching for a product.
- Keep a short list of which service owns code, data, deployment and logs.
- Remove overlapping tools when you cannot explain why both are needed.
Where it breaks
Categories do not tell you which option fits your budget, region, scale or risk. They also hide bundles: replacing one product may replace several jobs at once. Check the dependencies before switching.
Terms used on this page
- Repository: a versioned record of project files and their changes.
- Runtime: the environment that executes a program.
- Observability: evidence, such as logs and measurements, about a running system.
Read next
Where data lives explains the state that must survive after a command or session ends.