I built a free API that measures the cost of software complexity
I've spent the last few months writing about the economics of software engineering. One thing I kept coming back to is that most companies have no idea what their complexity actually costs them. They track headcount, infrastructure, tooling, but not the tax that interdependence and coordination overhead impose on every feature they build.
The Sync Tax is that invisible multiplier. When teams have to coordinate because their code depends on each other, when a change in one component breaks another, when meetings replace building. All of that has a cost.
I built a small API that quantifies it. You feed it a few metrics about your team and codebase, it returns a multiplier and a dollar figure. Free tier, no credit card.
There's also an MCP server if you want agents to query it directly.
This is a really clever way to make an invisible cost visible.For anyone who hasn't clicked through — the API returns a Sync Tax Score (a multiplier like 2.7x) and a dollar figure based on team size and codebase coupling. The example on the site shows 2.7x multiplier, 68 hours waste per feature, $408k annual cost.A few observations from someone who has thought about this:
The multiplier concept is powerful for budgeting. If a feature would take 100 hours in a "zero-sync" world, a 2.7x multiplier means you budget 270 hours. That alone would change how roadmaps are built.
The free tier is generous for early-stage teams.The pricing page shows a free plan ($0) and a paid plan ($29). The free tier is smart — teams can test their own data before committing.
The MCP server for AI agents is the interesting part.Most calculators stop at giving you a number. Letting Claude or Cursor query the multiplier directly means agents could adjust their recommendations based on your team's actual friction. That feels like where this is headed.
But i wanted to ask how did you derive the multiplier formula? Is it based on team size plus code coupling metrics or does it also factor in things like PR review time or deployment frequency? The website mentions 'theories from The Engineering Tax' — curious how much is academic versus empirical.
This solves a real problem though. Most engineering leaders know complexity costs them, but they can't measure it. Now they can.
Interesting angle because complexity has a cost twin on the infra side that nobody really measures either. A single over-engineered service usually drags along 3-4 idle databases, an orphaned cache layer, and a multi-AZ setup no one actually needs. Does your model account for runtime cost at all, or purely code complexity? It would be wild to combine the two views of the same team, two angles on the same waste.
I'm not talking about code complexity here, I'm talking about all aspects of complexity, obviously including infra. And another expensive and underestimated component of complexity is coordination meetings. Do you spend half of the day in meetings almost every day? That costs a lot. I intend to find a way to calculate all those components so business owners can make truly informed architectural and product decisions.
The 'based on what model' question is the right one. Precise dollar figures from opaque inputs lose credibility fast with technical audiences. The framing that tends to land better is a range with visible assumptions — not $400K/year but 'our model suggests 15-25% of sprint velocity is absorbed by coordination overhead, here's what drives that.' That gives engineers something to dispute or validate, which is more useful than a black-box number they'll dismiss.
That’s a strong developer tool idea — especially if it translates “technical complexity” into something business teams understand: cost, risk, and maintenance impact.
"Companies track headcount, infrastructure, tooling, but not the tax that complexity costs them" — this is such an underappreciated problem.
Most engineering orgs feel it but can't quantify it. Making it measurable changes the conversation from "this feels slow" to "here's what slow is costing us." That's a much stronger basis for prioritization.
Interesting tool. What's your approach for making the output actionable for non-technical stakeholders?
I want to provide numbers CEOs will understand.
Let's say a CEO brings a project to increase revenue in $2M/year and asks the CTO to develop feature X in the next 2 weeks. The CTO evaluates the situation and knows that he needs to remove tech debt to make that project less risky, the CEO pushes back, focused on the upcoming 2M. The CTO is unable to assess the CEO because he also doesn't know that not removing tech debt will increase the cost of development 200% and the cost of maintenance in $3M/year, so they would lose money. Wouldn't that help the CEO make a truly informed decision?
The "sync tax" concept is genuinely interesting — coordination overhead as an invisible multiplier is real and under-measured. But two things worth pushing on.
The dollar figure is the trust-killer, not the selling point. Any precise cost ("your complexity costs $400K/year") derived from a few inputs is necessarily a formula you chose. The exact technical audience that would care about this will immediately ask "based on what model" — and "a few metrics through my multiplier" makes the precise number read as false precision. Ranges or relative scores survive scrutiny better than dollar figures that imply accuracy you can't have.
Bigger thing: who's the buyer and what do they do with the number? An eng manager gets "$400K sync tax" — then what? The number doesn't say which dependencies to cut or which teams to restructure. A diagnostic that produces a scary number but no next action is interesting-once, not sticky. The value isn't measuring the tax — it's prescribing which specific complexity to remove. You built the measurement; the prescription is where the actual product is.
The MCP server angle feels like solution looking for problem — worth asking what agent actually needs to query complexity cost, versus building it because MCP is available.
This is a strong idea because “complexity” is usually treated like engineering intuition, not something the business can see in dollars.
The sharper positioning might be that you are not just calculating code complexity. You are translating engineering drag into a financial number leadership can actually understand: coordination cost, dependency risk, slower feature velocity, and the hidden tax of teams stepping on each other.
I’d be careful with the naming frame before this becomes more than a calculator. “Complexity Cost Calculator” explains the first tool, but the bigger product could become an engineering economics layer for teams and agents: measure software drag, expose where coordination is expensive, and let MCP-connected workflows reason about it.
Davoq .com would fit that direction better if you want it to feel like serious engineering infrastructure rather than a one-off calculator. The product can stay simple, but the brand should leave room for APIs, MCP, dashboards, and team-level complexity intelligence.
The idea is strong enough that the name should not make it feel smaller than the problem.