# Startup decelerator

Source: https://abcastor.com/writing/startup-decelerator/
Author: Castor
Published: 2026-10-06

6 Oct 2026 · startups, strategy

How to keep moving when you don't know yet where you're going.

At a startup event this October, one of us spent the evening describing a
project we are working on. Halfway through a sentence he realised he could not
say why it was different from what already exists. He was sure it was. The
founder he was talking to looked impressed anyway.

What people liked less was the plain version of where we are: exploring, without
knowing yet what we will build. People want to hear that you are building
something cool. That is fair. At an event like that everyone is sorting a room
of strangers by conviction, and "we don't know yet" sounds like having none.

That same week, talking it over with a friend, we found a name for what we are
doing: a startup decelerator.[^1] An accelerator compresses. Y Combinator's
programme lasts three months and ends on Demo Day, and founders describe the
eleven weeks before it as the most productive of their lives.[^2] A decelerator
stretches the time before you commit to the one thing that will take years of
your life, and spends that time watching what happens.

## Why slow, now

The faster the situation moves, the slower we think you need to be about
choosing what deserves years. Everybody is running after a train that has
already left. The useful move is to stop for a second, work out where it is
going, and meet it at the next station.

We did want to build a startup. Every idea we discussed came with the same
doubt: would AI be doing this on its own in six months? We could have aimed for
something that made money for three or four years and then sold it, but we
wanted to make something that lasts, and we couldn't explain to ourselves why
any one idea deserved that. A plan made in a hurry today is a bet on where the
train was this morning.

Slow is about the big commitment, and only that one. Taking money, hiring and
promising a product to strangers can all be walked back, at a price paid mostly
by the people who trusted us, so we slow down for those, the way [Why
Castor][L1] puts it. Everything that tells us something and can be undone, we do
fast: a piece of open-source software we can write in a week, an essay, a
conversation. Two people who live together can decide that kind of thing over
breakfast, which is the advantage [a small team always has over a giant][L2].

The Romans had a phrase for this, *festina lente*, make haste slowly. Suetonius
says Augustus used it often, and fifteen centuries later the Venetian printer
Aldus Manutius made it his mark, a dolphin wrapped around an anchor.[^3]

[L1]: https://abcastor.com/writing/why-castor/
[L2]: https://abcastor.com/writing/skunk-and-beaver/

## Moving without a destination

Say you are walking somewhere four blocks north and three blocks east, in a city
laid out as a grid. Walk the four north, turn once, walk the three east, and it
is seven blocks. Mix the turns up however you like and it is still seven. What
changes is the traffic lights. One of us takes whichever crossing is green, as
long as it leads the right way. Walk all four blocks north first and you have
spent your choice: every crossing left has to take you east.

That is how we run Castor while we decelerate. We go in several directions at
once: this blog, and [open-source software][L3] that circles one theme, from a
server that lets an agent work in the browser tabs you already have open to a
router that spreads coding work across the AI subscriptions you already pay for.
Each project is small enough to finish or drop in a few weeks, so a turn costs
little.

The walker knows where they are going. We don't have a destination yet, but we
have a direction. Our [values][L4] are written down on this blog, dated, and
they already rule out some green lights. An agent that acts in your name without
asking would be quicker to build and easier to demo; [Gaddi][L5], our browser
server, holds actions like publishing until you approve them yourself, with
Touch ID, on your own Mac.

[L3]: https://github.com/ABCastor
[L4]: https://abcastor.com/writing/values-as-advantage/
[L5]: https://github.com/ABCastor/gaddi

## Watching for what

From the outside, sitting back and watching looks exactly like procrastination,
and on some days that is what it is. The difference we try to hold on to is that
procrastination waits for a feeling, the feeling of being ready, which never
comes. A decelerator waits for information, and should be able to say which.

We watch where a person still makes the result better and where keeping one in
the loop is ceremony, which is [the question behind Castor][L6]. We watch what
agents can do this month that they could not do last month. And we write,
because writing is how we catch ourselves: put "we're exploring" on a page and
the reader will ask what we have learned. [OmniRead][L7], our web reader for
agents, came out of something we kept running into: an agent cannot tell a page
it read from a page it half read, so it reasons over both with the same
confidence. Now every read comes back with evidence of whether it was complete.
When we can't say what a project taught us, maybe we enjoyed making it and
haven't learned much yet.

The weak spot is the stopping rule. Sometimes the street ahead is the one you
need, and its light is red. A large project is mostly red lights: long stretches
where the interesting choices have been made and the rest still has to be done.
If every dull stretch sends us looking for a new direction, we will end up with
a fine collection of beginnings. So we are looking for a question that keeps
coming back after the excitement of a new project wears off, because several
projects have left it unanswered, or because the answer matters enough to sit
through the boring parts. We can say where to look. We cannot yet say what we
will see on the day it is time to commit.

[L6]: https://abcastor.com/writing/why-castor/
[L7]: https://github.com/ABCastor/omniread

## The case for hurrying

Everything above argues with the person who did most to define what a startup
is. "A startup is a company designed to grow fast," Paul Graham wrote in 2012.
"The only essential thing is growth. Everything else we associate with startups
follows from growth."[^4] At Y Combinator, which he co-founded, a good week
means growing 5 to 7 percent, and "if you can only manage 1%, it's a sign you
haven't yet figured out what you're doing."[^4]

He answered this essay, too, in 2006. "Startups make all kinds of excuses for
delaying their launch. Most are equivalent to the ones people use for
procrastinating in everyday life."[^5] Among the causes of delay he lists
"working on too many different things", which is a fair description of a walk
across a grid. He thinks the risk runs almost entirely one way: "Launching too
slowly has probably killed a hundred times more startups than launching too
fast". And the evening at the event was a small case of another of his lines:
"it's only by bouncing your idea off users that you fully understand it."[^5]

We are playing devil's advocate here, and we know it. A startup's nature is to
grow fast and to move fast to get there; that is what the word means, and Graham
has watched far more of them than we have. We don't know which of us is right,
and the opposite of this essay may well be true. We often argue the other side
on purpose, to see whether the strong case holds up.

Even he allows that a startup's growth begins with "an initial period of slow or
no growth while the startup tries to figure out what it's doing."[^4] Our bet is
only about that first period: that while what machines can do changes every few
months, it should be longer than it used to be, and spent shipping small things
within a week and saying them out loud to strangers, which is his advice too. If
we are wrong, a year from now we will have shipped plenty and committed to
nothing, and the last paragraph of this essay asks you to call that out.

## The pitch problem

A decelerator pitches badly. The pitch asks for the conclusion we have chosen
not to draw yet, so the honest answer loses most rooms to someone with a slide
and a number.

The evening gave us something for the price. Saying a project out loud to a
stranger, with a little pressure on, found in a few seconds a gap that weeks of
building had hidden. Nothing rides on that project yet, so the gap cost us one
awkward sentence and a better question to work on. Next time we will say what we
are watching for and show one thing that works.

If a year from now these essays still say "we're exploring" and none of them
says what we chose, it will have been procrastination, and you should tell us
so.

## Notes

[^1]: The word is not new. Decelera, a programme in Menorca, has called itself a
      startup decelerator since 2015: ten days for founders to step away from
      their companies. We mean something longer and cheaper: a way of running
      the company before there is one. [Source][L8]

[L8]:
      https://www.eu-startups.com/2022/12/decelera-menorca-opens-call-for-impact-startups-to-take-part-in-its-2023-decelerator-programme-sponsored/

[^2]: Y Combinator, "What Happens at YC": a three-month programme, four batches
      a year, each ending in Demo Day; "Many founders describe the 11 weeks
      leading up to Demo Day as the most productive period in their lives."
      [Source][L9]

[L9]: https://www.ycombinator.com/about

[^3]: Suetonius, *Life of Augustus* 25.4: "Hasten slowly" and "That which has
      been done well has been done quickly enough" were among his favourite
      sayings. Erasmus discusses the adage, and Aldus's dolphin and anchor, in
      his *Adagia*, under "Festina lente"; his verdict on his printer was that
      making haste slowly had brought Aldus as much gold as reputation. Summary
      and sources: "Festina lente", Wikipedia. [Source][L10]

[L10]: https://en.wikipedia.org/wiki/Festina_lente

[^4]: Paul Graham, "Startup = Growth", September 2012. [Source][L11]

[L11]: https://paulgraham.com/growth.html

[^5]: Paul Graham, "The 18 Mistakes That Kill Startups", October 2006, mistakes
      8 ("Slowness in Launching") and 9 ("Launching Too Early"). [Source][L12]

[L12]: https://paulgraham.com/startupmistakes.html