We were only ever half serious

Version 1.0 · Published 2026-08-03

On 7 December 2015, Marcel Panse and I published a guest post on High Scalability called “The Serverless Start-up - Down With Servers!”. It explained how we had built Teletext.io on API Gateway, Lambda, DynamoDB, S3 and CloudFront, with no servers to manage. Not one.

Somewhere in the middle, we wrote this:

We like rules. At our previous start-up Peecho, product owners had to do fifty push-ups as payment for each user story that they wanted to add to an ongoing sprint. Now, at our current company myTomorrows, our developer dance-offs are legendary: during the daily stand-ups, you are only allowed to speak while dancing - leading to the most efficient meetings ever.

That paragraph is the reason anybody remembers the article.

Both of them were real, for a while

The push-ups happened and so did the dancing. They started as inside jokes and we genuinely ran them for a stretch, which is how most of our rules went: invent one, enjoy it, get something out of it, let it quietly lapse. Nobody was still earning tickets with burpees in month four.

The dancing is worth explaining, because the detail that made it work is missing from the article. We held the stand-up in a large open space with the rest of the company around us. So the rule was not really about dancing. It was about doing it in front of everybody. That made it an organizational joke and a working boundary at the same time.

What it was never was formalized. No policy, no handbook, nothing anyone could be held to, and that was deliberate: the moment you write down that speaking requires dancing, you have written down a rule that not everyone can meet. That was obvious to us at the time, which is exactly why it stayed informal.

In the article, though, neither rule was a description of daily life. They were a metaphor, and they were there to do a job.

What the metaphor was for

We wanted to show how we like to solve problems, which is by picking a hard boundary first and then working inside it, rather than deciding case by case. A mid-sprint user story is a real cost. Handle it ad hoc and that cost lands quietly on the team. Put an absurd, non-negotiable price on it instead, in public, and suddenly everyone is making a deliberate choice.

The point was never the push-ups, and it was never the dancing. It was the boundary, and the fact that you could not quietly step around it.

And the joke was never really the exercise either. The joke was the premise: that a company could exist where somebody would actually enforce this, straight-faced, forever. We were mocking our own subculture by playing it completely deadpan, which is a thing you can only do about a world you are standing inside. Writing the serious reason as a joke let us make the point and undercut ourselves in the same breath, and honestly, it worked exactly as intended.

The same move built the architecture

Which is why the paragraph belonged in that article rather than in some other one. Six paragraphs away, we had written the technical version of exactly the same idea: at Teletext.io we were not allowed to use servers. Not even one.

That is not a conclusion anyone reaches from a requirements document. It is an arbitrary rule we imposed on ourselves, and then designed our way out of. Our own line for it in the piece was that constraints fuel creativity. Give yourself no servers and you will find API Gateway, Lambda and DynamoDB. Give a product owner a push-up tariff and you will find out which user stories actually mattered.

Same method, twice, in one article. One version got an architecture diagram. The other got a punchline. We assumed readers would see them as a matched pair.

Nobody read it that way

It went to the front page of r/programming and finished at 142 upvotes and 143 downvotes, about as evenly split as a thread can get.

Some of it was the argument we came for, and it was a good one. AWS Lambda had only been announced in preview in November 2014 and was barely months out of general availability, so people pushed hard on vendor lock-in, on what happens when Amazon raises prices, on why DynamoDB rather than a Postgres instance on RDS. Someone read the monthly cost table as a daily one and was politely corrected. Normal, useful stuff.

Underneath it ran a completely different conversation, and the tell was how people quoted the push-ups paragraph: in full, with nothing added but “Wtf?” and “What in the actual f***.”

Then the questions started. “That part had me wondering if the whole article was satire.” “The dance-offs were satire, right?” “Is that serious, or satire? I’m having a bout of Poe’s Law here.” One commenter had been arguing the technical side for a while, stopped mid-thread when he realised the quote was real, and admitted the line had been so ridiculous that it had not registered the first time he read the piece.

That was the moment it became clear. A few hundred engineers had read a metaphor as a job description, and the article was no longer about serverless at all.

My favorite came from someone working out where we were based: “I assumed it was a Silicon Valley startup… turns out it is Amsterdam. It takes some effort to out-valley the valley.” Someone else wrote “Move over Mike Judge.” Somebody filed the whole thing under r/programmingcirclejerk. Reading it back eleven years later, I laughed as hard as I did at the time.

Those three came closest of anyone in the thread. They had the register exactly right, spotted the Mike Judge sitcom energy, and clocked that the paragraph belonged in a circlejerk sub. The only thing they got wrong was the direction: they assumed we were the specimen rather than the ones doing the impression.

The comment that arrived at our own conclusion

One has stayed with me, and it was not one of the funny ones.

Someone wrote that this is the kind of detail that gives rise to allegations of ageism. When a reply asked what he meant, he explained: he was picturing his 65-year-old father doing fifty push-ups in order to do his job, and his mother, who had lived with MS for most of his life, trying to dance so she could speak in a stand-up.

He was right, and he had reasoned his way to the same place we had. That is the precise reason neither rule was ever written down. A joke you can opt out of is a joke. A requirement that speaking depends on a physical act is something else, and it excludes people the moment it becomes policy.

The difference is that we knew that and he could not. We had put the rules in the article as though they were rules, so the only honest reading available to him was the one he gave. Write in metaphor and you do not get to choose who reads it as fact, and the people who read it as fact are entitled to judge the thing they think they are looking at. His comment is not a misreading I want to correct. It is the strongest evidence in the thread that the joke should never have become a policy, which is what we had already decided.

Nobody had a word for it yet

What we had accidentally produced was rage bait. In 2015 that was not a genre. People were not writing paragraphs to farm outrage, the term was not in common use, and it was certainly not a tactic anyone would have admitted to.

So mostly we were baffled, and then delighted. We had written something to be enjoyable and to say something real about how we work. It was enjoyed, it said the thing, and it also drove a portion of the internet into sincere fury about a workplace that had stopped existing months earlier. Watching that happen in real time is still one of the funniest things either of us has been involved in.

What turned out to be true

Read the technical half now and it looks different. Two commenters made predictions mid-argument. One said platform services would become the default regardless, “much like high level programming languages have.” Another, defending DynamoDB, wrote that it would be hard for his generation of tool builders to admit something turnkey was good enough, and that “by 2020, they’ll say no one was ever fired for choosing AWS.”

Both aged extremely well. The position we were mocked for is now unremarkable.

The attention turned real, too. Werner Vogels, then CTO of Amazon, referenced the article and Teletext.io more than once, and AWS featured us in its Hot Startups series in August 2016. The architecture held up well enough that UNLESS still runs on that Teletext.io base today. The commercial rollout of Teletext.io is a different story, and one I will get into another time.

What I would do again

I would keep the paragraph. The lines half the thread dismissed as vanity were the clearest statement in the article of the method that produced the thing they were arguing about. Pick a boundary, let the constraint do the design work, and you get somewhere an open-ended discussion never would. We still build that way, which is why Unless is small on purpose and does one thing.

The thread did teach me where that method has a limit, and it is a sharper line than I could have drawn at the time. You can be absolute about a constraint on a system. No servers, not even one, is a rule that costs a machine nothing and forces you to think. You cannot be absolute about a constraint on people, because the moment it is written down, someone is excluded by it. That is why one of those rules is in the architecture diagram eleven years later and the other never made it past an inside joke.

What I did not understand in 2015 is how little of the reaction was about us. A room full of engineers had been reading startup culture pieces for years and was thoroughly tired of them, and we handed them a fresh specimen at the perfect moment. They were not really arguing with our stand-ups. They were arguing with a decade of them.

The serverless bet does not need defending anymore. The metaphor, oddly, is the part I still would.