Skip to content
Solutions · Developers

Quote from your own velocity, not your gut.

Every freelance developer’s estimate is some version of "I think I can do it in three days." The math behind Ensaria replaces that with: "tasks like this have taken you between 2.5 and 4 days over the last 12 instances, median 3.2." Same confidence, calibrated against reality.

The problem

Where this usually breaks.

The planning fallacy — humans systematically underestimating how long anything takes — is the best-replicated finding in behavioural psychology. Developers know it intellectually. We tell jokes about it at standup. And then we still go ahead and quote a 5-day feature in 3 days, because *this* one feels different.

The single proven antidote is reference-class forecasting: don't estimate the current task; estimate from the *distribution* of past similar tasks. The honest number lives in your last 30 commits, not in your intuition.

Every estimate shows median + p25–p75 range + sample size — sourced from your own past 90 days.

How Ensaria's Reality Engine does it

Every task you create gets auto-tagged from its title + project + client + history. When you set an estimate, Ensaria pulls the matching reference class from your last 90 days and shows the median duration, the p25–p75 range, sample size, and confidence (low / med / high based on sample + variance).

If the sample is too thin — fewer than three similar tasks — it tells you that instead of guessing. The Money Lens never makes up a number; it just shows you the truth in your own data.

What this changes about quoting

When a client asks “how long for X?”, you no longer answer from gut. You answer from “tasks like this have taken me median 4.2 days, range 3.1–5.8, across 14 instances over the last year.” That's a quote that's harder to negotiate down and easier to deliver on time. Read more on reference-class forecasting and the planning fallacy.

In the product

Where this shows up.

A few other surfaces in Ensaria where the same idea lives — none of these are settings you opt into; they're how the product behaves by default.

No similar work yet
Ensar will learn from the first 5–10 sessions. Until then, your estimate is your own.

No history yet — Ensar refuses to fabricate. After 5–10 sessions, the math takes over.

Effective rate per project surfaces the bug-fix client who's silently draining your month.

A scheduled block with the matching estimate already on the card — start time, end time, sample.

Sunday Review shows velocity vs last week + capacity left for next — the real shape of your sprint.

Common questions

Does Ensaria integrate with GitHub or my issue tracker?

No native integration at v1. GitHub-issue → Ensaria-task syncing is in the backlog. The honest answer: integrations are easy to build badly, and we'd rather ship the calm planning core first. Most developers manage tickets in GitHub/Linear/Jira and use Ensaria as the meta-layer.

How does Ensaria estimate ticket duration?

It doesn't generate estimates from nothing. When you add a task, Ensaria finds tasks from your last 90 days with matching auto-tags and returns the median, p25–p75 range, and sample size. If there's no relevant history, it tells you that instead of fabricating a number.

I quote in story points, not hours.

Story points are tracked too — label any task with a point value, and Ensaria correlates your tracked hours against the points over time. After 30–60 days, you'll see your own ‘one point = N hours’ relationship, calibrated for your codebase.

What about deep-work blocks vs interruption-heavy days?

Ensaria tracks two kinds of time independently — focused (timer-started) and ambient. Your effective rate inside focused time vs ambient time is shown separately, so you can see whether the "10 hours billed today" was 8 + 2 of context switches, or 4 + 6.

Free for one active project. No card.

Pro unlocks unlimited projects, all-time history, and the deeper calibration insights.

Create account
EU-hosted · Export anytime · Delete anytime