Skip to content
Aleksei Mikhailov Available
RU EN

Estimation from a spec: how cost and timeline are calculated (and where teams usually get misled)

Queries like “software cost estimate”, “project timeline estimate”, or “estimate from requirements” are not about one number. They are about risk management: you are buying a predictable outcome, not “some code”.

Below is what a real estimate looks like, what must be present in a spec (or even a short brief), and how to tell estimation from guessing.

1) Why “one number” almost always hurts

If someone says: “2 weeks, costs N” without:

  • a module breakdown,
  • assumptions,
  • risks,
  • acceptance criteria,

that’s not an estimate. That’s a sales promise.

Reality catches up later: “not included”, “turned out harder”, “we need roles/permissions”, “the integration is unstable”, “design isn’t ready”.

2) What you need to estimate (minimum)

2.1. Scope: what is in the first version (MVP)

Without scope, the estimate becomes elastic. A usable spec always contains:

  • “in scope”
  • “out of scope”

2.2. Scenarios (user stories) and acceptance criteria

Estimation is calculated from scenarios, not from “feature ideas”.

Example:

  • “User buys a subscription” is not one button. It’s a scenario with payments, webhooks, statuses, failures, access control, and edge cases.

2.3. Integrations

“Connect CRM/payments/delivery” can be:

  • 2 hours, if SDK is solid and events are clear
  • 2 weeks, if the API is flaky and you need limits, retries, idempotency, queues

3) What timelines are made of (work map)

A real estimate is decomposed into blocks:

  1. Discovery / requirement clarification (sometimes 0.5-3 days)
  2. Architecture and data model (especially for web apps/bots with admin)
  3. Backend/API (endpoints, auth, integrations)
  4. Frontend (screens, states, forms, validation)
  5. Admin panel (often a hidden 30-50% of the project)
  6. Testing (at least smoke + critical scenarios)
  7. Deployment/infra (Docker, environments, secrets)
  8. Monitoring/logs (so you don’t debug blind)
  9. Acceptance by criteria (acceptance criteria)

Even if you simplify parts, they must be explicitly marked.

4) What a “good” estimate looks like (deliverable format)

4.1. Module table

For example:

  • Authentication/roles - X-Y days
  • Payments - X-Y days
  • Telegram UI - X-Y days
  • Admin panel - X-Y days

Why a range? Because an honest estimator exposes uncertainty and explains it.

4.2. Assumptions list

Examples:

  • “Design is ready and won’t change”
  • “Payment provider is YooKassa/Stripe, access is granted”
  • “Initial load up to 10k users/month”

4.3. Risks list

Examples:

  • “External API may fail -> retries/queue required”
  • “Roles/permissions are more complex -> admin panel scope grows”

4.4. Release plan

Good practice: 2-4 short releases instead of one big-bang delivery.

5) Typical “hidden” parts that break timelines

  1. Admin panel (manage content/pricing/users)
  2. Access control (RBAC, audit log)
  3. Errors and edge cases (payment canceled, double click, network loss)
  4. Data migration (if moving from Excel/legacy)
  5. Observability (logs, metrics, alerts)

If those are not in the estimate, they’ll reappear later as “extra work”.

6) A quick checklist before estimation

If you don’t have a full spec yet, I usually ask 12 questions:

  1. Who is the user and what roles exist?
  2. What does the main “success” scenario look like?
  3. What integrations exist and who provides access?
  4. Do we need an admin panel? What is managed there?
  5. Do you have design? In what form?
  6. Platforms: web/iOS/Android/Telegram?
  7. Do we need authentication? Which kind?
  8. Notifications: email/sms/push/Telegram?
  9. Reports/exports?
  10. Performance/load requirements?
  11. What is must-have in MVP vs later?
  12. How do we accept work (acceptance criteria)?

7) How I can help

  • Timeline/cost estimation from your spec (with risks and assumptions)
  • Spec “for estimation”: I convert an idea into testable requirements
  • Roadmap: releases, priorities, risks

If you want, I can estimate timeline and budget as a range (assumptions + risks) and map it into a realistic release plan. Send 3 things: MVP goal; critical flows/integrations; what you already have (design/spec/code).

Free consultation