Decline the traffic you can't carry
Stated flatly, the rule sounds like caution: do not accept load you cannot carry. In Martin's career it has been anything but cautious, because every time it was tested the load on offer was exactly what a founder wants: a front page on Sweden's biggest newspaper, a Kickstarter ten times over its goal, a factory run with orders waiting. The sources, from a 2010 talk on scaling to a 2024 podcast about uptime, show the rule kept once at real cost, broken once at real cost, and refined into something narrower than the slogan. You can take more than you can carry if you know which load it is and can test it first. You say no when you can't.
Two newspapers in the same week (2007)
The rule was learned before it was chosen. In a 2010 talk to Stockholm web developers, Martin recalls that Twingly was built as a hosted service, "en molntjänst även om den terminologin inte fanns då" (a cloud service, even though that terminology didn't exist then). Dagens Nyheter signed first, Svenska Dagbladet a few weeks later, in autumn 2006. ▶ 4:19 Neither launched until spring 2007, when SvD hinted on a blog that something was coming, DN panicked and published, SvD followed, and "både SVD och DN lanserade samma vecka, två dagar efter varandra. Båda hävdar att det var den andra tidningen som lanserade först." (both SvD and DN launched the same week, two days apart. Both claim the other paper launched first.) ▶ 5:34 Twingly's first real load was two of the country's largest news sites at once, on a timetable set by their rivalry.
It held, and the point of the story is why. Three years on, 115 sites in ten countries ran "på exakt samma lösning som vi lanserade för tre år sedan som då klarade av DN och Svenskans sammanlagda trafik" (on exactly the same solution we launched three years ago, which then handled DN's and Svenskan's combined traffic). ▶ 6:24 The lesson is architectural, not heroic. "Skalbarhet är alltså inte samma sak som prestanda" (scalability is not the same thing as performance), nor availability; they are separate problems. ▶ 8:58 "Molntjänster ger inte automatiskt skalbarhet." (Cloud services don't automatically give scalability.) It has to be built into the architecture from the start. ▶ 11:05 Capacity was also built into the calendar: a 2011 interview describes Twingly working in three-week iterations, each followed by a week of "lagg" for regrouping, customer support and planning. Tores sagor från verkligheten ↗
Saying no to Aftonbladet (2010)
The clearest case of the rule kept comes later in the same talk. Twingly Live, a real-time stream of tweets and Facebook posts around an event, had run on Aftonbladet during the Winter Olympics: "Under OS hade Twing Live runt 80 000 besökare per dag" (During the Olympics, Twingly Live had around 80,000 visitors a day). Then Aftonbladet wanted it on its front page for Melodifestivalen and ran tests, "började pumpa in tio gånger mer data, eller 500 000 besökare" (started pumping in ten times more data, or 500,000 visitors) a day. ▶ 40:29 "Då blir det lite skrämmande." (That gets a bit scary.) Twingly Live used long polling, which he describes without vanity: "Det är ett hack. Eller rättare sagt en sammansättning av flera hack som man måste använda för olika browser." (It's a hack. Or rather a combination of several hacks you have to use for different browsers.) ▶ 40:55 With hundreds of thousands of visitors each holding a connection open, "Det ställer helt nya krav på servern." (That puts completely new demands on the server.) ▶ 41:46
Scaling it horizontally was too big to build in the week they had. "Vi tackade nej till Aftonbladet och sa att vi kan inte erbjuda er att ha den tjänsten på er framsida under Melodifestivalen." (We said no to Aftonbladet and told them we can't offer you that service on your front page during Melodifestivalen.) ▶ 42:36 The reason is the rule in one sentence: "Vill inte göra det på en vecka, för då har vi noll tid på oss att testa efter att det är färdigbyggt innan det ska driftas." (Don't want to do it in a week, because then we have zero time to test after it's built before it goes into production.) ▶ 43:03
Two things in the same talk keep this from being a story about timidity. Twingly kept paying Amazon about $3,000 a month for S3 it could probably self-host for less, "eftersom det är sån trygg och säker hosting" (because it is such safe, secure hosting): capacity was bought, not refused. ▶ 39:34 And he warns against the opposite error, citing FriendFeed, which never needed horizontal scaling because memory halved in price as its users doubled; build for a flood that never comes and the time is lost. ▶ 15:01 The rule is not always build for the flood. It is don't accept the flood untested.
The Kickstarter that buried the team (2012)
The rule was broken, knowingly and rightly, with Memoto. The campaign asked for money "to start production of the first 1,000 cameras". ▶ 1:19 It reached its $50,000 goal in five hours and $500,000 in a month. ▶ 9:48 At Web Summit in 2015 Martin explained that seed money had been raised beforehand, so "Kickstarter was a go-to-market channel for us, our strategy", ▶ 11:08 and that the underestimated part is the preparation, where saying you are doing PR is easy and doing it "takes a lot of work and a lot of time". ▶ 10:09
Then the admission. "What we weren't at all prepared for was the overwhelming customer support load that immediately comes with a crowdfunding success. We had to spend 24 hours a day just answering messages on Kickstarter and outside." ▶ 11:33 By 2015 he was taking calls from other hardware teams and sorting their troubles into three kinds: not knowing how to prepare, a campaign that didn't take off, and support that overwhelms the team, where "communication is really key to keep the value in the community and keep a good spirit". ▶ 12:38 ▶ 13:03 Nobody declined this traffic, and nobody should have; ten times the goal was the company. The load Memoto could not carry was not servers but people, and it arrived the same day the money did. See The Kickstarter that funded everything.
Heaven or hell (2013–2014)
A year later the same team chose its load deliberately. Weeks before the November 2013 launch, Martin told SlashGear the app would ship without search, "because it doesn't yet work properly", and that the OS X uploader was done while "the Windows version will hopefully be completed for November, or during November; we're not sure about the Windows version". The rationale: "it's more important to get people using it. There are so many bugs to be ironed out, we need to get it out there" before spending time on bells and whistles. Where that would leave them he could not say: "We don't know what it will be like in two months time: heaven or hell." SlashGear ↗
Early 2014 was closer to the second. On Startuppodden he reports around 400 cameras delivered, ▶ 5:50 against orders of roughly 7,000, ▶ 6:23 and a delivery curve that inverted expectations: the first 1,000 backers were spread over two months of ramp-up, "och sen resten, övriga, vad är det nu, 6000 kameror som ska ut komprimeras ihop till en månad" (and then the rest, the other, what is it, 6,000 cameras that have to go out get compressed into one month). ▶ 5:57 The difference from Melodifestivalen is that the gaps were known: software could be iterated in the wild, and a factory ramp, untestable in a week, could at least be scheduled. The shipping discipline itself is in Failure & resilience.
Orders of magnitude (2016, 2023)
Hardware sharpens the rule because its load does not come in increments. On a 2016 panel Martin said "the first product was manufactured in 25,000 units before we closed it down", that a hardware startup moves from being an R&D company to a sales company in succession, and that "a preferable number would be 250,000 of the second generation and 2.5 million of the third". ▶ 19:48 Seven years later, half joking on his podcast, he priced a restart of the Clip at $2.5 million for "10,000 units, literally 10,000, not as a, oh, that's a big number" but as the minimum quantity to start production. ▶ 27:48 ▶ 28:15 You cannot decline part of a factory run; the only honest capacity question in hardware is asked before the order.
Reliability first (2024)
The rule's latest form is quieter. On the podcast in 2024, Rasmus Adler Wahlberg, Martin's co-founder at Multiply, reports: "We've done a lot of work on the technical side. We have good security. We had 100% uptime last year. 90 days." Martin's response is that a focus on service and closeness to the customer "sounds incredibly healthy actually for the company". ▶ 25:34 Rasmus adds that many companies are afraid of AI security and that Multiply was pursuing ISO certification to prove otherwise. ▶ 25:49 It is the 2010 decision restated for a software company: build the carrying capacity, and the proof of it, before selling the traffic.
Worth remembering
- Say no when there is no time to test: Aftonbladet's front page, declined because a week left zero time after the build. ▶ 43:03
- Capacity is decided at design time: the solution that carried two newspapers carried 115 sites three years later, because cloud alone gives no scalability. ▶ 6:24 ▶ 11:05
- The load you can't carry may be people, not servers: a Kickstarter success meant 24-hour support nobody had planned for. ▶ 11:33
- Known gaps are a choice, unknown ones are a gamble: shipping without search and without a Windows uploader was deliberate. SlashGear ↗
- Hardware load steps by orders of magnitude and has a floor: 25,000 units, then ten times that, and never fewer than 10,000. ▶ 19:48 ▶ 27:48







