Tuesday night, 11:12pm. My son has been asleep for two hours. I have three Cursor tabs open, a half-written prompt, and this voice in my head saying: hurry up, you wasted the evening, catch up.
So I rush. I code something. I ship. I go to bed at 1am feeling like I made progress.
The next morning, making breakfast, I look at what I pushed. It's garbage. Not technical garbage — strategic garbage. A feature nobody asked for. A component that solves nothing. Motion without direction.
The acceleration wasn't a lever. It was an escape.
Sahil Bloom posted something that stopped me cold:
> "Major cheat code for life: Become difficult to rush."
The world pushes you to rush. Rushed decisions. Rushed conversations. Rushed timelines. And in the solopreneur/AI ecosystem, it's worse: every day a new model, a new framework, a new guy on Twitter who "built in 48h" what you've been planning for three weeks.
But Sahil isn't saying "be slow." He's saying: become difficult to rush. That's radically different.
### What solo fatherhood forced me to understand
Before being a solo dad, I could rush. All-nighter? Sure. Weekend coding binge? Easy. 72-hour sprint for a launch? Let's go.
My son killed that option. And it's the best thing that happened to me as a builder.
When you have a kid who wakes up at 6:45am no matter what, you can't cheat time anymore. You have your slots — 9pm-11pm on weekdays, a few hours on weekends during nap time — and that's it.
So either you panic and rush through those slots. Or you accept the constraint and become surgical.
I've done both. Rushing gave me: three abandoned projects, a silent burnout in March, and the guilt of snapping at my son because I was wrecked by my own stupidity.
Strategic slowness gave me: a product that runs, users who come back, and enough energy to be present at breakfast.
The choice is made.
### Ship, learn — not ship, ship, ship
Solopreneur culture worships shipping. "Ship fast, break things." "Launch in a weekend." And AI amplified this: with Cursor and Claude, you can technically build an MVP in 48 hours.
But being able to go fast doesn't mean you should go fast.
The real cycle, the one that builds something lasting, is ship, learn. Not ship, ship, ship.
- Ship: put something out there. Small. Imperfect. But real.
- Learn: listen. Look at the data. Talk to people. Understand what's missing.
- Then ship again — but this time, you know why.
Rushing eliminates the "learn" phase. You chain ships without ever absorbing feedback. You build a castle of features on a foundation of assumptions.
I have a board in Notion with two columns: "Shipped" and "Learned." If the Learned column has been empty for more than a week, I know I'm rushing. I stop. I close Cursor. I go for a walk with my son.
And weirdly, it's often during those walks that the real solution appears.
### The hollow product test
In January, I rushed an AI prompt automation tool. Three all-nighters. Proud of myself. Launched on a Sunday night with a LinkedIn post.
47 likes. 12 signups. 0 active users after one week.
Hollow product. The bread that collapses when baked.
In April, I took a different angle. Same domain — applied AI — but this time, I spent three weeks talking to people before writing a single line of code. I shipped an ugly prototype. I listened. I iterated. Slowly.
Result: less spectacular at launch. No viral post. But people using the thing every day. Sending me messages asking what's next.
The difference? Three weeks of fermentation vs three nights of rushing.
### Acceleration as escape
Here's the uncomfortable truth: most of the time when I rush, it's not because I have a deadline. It's because I'm afraid.
Afraid the idea is bad — so I code instead of validating.
Afraid someone else will launch first — so I cut corners instead of differentiating.
Afraid of inaction — so I confuse agitation with progress.
Rushing is the anesthetic of uncertainty. As long as you're coding, you're not thinking. As long as you're shipping, you're not doubting. As long as you're moving, you're not facing the question that hurts: does anyone actually need this?
Becoming "difficult to rush," as Sahil says, means accepting to sit with that question. To look it in the face. And to move only when you have an answer — even a partial one.
### My new rhythm
Today, I build like I make bread.
I mix the ingredients (idea + user research). I knead (quick prototype). Then I let it rise. For a long time. I don't touch it. I do other things. I live my life as a father.
And when it's ready — when the feedback has done its work, when the structure is there — I put it in the oven.
It's less sexy than "I built this in a weekend." It doesn't make good LinkedIn content. But it makes products that last. And a father who lasts too.
Next time you find yourself at 11pm with three tabs open and that artificial urgency in your gut, ask yourself one question:
Am I moving forward, or am I running away?
If the answer is honest, you'll close the laptop. And tomorrow morning, at breakfast, you'll know exactly what to build.
And if you want to put AI to work for your time — a custom SaaS or an n8n automation — let's talk on sebastiendebollivier.com.
