The stack that actually ships software engineering tools.

Short answer: An engineering team needs six categories of tool: editor, version control, CI/CD, tracker, communication, observability. Everything else is decoration. The one decision that compounds is version control — every other tool integrates with it. Most teams over-tool by adding three CI providers, four code-review apps, and two trackers; the fix is to pick one in each category and stop.

A software engineering team requires the following six categories of tools: editor / IDE, version control, CI/CD, issue tracker, team communication, observability. Anything that isn’t a core capability is either fancy or specialised. Despite the rotation of products the categories in 15 years have remained unchanged.

The reason this matters is because each extra category you add into the stack adds a context switch and a new failure mode. Teams who ship consistently are usually undertooled, rather than overtooled. Meaning they have one of each thing and use that well. When a team encounters this situation, they often face three competing CI providers, four code-review applications, and a tracker that their team avoids using in favour of a Slack channel.

In this article, we will look at the six categories, the products that fit into which, the one category that determines the rest, over-tooling as a failure mode and when even the most basic stack is overkill. Engineering mangers, leads and ICs assessing or justifying their tool stack.

The six categories

Every category is truly essential for a team that ships software frequently.  Should one either of the six fundamentals be unavailable, the team compensates for it by creating workarounds (a wiki tracker instead of a tracker, code-review Slack channel instead of code review queue, log file grepping instead of monitoring).

Just one product per category is the right answer. It’s fine when the team has a good reason to use two eg. GitHub for VCS + Linear for issues (even though GitHub has Issues). The incorrect option includes three products in any given category, because then the team has to remember “I’m using this one for that case”.

The one decision that compounds — version control

Use version control if you deliberately change one tools decision. Say this helps you to plot best solution in style choices using new tools. Continuous Integration is activated by code commits. Problem solvers are connected to PRs.  The version control system host is where code review takes place. Errors are traced back through commits by observability.

Git is the default in use. The host (GitHub, GitLab, Bitbucket, self-hosted) is the part that the teams choose and live with for years, and the host's integration surface into your tracker, CI and chat ends up shaping daily workflow more than the editor ever will.

GitHub is the most popular, has the largest ecosystem, and has the deepest third-party integrations. At scale, though, it is price (and the historical “we host everything on GitHub” trade-off; this has stabilised with Microsoft ownership but reamins a risk).

The combination of all functionalities like VCS, CI/CD, issues and container registry in one product makes GitLab the all-in-one option.  The integration is tight; the trade-off is you commit yourself to the GitLab ecosystem instead of best-of-breed per category.

Bitbucket is a major Jira integration play; naturally, it’s an Atlassian product. Preferable if the organization is already using Jira; otherwise, less so. The same principle applies to whichever tracker you run — the closer the host-to-tracker hook, the less context-switching, which is why we ended up rebuilding our GitHub integration rather than wrapping a third-party bridge.

Gitea or an open-source version of GitLab CE.  Increased operational cost.

Choose a host that suits the organization. Avoid making frequent changes to ERD, once in a few years would suffice. Each migration takes up months of working time across the team and the tooling muscle memory takes a long time to rebuild.

Editor / IDE — the smaller decision

Selection of IDEs is largely individual and guided by the team. Decisions at the team level.

• Pick one shared formatter / linter config. Whoever uses what IDE, the code should look the same.
• Don't mandate the IDE. Mandate the formatter. Engineers using different editors should produce identical-looking code.
• AI assistance is now part of the IDE category. Cursor, GitHub Copilot, Claude Code, JetBrains' AI. The team can have preferences; the policy should be about what gets committed (does the AI's suggestion pass the team's tests and review?) not what gets used while writing.

The mathematics of smaller stories: cycle times drop from days to hours and teams reach users up to 14× faster – and modern IDE + AI workflows are part of why. Once upon a time, stories that took a day now can take an hour. According to a Dutch expert on software metrics, the flow metric (cycle time) tells you when the AI is actually adding value. In contrast, the vendor’s “lines of code suggested” tells you nothing — the DORA research program lands in the same place when it ranks delivery throughput over surface-level activity.

CI/CD — the integration question

The CI/CD selection depends on the host of the VCS.

• GitHub → GitHub Actions is the path of least resistance.
• GitLab → GitLab CI built in.
• Bitbucket → Bitbucket Pipelines.
• Multi-VCS or specific needs → CircleCI, Buildkite, Jenkins.

Specialist CI providers like CircleCI and Buildkite are needed when you need to run CI jobs in parallel, use specialized hardware (like mobile builds), or have advanced features (like test splitting or large-scale build caching). For most teams, the host-native CI is good enough; the time saved on integration outweighs the loss of best-of-breed features, and a tracker-side webhook is usually a few clicks away — our CI/CD integration list is one example of how shallow that wiring should feel. The mental model behind it is still Martin Fowler's original CI definition: integrate continuously, keep main green, automate the build.

The CI policy is more important than the CI choice.

• Tests run on every PR. No exceptions.
• Tests are fast enough to run on every PR. If they take 45 minutes, engineers stop trusting them.
• Failing tests block merge. Not "fail open"; not "the CI is flaky, ignore it for now".
• Deploys are scripted and idempotent. Not "Sam runs the deploy script from his laptop".

Most CI/CD failures are not about the tools; it’s about the discipline. The tool might impose some moderation (branch protection, necessary checks), but the team needs to strive for discipline.

Issue tracker — the productivity bottleneck

This information was already fully elaborated in our issue tracking systems guide. The short and sweet version.

• Five fields per issue, no more (title, reporter, assignee, severity, state).
• Four workflow states (New, In Progress, In Review, Done).
• Search has to work, with stable URLs.
• Notifications you can actually trust.
• One ordered backlog — priority is the order, not a column.

Exactly this pattern is what LiteTracker is built around: single ordered backlog; story-only velocity; one owner per card; no Gantt charts. The discipline behind that ordered list is its own skill — see backlog refinement done in the right dose for what "enough, not more" looks like in practice. Other tools (Jira, Linear, GitHub Issues) can be set up the same way; they just come with different defaults.

Team communication — Slack and its discontents

Slack (or Teams or Discord) is the undisputed frontrunner in the sector. The important choices.

• Channel discipline. Too many channels and people miss things. Too few and signal drowns in noise.
• Public over private by default. Most decisions belong in channels where future team members can find them.
• Async over sync. Long-form decisions belong in docs, not threads.
• No call-by-default culture. Synchronous calls are expensive; default to text.

Using Slack Is Acceptable. The teams are fine. Discord works well! It's the discipline; not the tool that counts. Most teams are more broadly suffering from organisational communication problems, not a communication tool-shaped problem. A simple swap of tool will not fix a bad organisation.

Observability — the category that earns its keep late

You never know when observability tools will pay back   log, metric, trace, alert. Teams with good observability spend minutes diagnosing any production issues.  Teams without observability spend hours.

The least stack.

• Structured logging in production with a queryable backend (Datadog, Honeycomb, CloudWatch Insights, plain ElasticSearch).
• Metrics dashboards for service-level signals (latency, error rate, saturation).
• Alerts on the metrics that matter, with paging on real problems and notification on warnings.
• Distributed tracing for multi-service architectures; optional but valuable.

When you think about it, the bar for observability that actually works isn’t super high: you can find last week’s logs in under a minute, you can eyeball service latency, you get paged when something’s broken. Many team have lesser than this and don’t get to know the gap until an incident happens.

The over-tooling failure mode

With enough teams, one pattern emerges: teams acquire tools more quickly than they remove them. A new project manager, a new continuous integration provider, a new code review app, a new AI assistant. After six months with the team, 14 tools are used on a day-to-day basis, and nobody can ramp a new hire without a half-day setup.

The solution is procedural: When a new tool is introduced, a decision needs to be made to determine which existing tool the new one replaces. In the case that nothing is replaced, the addition has to justify why two competitive tools are worth the price.   The majority of additions fail this evaluation.

Another failure: tools not being updated. The decision log has nothing, the wiki has DRAFT pages dated 2 years, the tracker has 200 issues no one sees. The issue does not lie with the tool. It lies with the cadence of regular maintenance. We don't just remove the tool, because the need will still be there. The answer depends on committing to a maintenance cadence or removing the tool.

When even the basic stack is overkill

The frank instances.

• Solo developer, side project. Git + VS Code + a deploy script is enough. CI is overhead; observability is "look at the logs".
• Two-person early-stage team. Slack + GitHub + a shared doc covers most needs. Add tooling when the team grows past four.
• Short-lived prototype. If the code is being thrown away in a month, don't invest in the stack. Use whatever works fastest.
• Hackathon / time-boxed experiment. Same logic — invest in tools at the speed they earn their place.

If you belong to every other category of people, yes, that means you get one in each of the six categories already mentioned above and stop.

A real opinion on AI coding tools

AI coding tools are IDEs, not a seventh category. Most teams over-invest in them, relative to impact. They are useful, but let’s keep things in perspective   AI does not change everything.

Tools like Cursor, Copilot and Claude Code are good. They help with your boilerplate, help with the unfamiliar, help with first drafts. To my knowledge they are never the bottleneck. Usually, the bottleneck causes unclear requirements that can be fixed in the issue tracker, slow CI that can be fixed in the CI/CD, broken observability that can be fixed in the observability tool, and distributed decision making that can be fixed in the comms.

Utilize the AI tools as they assist. Don't expect them to resolve issues in other categories. Throughput maths – it’s really more about the six categories, than about which AI assistant is in the IDE.

Frequently asked

What tools does every software engineering team need?

The six categories are/editors, version control, CI/CD, issue tracker, team communication and observability. Choose only one product from each category; avoid adding a second to any category unless justified.

What's the most important tool decision?

git usage. CI runs on commits, coal faces in PRs, the host carries out the code review, and observability links errors to commits, every other tool integrates with VCS. If you get this right, it will pay off.

Do small teams need CI/CD?

Certainly! Even for low-scale teams. Bugs are more common with manual deploys. To be minimally compliant, an application must have a script that runs tests on every PR. The script must also deploy on merge to main. GitHub Actions or GitLab CI are both fine.

What's the difference between an IDE and a code editor?

In the past, an IDE typically includes a debugger, builder, and refactor function. In contrast, an editor was lighter weight. The distinction has lessened; Visual Studio Code is really an editor but has IDE-like capability via extensions. When making decisions about tool stacks, treat them the same.

Should we use GitHub or GitLab?

It depends on what other needs you have. When it comes to the largest ecosystem, GitHub is the winner. The all-in-one option consisting of VCS + CI + issues, is GitLab.  Opt for GitHub if you are looking for best-of-breed across categories. Choose GitLab if you want to reduce the number of vendors you rely upon.

Is Jira required for software teams?

No. Numerous teams utilize Linear, GitHub Issues, LiteTracker, and others. Larger teams resort to Jira but smaller ones go for lighter options.  The relevant features apply to any tracker: single ordered backlog, story-only velocity, fast search.

What observability tool should I use?

It depends on your scale and budget. The most-deployed enterprise option is Datadog. Most-loved by teams running distributed systems is Honeycomb. The open-source default is Grafana + Prometheus. It is necessary for the vendors to be less concerned as compared to getting the right logs to respond to "What broke?" in minutes.

How many tools should an engineering team have total?

On average six to ten being used actively every day. If the team context-switches more, the team is distracted; vice-versa and the plan isn’t clear. The actual number matters less than that each tool is used and up-to-date.

Still stuck

The six-category tool stack features software tools software teams absolutely need to be successful at delivering value. Most disagreements about tooling come down to which vendor in each category; the bigger decision is whether you’ve committed to one in each and stopped adding more.

LiteTracker is your choice if you want a tracker that’s the one product in the issue-tracker category   single ordered backlog, story-only velocity, no Gantt charts. Unlimited users are welcome in our free tier. If you’re a solo developer or hackathon team, skip the formal stack and just ship.

In either case, take one from each category, then leave the stack untouched for two years and ship product instead.