A place for developers to talk about building on Farcaster.

/dev

Ever worked on a project that blew past its deadline? (who hasn’t?)

Even the best PMs can’t estimate time accurately. 

Why is estimating time so hard? Let’s unravel the mystery behind project timelines and why we often miss the mark 🧵

At the start of a project, we know the least…
…and yet, that’s when we’re asked:
“How long will this take?”
Spoiler: we’re all just guessing.

Frames V2 developer (or are they called Mini Apps now?)

There’s a name for this: the Cone of Uncertainty.
🟢 At the beginning, your estimates can be off by a lot (like 4x).
🟢 As you work and learn more, your estimates get better.
But by then? You’re halfway to the deadline. ⏳

This creates a fun little paradox:
You’re expected to commit when you know the least…
…but by the time you actually understand the work, you’re running out of time. 😅

The result?
⛔️ Deadlines slip
⛔️ Features get cut
⛔️ People stress out
Sound familiar?

So how do you deal with this?

✅ Plan in iterations (short sprints > big launches)
✅ Use time ranges, not fixed dates
✅ Communicate early and often (very important)
✅ Expect change, and build in wiggle room

Instead of saying “it’ll take 4 weeks,” try:
“We estimate 3–5 weeks, depending on what we discover.”
It sounds less confident, but it’s actually more professional.
Good teams make room for uncertainty.

Estimates aren’t promises, they’re bets.
Make small bets.
Reassess them often.
And tell your team (and stakeholders) what’s real, not what’s comfortable.

The truth: Everyone struggles with time estimation.

But if you respect the unknowns, communicate clearly, and stay flexible, you’ll save yourself a lot of pain.

Have you experienced a timeline that went wildly off track? Share your story or tip below 👇