The coordination tax: six years watching a one-day feature take four months
There's a number you see quoted sometimes in management books, and most engineers I know dismiss it the first time they read it: in a team of eight, there are 28 possible communication paths. In a team of sixteen, 120. The formula is n(n-1)/2 and it's just geometry, but geometry is the thing that runs your day. Every one of those paths, on an active project, is a message you triage, a Slack reply you owe, a meeting that could have been async but isn't. The paths don't cost much individually. They compound ruthlessly.
I spent six years as an engineer inside product industry. Good companies. Real products. Smart people. Somewhere in year three I started keeping an informal tally: how long did each feature actually take, and how much of that time was I writing code? The ratio got worse every year. By the end, for a typical ticket, my time with a compiler open was maybe fifteen percent of the calendar span. The rest was alignment. Meetings about the meeting. Review cycles where the reviewer was waiting on a decision from someone who was waiting on a decision from someone else.
The numbers are public if you care to look. U.S. workers average 35 hours of meetings per month. The load of unproductive meetings on individual contributors has roughly doubled since 2019, from 1.7 hours a week to 3.7. Seventy percent of managers describe their meetings as costly and unproductive, and they are the ones calling them. DORA's 2025 State of AI-assisted Software Development report is polite about it but the subtext is clear: AI is making the coding step faster, and organizations without healthy value streams are mostly not seeing that speed reach production. The bottleneck was never typing.
I want to be specific, because abstractions let everyone off the hook. A scene I'll carry for a while: on one project we had forty microservices and eight engineers. Deploys took three of us half a day. We had optimized for a scale we didn't have, and we paid for it every Tuesday. Nobody had designed the dysfunction. It had accreted. Someone good had made a reasonable call in 2019 about future-proofing, someone else had reasonably extended it, and two years later we were a small team pretending to be a large one, carrying the operational overhead of a company ten times our size. There was no villain. That was the unnerving part.
Here is the thesis I landed on, and the one I'd like people to push back on:
Coordination is not a management problem. It is a physics problem, and it has a price curve that organizations systematically underestimate.
A team of four adds a fifth person and gets roughly 25% more output. They also get 40% more communication paths. By eight people the paths are growing faster than the headcount, and by sixteen the second derivative has taken over. You can flatten this curve with good tools, clear owners, tight docs. You cannot eliminate it. Past a certain size the paths dominate, and the marginal engineer produces less than the coordination cost of adding them. Every experienced manager knows this. Almost no org is structured around it.
What finally tipped me was an accounting exercise. In one column I listed what I could build in a weekend if I owned the full stack and made every call myself. In the other, what the same feature would cost to ship at work, measured in calendar time from idea to production. The ratio was never less than 20x. Often 60x. Not because my coworkers were slow. They were excellent. It was because the system they were operating inside exacts a tax that scales with its size, and no individual inside it can opt out.
I left in early 2026 and shipped Flowly in thirty days.
I am not going to pretend AI was the hero of that story, even though it helped. The hero was the absence of the coordination tax. One mental model. No alignment meetings. When I decided on a data shape at 10 a.m. I could ship it by lunch, because the only person who needed to sign off was me. A one-month bet replaced a six-month one not because I typed faster but because the overhead went to zero. Pieter Levels is at roughly $3M a year with zero employees, and Photo AI alone was clearing about $138K a month last quarter. He is an outlier in magnitude, not in kind. The infrastructure for small, opinionated, one-brain products has quietly become unreasonably good.
Flowly is my negative-space answer to the years I spent inside the tax. One workspace for tasks, timers, and analytics, aimed at freelancers and small teams who run four apps to answer one question: where did my week go? I built it for the version of me who, three years ago, would have spent a Friday afternoon reconciling Toggl against Todoist against a spreadsheet, and would have gotten the number slightly wrong anyway.
If you've made this jump from a team to solo, I'd like to hear the actual delta in concrete terms. Not "it feels faster" but: what's your time from idea to production now compared to before? How many meetings did you attend in your last week at a company versus now? The coordination tax is something most people feel in their bones but rarely put a number on. If you have the number, I'd like to hear it.
https://flowly.run. 14-day Pro trial, no card required.
I've seen this pattern up close. I built CodeTeleport — an MCP server, CLI tool, dashboard, billing, and launch — and shipped it in 7 days. Every decision happened in minutes because one person understood the problem, the architecture, and the code.
The moment you add layers between the person who understands the problem and the person writing the code, everything slows down. Not because people are lazy, but because translation is lossy. Every handoff drops context.
The best setups I've worked in had one technical person who owned the decision and the execution. It doesn't scale forever, but in the early stages, it's the fastest way to ship.
Seven days for all of that is the proof of concept in one data point. And the "translation is lossy" framing is exactly what the coordination tax actually is under the hood — not the meetings themselves but the information that degrades at every handoff. By the time a user insight becomes a ticket becomes a spec becomes a PR, you're building a photocopy of a photocopy of the original problem.
The one-person-owns-problem-and-execution setup doesn't scale forever, but I'd argue it scales further than most teams allow it to. The pressure to add people comes early, often before the decision surface actually requires it. Sometimes the right move is to stay in that mode longer than feels comfortable, because the moment you split problem ownership from execution ownership you've introduced a translation layer that never fully closes.
Really strong framing. The line about geometry running your day is memorable, and the post captures a pain almost every team feels but rarely names clearly. I also like that you didn’t just complain about meetings—you tied the problem back to communication paths and compounding coordination overhead. Curious whether you’ve seen any teams actually reduce this tax in a durable way, or if it always comes back once headcount grows.
The durable reductions I've seen share one thing: they treated coordination structure as a product decision, not an HR one. Meaning someone actually designed it — clear ownership boundaries, explicit interfaces between teams, a default of async — and then defended it under the pressure to add process when things got complicated. The ones that didn't make it treated structure as something that would sort itself out, and it sorted itself into the same meetings everyone else has.
The honest answer is it always comes back past a certain size. The curve is physics. But there's a meaningful difference between a team that hits 40 people and has 150 paths because they designed for it, versus one that hits 15 and already has 150 paths because nobody drew the lines early. The tax is inevitable. The rate at which it compounds isn't.
A lot of early GTM pain comes from chasing volume before you understand signal.
It is easy to think the answer is more posts, more outreach, or more channels. Usually the bigger unlock is getting better at spotting who actually has the problem right now and what made them pay attention in the first place.
That tends to clean up a lot of the confusion.
The "right now" qualifier is the part that usually gets skipped. Most targeting is demographic — freelancers, small teams, productivity-focused — but the people who convert are the ones who are actively feeling the problem today, not the ones who fit a profile. Same person, different moment, completely different outcome.
What made them pay attention is the harder question and the more valuable one. If you can identify the trigger — the frustration that made someone searchable — you know where to be, not just who to find.
The ratio of writing code to everything-else is the thing nobody puts in the job description. When I was in a team of twelve, I tracked a three-week sprint once and found I was writing code about 11 hours of it. Everything else was prep, handoff, context-giving, or unblocking someone. The coordination cost wasn't even hostile. People were collaborative and smart. The paths just multiply. Going solo or small team is a direct response to this. The overhead doesn't compress, it disappears.
Eleven hours in three weeks is the number that should be on the job description. Not as an indictment — exactly as you said, collaborative, smart people — just the honest accounting of what the structure costs before anyone writes a line.
The "overhead disappears" experience is real for the first few months. Then you realize some of it was load-bearing. The second opinion you never had to ask for. The person who caught the thing you were too close to see. Solo you move faster and occasionally you ship the wrong thing with full confidence. Different tradeoff, still a tradeoff.
The "there was no villain" observation is the load-bearing part of the post, and it's the same mechanism as personal habit accretion at the individual scale. Every morning you pick up your phone first thing for a legitimate-feeling reason: check the weather, confirm no emergency overnight, whatever. None of those days was the problem. The aggregate is the problem. Each decision was defensible in isolation, and none of them could have been defended looking forward seven years.
Organizations don't accrete dysfunction on purpose, and neither do people. What's unnerving isn't that a villain was hiding somewhere. It's that the reasonable-sounding decision is the unit of accretion, which means the only way out is to stop judging individual decisions by whether they seem reasonable in the moment and start asking whether the aggregate matches what anyone would have chosen on purpose.
The forty microservices didn't all arrive on one day. They arrived one reasonable morning at a time. That's the framing I'd carry into the next team.
The habit accretion parallel is the right one and I hadn't made that connection explicitly. The phone-first-thing pattern is identical in structure — each instance has a defense, the aggregate has none, and the defense for each instance is exactly what makes the aggregate invisible until it isn't.
The "would anyone have chosen this on purpose" test is a cleaner diagnostic than trying to audit individual decisions, which will all pass. You're not looking for the bad call. You're looking at the shape of what accumulated and asking whether it matches any intention anyone ever had. Usually it doesn't. Usually nobody would have signed off on the destination if they'd seen it on day one.
The forty microservices on one slide in a planning meeting would have been laughed out of the room. They arrived because no single morning was the morning to say stop.
I can relate so much. I've been Head of Product at an EdTech company for more than 6 years now, and the ratio you describe (15% coding, 85% alignment) is realy accurate on my side too.
We recently designed a multi-step funnel for 14 landing pages. The actual build was maybe 2 sprints of dev work. The alignment across product, dev, QA, and PPC on what the flow should even look like? I don't even want to count;))
What pushed me to start building my own SaaS on evenings and weekends was exactly this realization. I shipped a working waitlist tool with referral tracking in a few days solo. At work, scoping the Jira stories alone for something comparable would've taken weeks.
The coordination tax is real and it compounds with every stakeholder you add (now having lean company structure it's a bit easier but still).
I'm curious about your analytics piece in Flowly. Do you track time per project/client or is it more about personal productivity patterns?
The 14 landing pages story is the coordination tax in its purest form — two sprints of actual work sitting inside months of alignment. The build was never the bottleneck.
The solo waitlist tool in a few days is exactly the delta. Same person, same skills, different structure. That gap is the whole argument.
On analytics — both, but they're connected. You can see time by project and by task, with date range filters, so if you're billing by client or just trying to understand where a week actually went across multiple workstreams it's all there. The pattern view is what most people find surprising — you think you know where your time goes until the data tells you otherwise. For someone juggling a day job and an evening SaaS build that visibility is probably the most useful thing in the product.
This is one of the most underappreciated dynamics in startups. I've been looking at engineering data across a bunch of startup orgs, and there's a visible pattern: commit velocity per contributor actually decreases as team size grows past 8-10 engineers. The total output goes up, but the output per person drops.
The interesting part is the exceptions. The teams that maintain high per-capita velocity tend to have one thing in common: very few repos relative to their team size. They resist the urge to split everything into microservices early. Monorepo or a small number of repos = fewer coordination boundaries = less tax.
The scariest version of this is when a startup's contributor count doubles (they just hired a batch) but their commit velocity stays flat for 2-3 months. That's the coordination tax eating the entire output of the new hires.
Curious if you've seen the repo architecture angle play out in the teams you've observed - was there a difference between the ones who centralized vs distributed their codebase?
The repo count as a coordination boundary proxy is a sharp observation — and yes, it tracks. The teams I saw maintain velocity longest were the ones who treated splitting as a cost to be justified, not a default to reach for. The microservices enthusiasm usually arrived before the scale that would have warranted it, and the overhead arrived immediately.
The two to three month flat velocity after a hiring batch is the coordination tax made visible in the data. New hires aren't unproductive — they're spending their output on onboarding into the coordination layer itself. Learning the paths before they can use them. That cost is real and almost never shows up in hiring plans.
The scariest version I saw wasn't flat velocity — it was a team that interpreted the flatness as a skills problem and hired more people to fix it. The tax compounded and the diagnosis never landed.
This line stood out: “the bottleneck was never typing.”
Feels like AI is exposing org inefficiencies more than fixing them. Faster code just makes coordination gaps more obvious.
The hidden tax is not only path count.
It’s how many times the same piece of work has to be reinterpreted before it can close.
A one-day feature becomes a four-month feature when every interface reopens the question of meaning — scope, risk, ownership, definition of done.
That’s when coordination stops being overhead and becomes semantic drag on the product itself.
What’s interesting is AI is making this gap more visible. If coding gets 2–3x faster but coordination doesn’t change, then org inefficiency becomes the real bottleneck
Yep, maybe this is the reason why orgs will loose to indie hackers ;)
What’s interesting is AI is amplifying this gap even more. If coding gets 2–3x faster but coordination stays the same, the bottleneck becomes even more obvious.
Exactly and even worse. Because of mad about AI CEOs and dummies with AI it gets a lot worse.
The approval layer is where most of the coordination tax accumulates in client work too. Not in the doing — in the confirming.
I've watched a two-hour design job stretch to two weeks because approval happened verbally on a call, then got re-interpreted, then disputed. The work itself wasn't the bottleneck. The lack of a shared, timestamped record of what was signed off at each step was.
Your internal coordination problem and the client-services version of it have the same root: decisions compound faster than records of them do. Eventually the gap between "what we agreed to" and "what we can prove we agreed to" becomes its own project.
Yes, it's also what I meant. I am aware that somewhere at the top approval pinpong is also played. But single person can be also indecisive so I consider that it's not the root cause.
"Coordination is not a management problem. It is a physics problem" — this framing landed hard.
The 40-microservices / 8-engineers scene perfectly illustrates how dysfunction accretes with no villain. Each individual decision was reasonable; the compound is brutal.
There is an external version of this same tax that freelancers and small agencies pay but rarely measure: client coordination overhead. Every revision cycle that starts with "I never approved that" is a coordination failure with the same structural cause as your Slack-owed replies and meetings-about-meetings. The approval happened in a DM, on an unrecorded call, buried in an email thread. No shared source of truth.
I have been building something to address that specific slice (proofsent.com, timestamped approval records so the "did you approve this?" question has a permanent answer). Different scale from the n(n-1)/2 problem you describe, but the failure mode is identical: absence of a single coordination truth.
The DORA point about AI accelerating coding while the value stream stays slow is the one I keep quoting. The bottleneck migrates upstream the moment you solve what you were previously optimizing.
This is a great extension of the idea.
What you’re describing is the same failure mode, just externalized: not too much communication, but no shared source of truth. Once “what was approved” diverges, you stop building and start reconciling.
That’s why your approach is interesting — it’s less about tracking messages, more about locking decisions in time.
And yeah, AI is making this more obvious. Faster coding just exposes how slow (or fuzzy) the decision layer really is.
Curious — are people adopting it before things break, or only after a dispute?
This really resonates — especially the idea of coordination being a “physics problem.”
I’ve felt something similar even in smaller setups, where most of the delay isn’t building but aligning decisions.
Curious, do you think there’s a middle ground where small teams can keep speed without fully going solo?
I’m currently building something in the freelancer space and noticing how much faster iteration becomes when there’s less coordination overhead.
I think that balance can be found and even large teams can keep decent if orginized smart.
This is one of my pet peeves in larger companies, so not fully Indie Hackers discussion, but I think it could still matter once we all have grown into large enterprises! Centralized ownership of everything is a recipe for immense slow-down. The solo-do-it-all does not scale, but there is something that does. People owning their own part of the work or product. That is scalable.
Everybody needs to and must be able to to own part of the product or project or "work" in full without having to commune with the N bosses on a daily basis. If there's a culture and system of "must ask manager for any decision that could cost more than $10 to the company and discuss it with 3 teams before implementing" any progress will sit dead in the water.
It goes two ways of course. With freedom comes the responsibility of not affecting other people's work negatively and actually doing something. That's why clear ownership and setup to support it (technically, organizationally, culturally, and so on *lly) is needed in these situations, but it's not just the managers who should own large swathes of the work and project. Without distributed ownership the coordination tax is always there and it kills any productivity the more things get locked down in approval processes and meetings.
Can everybody own something in full? Almost certainly not, but who can/cannot do something and whether they can learn to, is something that needs to be figured out on the go. In my experience most people tend to be far more capable and clever when given the incentives and freedom than it might seem in a micromanaged environment.
Distributed ownership is the right frame — and it scales in a way that headcount reduction doesn't. The coordination tax isn't really about team size, it's about how many approval layers sit between a decision and the person who has to live with the outcome. Compress that and the paths stop mattering as much.
The micromanagement point cuts deep. People perform to the surface they're given. Give someone a narrow corridor and they'll navigate it narrowly, which looks like confirmation that they needed the corridor in the first place. It's a self-sealing system.
The hard part is that clear ownership requires someone to actually draw the lines — which domains are yours, where they end, what the interface looks like. That work is unglamorous and easy to skip, so most orgs default to shared ownership of everything, which is functionally ownership of nothing.
I’ve been thinking about this from a branding angle.
There’s still no simple global phrase for female identity.
I’ve been exploring this idea with a domain
Do you think naming alone can shape a brand at scale?
Naming creates the container but doesn't fill it. Google meant nothing before it meant everything.
What's the domain?
This resonates a lot. I’ve seen similar 10x+ speedups going solo — mostly from eliminating decision bottlenecks, not coding speed.
Curious how you’re measuring Flowly’s actual usage retention so far?
Mostly through activation depth rather than raw retention — whether users hit three or more distinct features in the first week, and whether they connect calendar sync, which turned out to be the strongest predictor of staying. Someone who only creates tasks churns. Someone who starts a timer, connects their calendar, and checks analytics at the end of the week almost doesn't.
Early days still, so the sample is small enough that I'd call it directional rather than conclusive.
Yea, and don't forget to question whether said feature that took so much time to develop was even worth developing. the only way to figure out whether a feature is worth developing is to make a minimum viable product out of it, test it on real users to validate its usage, and then iterate on it. Great article!
Exactly — the coordination tax compounds hardest on the wrong features. A six-month shipping cycle doesn't just slow you down, it means you find out the feature was wrong six months too late. Solo the feedback loop is short enough that you can kill something after a week. In a team that decision has to travel the same paths as everything else.
This is a sharp articulation of something most engineers intuit but rarely quantify: coordination isn’t just overhead, it’s a scaling function that quietly eats execution capacity as teams grow.
What resonates most is the “physics” framing. Even when every individual is high-performing, the system-level friction compounds—more paths, more dependencies, more waiting.
The 20x–60x delta between solo shipping and org shipping is especially striking, because it reframes “productivity” as less about coding speed and more about decision latency and ownership clarity.
AI may compress implementation time, but without structural changes in how decisions flow, the bottleneck just shifts rather than disappears.
At the same time, I’d be curious where you think the boundary is for this model.
There are classes of problems where coordination cost is not just overhead but a feature (security, large-scale reliability, regulated environments).
The interesting tension might be less “solo vs team” and more “how small can the decision surface stay while still benefiting from multiple minds.
The last question is the right one, and I don't think the answer is a headcount. It's about how many people need to hold the same context simultaneously for a decision to close. Keep that number at one for as long as possible — not by excluding people but by making ownership unambiguous enough that most decisions never need to become conversations.
The coordination-as-feature point is real and worth separating out. Security, reliability, regulated systems — there the second set of eyes isn't friction, it's the actual work. The review cycle exists because catching the thing matters more than shipping fast. That's a different physics problem, not a counterexample to this one.
Where I think the model breaks is less about domain and more about surface area. The moment the decision surface grows faster than one person's judgment can cover it, you need more minds — but the goal should be expanding coverage without expanding the coordination layer that connects them. Two people with clean, non-overlapping ownership and a clear interface between them scale better than four people who share everything. The paths matter less than how often they have to activate.
This hit a little too close, to be honest. ~
I never thought of it as 'coordination tax', but that's exactly how it felt.
It's not about slowness - it's just everything starting to depend on everything else, one decision leads to 3 meetings, which leads to waiting, which leads to explaining context to a new person.
The feature weight vs hardness part. That's so real.
Also like how you described it like a physics problem instead of a management one.
Most teams solve this by adding process to remove drag, which usually just adds more weight to the system instead of removing it.
I'm actually curious though - when you went on your own, what actually changed on a day-to-day basis? Was it just fewer things to coordinate or did you cut scope way more aggressively than you could on a team?
Either way, this explains a ton about why small teams could ship circles around big teams. It wasn't talent, it was drag.
Both, but they're connected. Fewer things to coordinate meant I could finally see which scope actually mattered. On a team, cutting scope requires consensus, which costs the same meetings as building the wrong thing — so you build it anyway. Alone, cutting a feature costs nothing. You just don't open the file.
The day-to-day shift was less dramatic than I expected. Same hours, same problems. Just no queue. A thought at 9am becomes a decision becomes code becomes shipped, same day. That chain used to have four places it could stall waiting for someone else's attention. Now it has zero.
"It wasn't talent, it was drag" is exactly it. I worked with genuinely excellent people who were spending the best hours of their day on context transfer instead of building. That's not a people failure. That's what the structure costs.
I felt this hard when moving from a team to solo.
What changed wasn’t just speed — it was decision latency.
At my old job, even small decisions had to “wait their turn”.
Now I can make 10 decisions in the time it used to take to align on one.
That difference compounds way more than people expect.
Decision latency is the right name for it — and it's the part that doesn't show up in any productivity metric until you're on the other side of it. You don't notice how much of your day was queuing, not working.
The compounding is what surprises people. Ten fast decisions don't just produce ten outcomes — they produce information that changes what the eleventh decision even is. You're iterating on a loop that used to move in weeks and now moves in hours. After a few months the gap between what you shipped and what you'd have shipped inside a team isn't linear. It's a different product.
the coordination tax is real and it compounds fast. what kills me is that it's not just internal coordination, it's also the hidden cost of communication outside the team. we ran into this with service businesses where clients text the founder directly, and suddenly all that context lives in one person's phone and nobody else can act on it. no visibility, no delegation, just a bottleneck that grows every time you get a new client.
That's the one that's hardest to see coming — internal coordination at least happens inside systems you control. Client context living on a founder's phone is a single point of failure that scales inversely with success. Every new client makes it worse, not better. Growth tightens the bottleneck instead of relieving it.
And it's invisible until someone's unavailable for a day and the whole operation finds out simultaneously how much was stored in one person's head.
the agent version is what keeps me up. you spin up 8 specialized agents thinking you cut the overhead - but now the paths multiply again, just in background jobs nobody watches until they conflict.
Yeah you see quite a lot of people evangelising running a fleet of agents, but honestly, my own brain capacity caps at 2, maaaaybe 3 on a good day. And then I have them working on completely separate things so that they don't interfere with others. I don't use worktrees, I just try to organise the work so that they don't need to communicate with each other.
This hits hard. Most teams don’t realize how much hidden coordination cost slows them down until it’s too late. Curious — did you find any specific patterns where this delay gets worst?
The worst version I saw was decision debt — when nobody owns a call, so it gets discussed in every meeting but resolved in none. The path count doesn't matter as much as how many paths a single unresolved question has to travel before it closes. One ambiguous requirement can touch every person on the team, repeatedly, until someone finally makes the call that could have happened on day one.
Second pattern: review chains where each reviewer is waiting on someone upstream. The work is done. It's just sitting. That's the coordination tax in its purest form — zero value being added, clock running anyway.
managed a team of 18. the 153 paths never look like 153 - they look like one 45-min standup nobody will kill. running AI agents gave me the same math again. the bottleneck moves. never disappears.
The standup nobody will kill is the perfect image for this — 153 paths compressed into one recurring calendar event that feels harmless because it only costs 45 minutes. Except it costs 45 minutes times 18 people, which is a full workday, every day, that the org has decided is just the price of existing.
The agent version of this is something I keep thinking about. The paths don't disappear, they just route through a different node. You're still the one resolving conflicts, setting context, catching the cases the agent couldn't handle. The bottleneck moved to you — quieter, but the same geometry.
this framing really hits home. we experienced this building Coop. as a tiny team the coordination overhead was close to zero and we could ship fast. but watching our early customers who are small service teams of 3 to 5 people try to manage client texting without proper tooling was like watching the coordination tax hit in real time. every message going to someone's personal phone meant everyone else was flying blind. the math you lay out here is exactly why keeping teams small and async first matters so much.
The Coop example is a perfect instance of it — the coordination tax showing up not inside the team but in the product gap itself. When client messages live on someone's personal phone, you've accidentally distributed the context across devices nobody else can see. The team is small, the overhead should be low, but the information architecture recreates the dysfunction anyway.
Async-first is the right instinct. The tax isn't really about meetings or headcount — it's about how many people need to hold the same context simultaneously to get anything done. Keep that number low and the curve stays flat longer than the formula suggests.
The “physics, not management” framing is hard to ignore. What stood out reading this is how the system grows into the problem. No single decision is wrong, but the combination creates something no one would design intentionally.
The 20x–60x gap is brutal, but also explains why solo feels so different. Not just speed but fewer points where things can stall.
The tricky part is once you add even a couple more people, that overhead creeps back in fast.
The "no villain" part is what stays with me. That microservices scene — forty services, eight engineers, half a day to deploy — nobody signed off on that outcome. It assembled itself from reasonable decisions made by people who were trying to do the right thing. That's harder to fix than negligence. You can't point at it.
The two-person jump is where I get stuck thinking about the future. One person has one mental model, one set of priorities, zero syncing cost. Two people have a relationship, which means context you have to maintain, decisions you have to explain, a person whose time you now partly own and who partly owns yours. That's not a complaint about people — it's just that the first coordination path is the most expensive one, because it creates the template for all the ones that follow. Going from one to two might actually be the hardest transition on the curve.
That “no villain” point is what makes it hard to deal with. If something’s clearly broken you fix it, but when it’s the result of lots of reasonable decisions, it’s much harder to even recognise as a problem.
The one-to-two jump is interesting as well. Feels small on paper, but that’s where the system changes completely.
Your formula about coordination paths holds in hardware too — and if anything, it's worse there.
I spent years coordinating with site teams, vendors, and permitting bodies.
The communication paths followed the same geometry, but with physical latency baked in: site visits, permit cycles, fabrication lead times.
One wrong call didn’t cost a week of meetings. It cost three months and a blown budget.
I’m now building an app solo, vibe-coding with AI assistance.
The external coordination tax dropped to near zero.
But it came with a different constraint: every decision — architecture, UX, copy, pricing — hits the same desk at the same time.
The overhead didn’t disappear. It compressed.
Your bottleneck was paths between people. Mine is the cognitive bandwidth of one person.
Both are physics problems.
I’ll take the second one — wrong calls usually cost an afternoon, not a quarter.
The hardware version is the one I hadn't considered, and it reframes something. You're describing a system where the feedback loop has fabrication lead times baked into it — a wrong call doesn't announce itself for months, and by then you've already built on top of it. At least in software, a bad architecture decision usually bites you before it costs a quarter.
The "overhead compressed, not eliminated" framing is exactly right, and it's something I underestimated. I kept thinking of zero meetings as zero overhead. It isn't. Every decision still has a cost — it just queues behind the same single processor now. The bottleneck moved. It didn't disappear.
What I didn't anticipate is that the single-desk problem has a failure mode that's harder to catch than coordination overhead. Bad coordination is visible — you can count the cycles, watch the delays accumulate. Cognitive compression fails quietly. Two weeks in you realize you shipped something nobody wanted, and there was never a second person in the room to ask the obvious question.
But I'll take that too. At least it fails fast.
Cognitive compression fails quietly" is the part that landed hardest.
In hardware, failure announces itself loudly and late. By the time you know something went wrong, you've already paid for it twice.
The quiet version is new to me. Still learning to hear it.
Most people blame execution speed, but this makes it obvious, the real bottleneck was always coordination.
Remove that, and suddenly “fast builders” aren’t special, they’re just operating without the tax.
Totally agree! The overhead is tremendous.
The n(n-1)/2 framing is the clearest way I've ever seen this explained. I spent 4 years at a mid-size fintech and kept a similar tally — my actual coding time was around 12% of the calendar span on most tickets. The rest was waiting. Waiting for the design review, waiting for the security sign-off, waiting for the PM to confirm the edge case nobody had thought about until the PR was already written. The dysfunction wasn't anyone's fault and nobody could fix it because fixing it would have required someone to own all the paths, and no single person did. Bookmarked this.
Checking out Flowly now.
12% is about what I saw too, and your framing of 'nobody could fix it because fixing it would require owning all the paths' is more precise than anything I wrote — that's exactly the structural trap. The tax isn't a symptom of bad management. It's a natural consequence of the geometry, and you can't manage your way out of physics. Curious what your setup looks like now if you've made the jump — and if you do try Flowly, I'm easy to reach. Happy to hear what's missing.
Pretty insightful. Thank you for your opinion!
Did you spend time inside a larger org before going solo (or staying solo)? I'm still trying to build out a real dataset on the idea-to-production delta. Most people tell me it "feels" 10x faster, but the ones who've actually clocked it are harder to find. Curious if you have a number.
Appreciate it — glad it resonated.
Max, you've hit the nerve, in a good way. This 'coordination tax' is precisely why I built "The Silent Empire ND". For neurodivergent founders, this tax isn't just time—it’s physical and mental exhaustion. We use 'The Silent Drive ND ' to automate the executive function loops that create this drag. High-status work shouldn’t feel like wading through mud.
The neurodivergent angle reframes the whole thing. For most people the coordination tax is an efficiency problem. For ND founders it's an energy problem, which is a different order of magnitude — you're not losing hours, you're losing the capacity to function for the rest of the day. The mud metaphor is exact.
Automating the executive function loops is the right attack surface. The drag isn't the meetings themselves, it's the cognitive overhead of tracking all the open loops, remembering what needs to happen next, holding context across interruptions. That's where the real cost lives for a lot of people.
Would love to understand more about how Silent Drive ND approaches it.
We are looking for someone who can lend our holding company 200,000 US dollars.
We are looking for an investor who can lend our holding company 200,000 US dollars.
We are looking for an investor who can invest 200,000 US dollars in our holding company.
With the 200,000 US dollars you will lend to our holding company, our finance team will invest the money in the stock market and some business sectors, thus making a significant profit for both of us.
With your 200,000 US dollars investment in our holding company, our finance team will invest it in the stock market and 4 different business sectors, significantly increasing our profits within a few months.
Your 200,000 US dollars investment in our holding company will be invested by our finance team in the stock market and several business sectors.
The 200,000 US dollars you will invest in our holding company will be used by our finance team in the stock market and in 4 different business areas.
Which business sectors will be invested in?
Money will be increased by investing in major sectors such as cybersecurity, software, furniture, and e-commerce.
With the 200,000 US dollars you have invested in our holding company, we will invest in major sectors such as cybersecurity, software, furniture, and e-commerce.
With the $200,000 USD budget you've invested in our holding company, we will significantly increase our profits within just a few months by investing in high-market sectors such as cybersecurity, software, furniture, and e-commerce.
If we use the 200,000 US dollars you invested in our holding company across four different business sectors, our earnings will increase rapidly.
By dividing the 200,000 US dollars into different business areas, we will reduce the loss rate to zero.
By investing the 200,000 US dollars you lent to our holding company in the stock market and four different business areas, we will rapidly increase the rate of return on investment.
We will use the 200,000 US dollars you lent to our holding company to rapidly increase our profits by investing in sectors such as stock market and cybersecurity, software, furniture, and e-commerce.
Our finance team will use the 200,000 US dollars you lent to our holding company to invest in the stock market and in high-market sectors such as cybersecurity, software, furniture, and e-commerce.
By using 200,000 US dollars in 4 different business sectors, we will generate a significant amount of income within a few months.
So how will we market the products we produce?
Thanks to our strong advertising network, we will be able to sell the products we produce quickly.
Thanks to our strong advertising network, we will quickly find customers for the products and projects we will produce.
Thanks to our strong advertising network, we will attract a large audience to our projects, which means we will quickly generate significant revenue.
By using WhatsApp groups, Twitter, Instagram, Facebook groups, TikTok, Telegram groups, LinkedIn, and many other high-traffic social media platforms for advertising, we will be able to conduct large-scale advertising.
By using various advertising tactics such as Facebook ads, YouTube ads, Google ads, and email advertising, we will be able to rapidly increase our customer base.
We will also try to attract an audience by using social media applications and websites from different countries.
We have 170 social media accounts, and by simply running ads on these platforms, we can reach an audience of 300,000 people within a week.
We are able to announce our projects to 300,000 people in just one week.
What will your earnings be?
If you invest 200,000 US dollars in our holding company, you will receive your money back as 750,000 US dollars on December 30, 2026.
If you lend our holding company 200,000 US dollars, I will return your money as 750,000 US dollars on 30/12/2026.
You will lend our holding company 200,000 US dollars, and I will return your money as 750,000 US dollars on December 30, 2026.
If you invest 200,000 US dollars in our holding company, you will receive your money back as 750,000 US dollars on December 30, 2026.
I will return your money to you as 750,000 US dollars on December 30, 2026.
You will receive your 200,000 US dollars, which you lent to our holding company, back as 750,000 US dollars on December 30, 2026.
If you lend our holding company 200,000 US dollars, I will return your money as 750,000 US dollars on 30/12/2026.
Your investment of 200,000 US dollars in our holding company will be evaluated by our finance team, and I will return your money to you as 750,000 US dollars on December 30, 2026.
I will refund your money as 750,000 US dollars on 30/12/2026.
By investing 200,000 US dollars in our holding company, you will generate significant returns within a few months.
Thanks to our financial project, you will significantly multiply your money within a few months.
How can you contact us?
To learn how you can lend our holding company 200,000 US dollars, you can get detailed information by sending a message to the WhatsApp number, Telegram username, or Signal number below.
For detailed information, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can increase your money by investing 200,000 US dollars in our holding company, send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can invest 200,000 US dollars in our holding company and to get detailed information about our project, please send a message to the WhatsApp number, Telegram username, or Signal number below.
You can get detailed information by sending a message to the following WhatsApp number, Telegram username, or Signal number.
To learn how you can increase your money and get detailed information, send a message to our WhatsApp number, Telegram username, or Signal number below. We will provide you with detailed information.
My WhatsApp contact number:
+212 619-202847
my telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88
Hey everyone — Flowly is live on Product Hunt today. Been building in public here for a few months and the IH community has been genuinely helpful along the way.
Would mean a lot if you checked it out and left a comment or upvote 👇
https://www.producthunt.com/products/flowly-8
"That n(n-1)/2 formula is a killer—the jump from 28 to 120 paths is exactly why 'quick' corporate syncs turn into 4-hour marathons. My personal delta went from a 3-week sprint for a UI change at my last job to literally 45 minutes on my current project. Shipping Flowly in 30 days is a massive win against that tax."
This might sound interesting 👇
You have an idea
$19 entry
🏆 Tokyo trip + hotel
💰 $500
Round just opened 👉 tokyolore.com
Testing
We are looking for someone who can lend our holding company 200,000 US dollars.
We are looking for an investor who can lend our holding company 200,000 US dollars.
We are looking for an investor who can invest 200,000 US dollars in our holding company.
With the 200,000 US dollars you will lend to our holding company, our finance team will invest the money in the stock market and some business sectors, thus making a significant profit for both of us.
With your 200,000 US dollars investment in our holding company, our finance team will invest it in the stock market and 4 different business sectors, significantly increasing our profits within a few months.
Your 200,000 US dollars investment in our holding company will be invested by our finance team in the stock market and several business sectors.
The 200,000 US dollars you will invest in our holding company will be used by our finance team in the stock market and in 4 different business areas.
Which business sectors will be invested in?
Money will be increased by investing in major sectors such as cybersecurity, software, furniture, and e-commerce.
With the 200,000 US dollars you have invested in our holding company, we will invest in major sectors such as cybersecurity, software, furniture, and e-commerce.
With the $200,000 USD budget you've invested in our holding company, we will significantly increase our profits within just a few months by investing in high-market sectors such as cybersecurity, software, furniture, and e-commerce.
If we use the 200,000 US dollars you invested in our holding company across four different business sectors, our earnings will increase rapidly.
By dividing the 200,000 US dollars into different business areas, we will reduce the loss rate to zero.
By investing the 200,000 US dollars you lent to our holding company in the stock market and four different business areas, we will rapidly increase the rate of return on investment.
We will use the 200,000 US dollars you lent to our holding company to rapidly increase our profits by investing in sectors such as stock market and cybersecurity, software, furniture, and e-commerce.
Our finance team will use the 200,000 US dollars you lent to our holding company to invest in the stock market and in high-market sectors such as cybersecurity, software, furniture, and e-commerce.
By using 200,000 US dollars in 4 different business sectors, we will generate a significant amount of income within a few months.
So how will we market the products we produce?
Thanks to our strong advertising network, we will be able to sell the products we produce quickly.
Thanks to our strong advertising network, we will quickly find customers for the products and projects we will produce.
Thanks to our strong advertising network, we will attract a large audience to our projects, which means we will quickly generate significant revenue.
By using WhatsApp groups, Twitter, Instagram, Facebook groups, TikTok, Telegram groups, LinkedIn, and many other high-traffic social media platforms for advertising, we will be able to conduct large-scale advertising.
By using various advertising tactics such as Facebook ads, YouTube ads, Google ads, and email advertising, we will be able to rapidly increase our customer base.
We will also try to attract an audience by using social media applications and websites from different countries.
We have 170 social media accounts, and by simply running ads on these platforms, we can reach an audience of 300,000 people within a week.
We are able to announce our projects to 300,000 people in just one week.
What will your earnings be?
If you invest 200,000 US dollars in our holding company, you will receive your money back as 750,000 US dollars on December 30, 2026.
If you lend our holding company 200,000 US dollars, I will return your money as 750,000 US dollars on 30/12/2026.
You will lend our holding company 200,000 US dollars, and I will return your money as 750,000 US dollars on December 30, 2026.
If you invest 200,000 US dollars in our holding company, you will receive your money back as 750,000 US dollars on December 30, 2026.
I will return your money to you as 750,000 US dollars on December 30, 2026.
You will receive your 200,000 US dollars, which you lent to our holding company, back as 750,000 US dollars on December 30, 2026.
If you lend our holding company 200,000 US dollars, I will return your money as 750,000 US dollars on 30/12/2026.
Your investment of 200,000 US dollars in our holding company will be evaluated by our finance team, and I will return your money to you as 750,000 US dollars on December 30, 2026.
I will refund your money as 750,000 US dollars on 30/12/2026.
By investing 200,000 US dollars in our holding company, you will generate significant returns within a few months.
Thanks to our financial project, you will significantly multiply your money within a few months.
How can you contact us?
To learn how you can lend our holding company 200,000 US dollars, you can get detailed information by sending a message to the WhatsApp number, Telegram username, or Signal number below.
For detailed information, please send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can increase your money by investing 200,000 US dollars in our holding company, send a message to the WhatsApp number, Telegram username, or Signal number below. I will provide you with detailed information.
To learn how you can invest 200,000 US dollars in our holding company and to get detailed information about our project, please send a message to the WhatsApp number, Telegram username, or Signal number below.
You can get detailed information by sending a message to the following WhatsApp number, Telegram username, or Signal number.
To learn how you can increase your money and get detailed information, send a message to our WhatsApp number, Telegram username, or Signal number below. We will provide you with detailed information.
My WhatsApp contact number:
+212 619-202847
my telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88
The 'coordination tax' is the silent killer of great ideas. Shipping in 30 days is a superpower that most big companies will never understand.
Since you've already proven you can ship fast with Flowly, you should enter it into the Validation Arena (tokyolore.com).
It’s a 30-day sprint where you compete with other solo builders to see who gets the most traction.
The prize pool just opened at $0 right now, so you can lead the board immediately.
The winner wins a trip to Tokyo! 🏆
Thank you for support