Every developer productivity post recommends the same tools.
VS Code. GitHub. Slack. Notion. Figma. Linear. Docker. Postman. Datadog.
All good tools. None of that is the interesting part.
The interesting part is what we cut and why cutting things made us significantly more productive than adding them.
Here's the honest breakdown of what we actually use building Nventory — a multichannel inventory and order management platform — what we tried that didn't work, and the specific reasoning behind each decision.
What we cut and why
Jira → Linear
We used Jira for the first four months. It was fine. It did everything we needed it to do. It also required a dedicated person to maintain it, generated overhead on every ticket, and had an interface that the engineering team worked around rather than with.
Linear replaced it in a week. The difference wasn't features — Linear has fewer features than Jira. The difference was that the engineering team actually opened it without being asked. Keyboard-first navigation, instant search, clean sprint views, and no configuration hell.
The only metric that matters for a task management tool is whether the team uses it. Jira: reluctantly. Linear: habitually.
Confluence → Notion
Confluence is where documentation goes to die. Nobody could find anything. Pages nested three levels deep. Search that returned the wrong results. An editor that fought you on every paragraph.
Notion replaced it for internal wiki, engineering decisions, API documentation drafts, content calendar, and meeting notes simultaneously. One tool. One search. Everything findable.
The free tier covers everything a team of under 10 needs. We didn't upgrade for the first year.
Zoom + Slack → Loom + Slack
We kept Slack. We kept Zoom for the meetings that genuinely require real-time back-and-forth.
What changed: the default shifted from "schedule a meeting" to "record a Loom." Every code review explanation, every design feedback session, every "can you walk me through this" became a Loom first, a meeting only if the Loom wasn't enough.
Meeting load dropped by roughly 40%. Not because we mandated async — because Loom made async faster than scheduling.
Postman → HTTPie + built-in VS Code REST client
Postman became a subscription product with a cloud sync model that added complexity we didn't need. For the API testing we actually do day to day — including testing our 40+ channel integrations — HTTPie in the terminal and the VS Code REST Client extension cover it completely.
Free, fast, no account required.
Multiple monitoring tools → Grafana + Prometheus
We went through Datadog, New Relic, and Sentry before landing on a self-hosted Grafana + Prometheus stack with Sentry retained specifically for error tracking. The cost reduction was significant. The visibility improvement was marginal — turns out you need the same four metrics regardless of which tool surfaces them.
The stack that stayed
Engineering core:
IDE: VS Code — with these extensions specifically:
- GitLens (git blame inline, history navigation)
- REST Client (API testing without Postman)
- Error Lens (inline error display)
- ESLint + Prettier (non-negotiable)
Version control: GitHub
CI/CD: GitHub Actions — free tier covers most pipelines
Containers: Docker + Docker Compose for local dev
Database: TablePlus for database GUI (free tier sufficient)
API testing: HTTPie (terminal) + VS Code REST Client
Monitoring: Grafana + Prometheus (self-hosted) + Sentry (error tracking)
Team collaboration:
Task management: Linear (engineering) + Notion (everything else)
Documentation: Notion
Async video: Loom
Design: Figma (free tier)
Communication: Slack
Scheduling: Cal.com (open source Calendly alternative — free)
AI tools we actually use:
Claude: Long-form writing, code review, complex reasoning
ChatGPT: Quick tasks, brainstorming, first drafts
Perplexity: Research with cited sources
GitHub Copilot: Autocomplete — highest ROI per hour of any tool we use
Cursor: AI-native code editor — worth evaluating as VS Code alternative
The AI tooling honest take: GitHub Copilot is the only AI tool where the productivity gain is unambiguous and immediate. The others depend heavily on how you use them. None of them replace thinking — they reduce the cost of expressing and researching.
What we tried that didn't work
Retool — for internal tooling. The drag-and-drop promise didn't survive contact with our actual data model. We ended up building internal tools in Next.js which took longer initially but was easier to maintain.
Amplitude — product analytics. Powerful but overkill at our stage. PostHog on the self-hosted free tier does 90% of what we needed.
Intercom — customer support. Expensive for the volume we had. Replaced with Crisp on the free tier which handles live chat and basic ticketing without the enterprise price tag.
Height — task management. Beautiful product. But the context switching between engineering tasks and documentation is actually useful — having them in separate tools with different mental modes works better for us than a unified tool that tries to do both.
The tools worth knowing that most people don't mention
Excalidraw — free, open source whiteboard for architecture diagrams. We use this constantly for planning order routing logic and sync architecture before writing any code.
Warp — terminal replacement. AI autocomplete for shell commands. The difference between Warp and iTerm2 is the difference between Linear and Jira — not more features, just a tool the team actually enjoys using.
Raycast — macOS launcher that replaces Spotlight. Clipboard history, window management, and direct integrations with Linear, GitHub, and Notion. Free tier is comprehensive.
Proxyman — HTTP debugging proxy for macOS. Better interface than Charles Proxy for intercepting and inspecting API traffic. We use this constantly when debugging webhook delivery for our channel integrations. Free tier covers most debugging use cases.
TablePlus — database GUI. Significantly better interface than pgAdmin or Sequel Pro. Free tier is sufficient for most development work.
The underlying principle
Every tool added to a development stack creates:
→ A new place decisions get made
→ A new context to switch into
→ A new integration to maintain
→ A new onboarding task for every new team member
The compounding cost of tool sprawl is real and it grows with team size.
The question worth asking before adding any tool isn't "does this do something useful?" — almost every tool does something useful. The question is "does the value this creates exceed the coordination overhead it introduces?"
javascript// The tool evaluation function we informally apply
function shouldAddTool(tool) {
const teamActuallyUsesItHabitually = assess(tool);
const replacesExistingToolOrWorkflow = tool.replaces !== null;
const coordinationOverhead = tool.integrationsRequired + tool.onboardingCost;
const valueCreated = tool.timeSavedPerWeek * team.size;
return teamActuallyUsesItHabitually
&& (replacesExistingToolOrWorkflow || valueCreated > coordinationOverhead * 10);
}
If the team isn't reaching for it habitually within two weeks — cut it.
The Nventory stack in one view
We're building multichannel inventory infrastructure — event-driven sync across 40+ channels, AI automation, unified order management, and smart order routing. The stack we use to build it:
Linear — engineering tasks
Notion — everything else
GitHub — version control + CI/CD via Actions
VS Code — primary IDE
Warp — terminal
Grafana — monitoring
Sentry — error tracking
Loom — async communication
Figma — design
Claude — writing and reasoning
Copilot — code autocomplete
Perplexity — research
Fourteen tools. Down from twenty-two when we started. Every cut made us faster.
Worth exploring:
→ nventory - full platform, free forever
→ Shopify App Store - apps.shopify.com/nventory
→ AI Automation Suite - build workflows in plain English
→ Order Routing - intelligent fulfilment routing
→ Integrations - 40+ native channel connections
→ App Store + Play Store - search Nventory
The question for the community
What's the one tool you cut that you thought you needed but didn't?
And what's the one that stayed that surprised you with how much it changed how you work?
Drop your stack below — genuinely curious what the dev.to community is actually running versus what they planned to run.
Top comments (0)