point-o-matic: sane dev estimates

3 min read

I often need sane estimates I can say out loud without cringing later. To solve this, I've made the Point-O-Matic to "price" project friction.

Scoring

Points are basically friction units. They're not effort, days or hours, but just an abstraction of how much reality tends to slow me down. My goal is to start simple, then nudge a score up or down based on the bumps I can already see.

Baseline

Start at 4 points (≈ 2 dev-days for a small feature), but never go below 2 points (≈ 1 day)

4 points is a small feature that's not trivial but also not a big deal. It's the baseline for anything that's not a tiny tweak. 2 points assumes I'm moving in my own stack with no surprises and is the absolute floor. It basically means "I could knock it out today if the world stays quiet."

Add points for real friction

Add when the work leaves my lane or mutates data that matters. These are the culprits that turn "today" into "next week." Tick only what's truly in play.

  • +6 major new external API or SDK (unproven docs, high risk)
  • +4 external gate I don't control (App Store, partner, security or legal)
  • +3 data migration or irreversible schema change
  • +2 minor new external API or sdk (well-documented, low risk)
  • +2 new roles or permissions model (beyond a tweak)
  • +2 brand-new UI surface (not just a tweak)
  • +2 touching multiple services or repos
  • +2 real security, or compliance target
  • +1-2 spec is fuzzy until I poke it

Subtract a bit if familiar (cap total at −2)

Familiarity reduces drag, but only a little. Cap the total at −2 so optimism can't bulldoze reality.

  • −1 I've shipped this exact pattern recently
  • −1 reusing a proven component or path I own
  • −1 "ugly is fine" (behind a flag, minimal polish)

Hello-world rule

Nothing gets an estimate until I've done something that proves the path is clear. A 60 minute smoke test tells me if I'm on bedrock or quicksand. If I can't get a button to fire code and see a result, I'm still mapping the cave. We price that uncertainty.

If I can't get click → code runs → visible result in ~60 minutes, add +3 (uncertainty tax)

Multipliers

When risks stack, they compound. Double early—while I can still cut scope—rather than after I'm already late.

Pull x1.5 if any one is true:

  • point total is already 9-11
  • external review (security, legal, compliance)
  • significant new integration (e.g. payment processor, auth provider)

Pull ×2 if any one is true:

  • point total is already 12 or more
  • critical path for a launch or deadline
  • external gate and a live data change
  • major new platform or runtime (e.g. iOS, Android, Node version)

Guardrails

These keep the tool lightweight and stop it from turning into process cosplay.

  • Touch the entry point before scoring (no cold estimates)
  • Mid-build reality check: if it feels about +2 points off, rescore and reset the date
  • Cut scope before moving dates

Quick examples

  • Settings tweak + small API call
    4 (base) +2 new UI −1 reuse = 5 pts → 2.5 days

  • Billing webhook to a new partner + migration
    4 (base) +3 new API +2 migration −1 done similar = 8 pts → 4 days → × 1.5 External Review ≈ 6 days

  • New feature with vendor approval + new roles + critical path
    4 (base) +4 external gate +2 new roles +2 new UI +1 SDK = 13 pts → 7 days → ×2 Critical Path ≈ 14 days


I'll keep refining this as I use it. If you try it, let me know how it goes!