Every few months a company publishes its tech stack, and the stack is always a little too clean. Every tool is best-in-class. Every tool is used fully. Nothing is half-abandoned, nothing is kept only because migrating off it would ruin a week, and the monthly total is never mentioned.
This is the other version. A composite of what ten-person product teams we know actually run on in 2026, including the costs, the redundancy, and the tools that survive purely because removing them is more annoying than keeping them. It is less tidy than a company blog. It is also more useful, because the untidy parts are where the real decisions live.
The foundation
Some categories are not arguments. Every team has them, every team buys them, and nobody should spend a meeting on them.
Email and calendars run on Google Workspace at roughly $6 per seat or Microsoft 365 at the same price. Both bundles include Meet or Teams for video, which is fine for most calls. The team still often pays for Zoom separately ($15 per host per month) because Meet is fine and Zoom is reliably good, and reliability matters when the call involves a customer. Payroll runs on Gusto, Rippling, or Deel; expense cards on Brex or Ramp; accounting in Xero or QuickBooks. Combined, those money-layer tools land between $300 and $500 a month for a team this size, scaling with headcount and which tiers you choose. Code lives on GitHub at $4 per developer, or GitLab if the team came up on it and has no reason to move.
Call the foundation layer $250 to $400 a month. It is boring, it is correct, and the only mistake available here is overthinking it. Teams that agonize over this layer are usually avoiding a harder decision somewhere else.
Where the team actually lives
Two or three tools absorb most of the working day, and these are worth real attention, because the team pays for them in hours, not just dollars.
There is a work tracker. For most product teams in 2026 this is Linear at $8 per seat, which has largely won the hearts-and-minds war against Jira ($8 per seat) for teams under fifty people. Jira persists where enterprise customers or existing Atlassian contracts require it, or where a team built its whole process around it and the migration cost is genuinely prohibitive. Asana sits between them: better than Jira for non-engineering workflows, less opinionated than Linear for product development. The pricing is close enough across all three that the choice is almost purely about workflow fit.
There is a chat tool. Slack at $7.25 per seat is the default. Microsoft Teams comes bundled with Microsoft 365, and teams that standardized on that suite often use it instead, though product and engineering teams frequently end up back on Slack anyway because the integrations are better and the developer culture leans that way. Either way, the tool is indispensable, and it is also the main reason focus is hard.
There is a documentation tool. Notion at $8 per seat is where most teams land. Confluence stays alive where Jira is the work tracker and the Atlassian bundle makes sense. Coda works well for teams that want documents and databases tightly combined. Whichever one the team chose, it is the source of truth for roughly sixty percent of what matters. The rest lives in Slack threads and in people’s heads.
That gap, the official knowledge base that is only ever partly true, is universal. No team has solved it. The teams that cope best are the ones that have stopped pretending the doc tool is complete, and instead made it cheap and unembarrassing to ask a person.
There is a quieter cost in this layer too: switching cost paid in muscle memory. A team that moves from Jira to Linear is not just migrating tickets. It is asking ten people to unlearn a set of reflexes built over hundreds of hours. That cost is real, and it is almost never priced into the comparison when a shinier tool appears in a demo. Sometimes the shinier tool is genuinely worth the disruption. Often the honest answer is that the current one is good enough, and the months of friction are not.
Budget the daily-driver layer at $300 to $450 a month. It is the layer most worth getting right and least worth being frugal about. Saving $20 a month here in exchange for a worse daily experience is a bad trade that compounds across every working hour.
The product stack
If the team ships software, there is a cluster of infrastructure that sits beneath the product: hosting, a database, error tracking, analytics, a transactional email service, and usually a feature-flag tool. Costs here are spiky and usage-based, which makes them the part of the stack most likely to deliver an unwelcome surprise on a Tuesday.
Hosting choices in 2026 split roughly three ways. Vercel is the default for frontend-heavy teams, especially those on Next.js. Railway and Fly.io handle backend services and long-running workloads at a lower operational overhead than AWS for small teams. AWS is still where you end up when the product has specific compliance needs, complex infrastructure, or someone on the team who knows it cold. Databases mostly run Postgres, via Supabase or Neon for teams that want managed infrastructure without the setup overhead, or directly on AWS RDS for teams already in that ecosystem.
Error tracking is almost universally Sentry. Analytics splits between PostHog (strong default for product analytics with session replay and feature flags bundled), Plausible (lightweight, privacy-first, better for marketing sites than product internals), and Amplitude (enterprise-tier pricing, better for companies with a dedicated data analyst who will actually use the cohort features). Transactional email runs on Resend, Postmark, or AWS SES. Resend has gained ground quickly among newer teams for its developer-friendly API; Postmark remains the reliable incumbent; SES is cheapest at scale but requires more setup. Feature flags are either LaunchDarkly (expensive, powerful, worth it after Series A) or PostHog’s built-in flags, which are good enough for most teams at a fraction of the cost.
A ten-person team typically lands between $300 and $800 a month on this layer, with the spread depending almost entirely on traffic and how disciplined the team is about turning off what it is not using.
The honest note here is that this is where teams over-provision. The instinct is to buy the plan for the company you hope to be in eighteen months. The discipline is to buy the plan for the company you are this month, and to revisit it when reality actually arrives.
The other trap in this layer is the tool bought during an incident. Something breaks at two in the morning, someone signs up for a monitoring product that would have caught it, and the subscription then outlives the memory of the incident by years. Incident-driven purchases are rarely wrong on the day they are made. They are rarely re-examined afterward, which is exactly how a stack ends up with three overlapping observability tools, each one bought during a different bad night by a different tired person.
The specialized layer
Here is where published stacks get vague and real stacks get specific, because this layer depends entirely on what the company does.
A team doing outbound sales runs a CRM and an outreach tool. HubSpot handles the full CRM-plus-marketing motion but prices up quickly as the contact list grows. Pipedrive is leaner and cheaper for pure sales pipeline work. Attio has gained real traction with early-stage product-led companies that want CRM data modeled around their own objects rather than a vendor’s assumptions. For outreach, Apollo and Lemlist are the common choices, often bought by whoever owns the sequence workflow and rarely reviewed by anyone else.
A support-heavy team runs a help desk. Intercom is the most feature-complete and the most expensive. Pylon is built specifically for B2B customer success and Slack-native support. Plain is newer and developer-friendly, with a clean API model. The right one depends on whether support happens in email, in a shared Slack channel, or in a purpose-built portal.
Teams in genuinely particular lines of work reach past the horizontal products entirely. A creator agency in MENA running its own talent management system, or a chain of dental clinics, will reach for purpose-built vertical tools that handle workflow specifics a general-purpose CRM simply does not model. The pattern holds across industries: vertical software wins wherever the workflow is too specific for a horizontal tool to fake convincingly.
The specialized layer is the one to scrutinize hardest, because it is where redundancy hides. Teams routinely run two tools that overlap by eighty percent, because each was bought by a different person in a different quarter to solve what looked like a different problem. Cost varies too widely to generalize, anywhere from $100 to $600 a month, but the audit is the same everywhere. List this layer, find the overlaps, and cut one tool from each overlapping pair. Almost always possible, almost always uncomfortable, because someone chose each tool and nobody enjoys having their choice retired.
Nobody buys a bad stack on purpose. They buy seven good decisions across two years, and end up with a stack that costs more than any one of those decisions intended.
The tools nobody mentions
Every real stack has a few of these, and leaving them off the published version is the small lie that makes published stacks useless as a reference.
There is at least one paid tool used by exactly one person, kept because that person depends on it and nobody wants to have the conversation. There is a subscription nobody can fully account for. It appears on the Brex or Ramp statement, it is plainly being used by something, and the original buyer has long since left the company. There is the free tier quietly load-bearing a real workflow, one pricing-page change away from a genuinely bad week. The PostHog free tier is a common example: the feature flags are in production, the plan limit is close, and nobody has looked at the billing page in months.
There is the spreadsheet. There is always the spreadsheet, doing a job that three purchased tools were supposed to do, outliving all of them, because it works and everyone already knows how it works.
None of this is a failure. It is just what a stack looks like after two years of reasonable people making reasonable local decisions without anyone holding the global picture. Naming these tools out loud, without blame, is the only way they ever get reviewed at all.
The total, and the real lesson
Add it honestly and a ten-person team in 2026 spends somewhere between $1,200 and $2,500 a month on software. That is $120 to $250 per person. Not alarming. Not nothing. Almost always ten to twenty percent larger than anyone on the team would have guessed before adding it up.
That gap between the guess and the number is the actual lesson. No team sets out to buy a bloated stack. It buys seven sensible tools over two years, each justified on the day it was bought, and the bloat is simply the sum: a thing no single decision is responsible for, and therefore a thing no single decision ever fixes.
The teams that keep their stacks lean do one unglamorous thing. Once or twice a year they put the whole list on a single page, with the real monthly cost beside each line, and they make someone defend every entry out loud. Tools that cannot survive that sentence get cancelled. It takes an afternoon. It is the highest-return afternoon on the operations calendar, and it is the one most teams never schedule, because nothing is on fire and the savings belong to no one in particular.
