Amdahl's law,
applied to companies.

A computer scientist named Gene Amdahl figured out in 1967 that you cannot make a computer arbitrarily fast by adding more cores. The math is unforgiving. The same math runs your company.

Amdahl's law is one sentence: the speedup of a system is limited by the part of it that cannot run in parallel.

Pour it into a formula and it says: if 5% of a program has to run sequentially, no amount of parallelism takes you past 20x speedup. Not 21x. Not "with enough cores, anything is possible." Twenty.

Hire 1,000 engineers, distribute them across the most beautiful tooling, and that 5% of serial work caps you at the same speedup as if you hired 100. The 900 extra people are noise.

I think about this every time a founder tells me their team is fast.

The serial part is hiding in plain sight

Pick a real customer-facing process in your company. Walk it end to end.

A customer messages on Instagram at 11pm. The DM lands in someone's phone the next morning. They open it, decide if it is a lead, copy the handle into a CRM, paste the conversation, tag the brand owner. Brand owner reads it at lunch, replies in a sentence, asks the operator to follow up. Operator drafts. Founder approves. Operator sends. The customer has already bought from someone else.

Every step except sending and reading is serial. None of it parallelizes. None of it gets faster by adding people. You can hire two operators and one will still wait for the founder.

Companies don't run at the speed of their fastest person. They run at the speed of their slowest handoff.

The trap: founders solve the wrong half

When a company feels slow, the first instinct is almost always capacity. Hire more engineers. Hire more marketers. Spin up a new pod. Buy software that the existing team will configure in three months.

Capacity is the parallel part. It is the 95%, and it is the easy part to scale.

The serial part is harder. It looks like:

• A founder who needs to approve every brand voice change.
• A legal review that takes seven days regardless of urgency.
• A QA queue that closes at 6pm IST and reopens at 10am IST.
• A handoff between "marketing got the lead" and "support owns the customer" that goes through a single person's inbox.
• A pricing decision that nobody owns.

These are not capacity problems. Doubling the team makes them worse, because now there are twice as many requests stuck behind the same gate.

The math is identical to Amdahl's. If 10% of a process is serial, you cap out at 10x speedup, no matter how much you grow. Most companies are operating at 3x of their capped 10x and convincing themselves the answer is more people.

What designers know about this

I came to building through design. The thing design teaches you is that the page is not the problem. The flow is.

A beautiful checkout button does nothing for a checkout flow that asks for the address twice. A team of A-players does nothing for a process that funnels through one person's calendar. The slowest leg owns the system.

Designers spend more time on the connective tissue between screens than on the screens themselves. Founders should spend more time on the connective tissue between people than on the people themselves.

What to do about it, in order

Find your serial part first. Map an end-to-end customer journey, in minutes, not in vibes. Use a stopwatch. Where do hours pile up?

Then, in this order:

1. Delete the step. Most serial steps exist because nobody removed them when they stopped being necessary. The fastest step is the one that does not happen.
2. Move the decision left. A founder approving a Slack message is a founder approving messages forever. Codify the decision once, push it down to the operator.
3. Make the slow leg asynchronous. If a step needs sleep on it, do not let it block faster steps. Parallelize what can be parallelized.
4. Only then automate it. Software is most useful as the last 20%, not the first 80%. Automate a clean process; do not automate a mess.

If the slowest leg of your company is a person, you have a hiring problem. If it is a process, you have a design problem. They feel similar from the inside, and the cures are different.

Spur's vision is Amdahl's, in commerce

This is also what I think about when I think about Spur.

D2C brands have parallelized the easy parts. Ads run in parallel across networks. Influencer outreach runs in parallel. Email campaigns blast in parallel. The marketing stack is well-cored.

What stayed serial: the conversation. A customer asking a question on WhatsApp at midnight. A shopper abandoning a cart while on a video call. A first-time buyer who needs five minutes of attention before they spend ₹3,000. The conversation is the serial bottleneck of commerce.

You can put 10x more spend behind the ads. You can hire 10x the agency. Until the conversation moves at the speed of the ad, you are paying for traffic that times out.

So the bet is this: take the slowest leg of commerce, the one that humans have always done one at a time, and let an AI run it in parallel without making it feel like an AI ran it.

Same idea, smaller scope: make the bottleneck go away. The rest takes care of itself.