Estimating software time and cost — without fantasy numbers

A real estimate needs locked scope. If scope floats, every price is a lie. Ask for three numbers: discovery, first-version build, and the first month of support. One “whole project” figure usually starts a fight. Write down uncertainty: gateways, data migration, missing content. KGSM consults to clarify scope, then contracts. Start from contact or web programming.

This guide — Estimating software time and cost — without fantasy numbers — is written from KGSM delivery work: scoped first versions, staged releases, and support after handoff.

Audience, risk, and how KGSM works

A manager who must give a board or partner a software budget and date and is tired of fantasy numbers

An estimate without scope means a floating date, endless change orders, and a fight over work that was never written down.

KGSM quotes three numbers: discovery, first-version build, and the first month of support. Integration and data uncertainty are written down.

Why one number for the whole system is a lie

A vendor who quotes one price for “website plus app plus accounting” puts the risk on you. Analysis, design, build, integrations, QA, go-live, and training each spend money differently. If version one is not one complete workflow, the delivery date is only the start of the next argument. KGSM ties the estimate to phases so you can buy phase one and decide phase two after real data. We do not hide uncertainty: if the other party’s gateway or API has no documentation, that line stays “conditional” in the quote. That honesty sells less in the first week and fights less in month six. Among three quotes with no scope, the cheapest is usually the one that later doubles. If an assumption fails, a change order makes sense; if it was never written, the change order means scope was never locked.

Ask for three separate numbers: discovery, version one, and the first month of support. A lump-sum quote without phases almost doubled after the payment gateway was connected.

How to freeze version-one scope before a price

Before you ask for a price, write one page: who the user is, which job they finish, which report must exist in week one, and which other system must connect. Separate admin roles from customer roles. Also write what is deliberately out so nobody later says it was “obviously included.” KGSM turns that page into an acceptance checklist. If you do not have the page, that work is a discovery workshop and should be priced apart, not buried inside the build. Your product owner must answer a design question within forty-eight hours; decision delay moves the date and that is not the build team’s fault. Copy, product photos, and business rules are yours. If content is missing, put a buffer in the estimate or tie the date to content delivery.

Shop content arrived late and the date looked like an engineering miss until content was tied in the contract. Write assumptions about integrations, content, and server access inside the estimate.

Write time with risk, not with a wish

A calendar date without a risk list is only a wish. Recurring risks on Iranian software projects, from KGSM’s work, include an incomplete gateway or eNamad account, messy spreadsheet data, late server access, an absent decision-maker, payment-rule changes, and a demand to launch web and app on the same day. Remove each from version one or give it an explicit day buffer. A demo every two or three weeks prevents late discovery; six months of silence then “delivery” is the expensive model. Count real-data testing inside build time, not after a launch party. Count training the same way. KGSM gives a firm date after scope is frozen, not on the first call. Ask for a phase-one window, not a promised day for the entire future system.

Define version-one acceptance before you sign. The decision-maker was travelling and two sprints waited only for approval.

How KGSM prices work and how you start

The KGSM model is explicit. An initial consult to understand workflow and roles is free or a short paid session so the estimate is not empty. Then a phased proposal arrives: remaining analysis if needed, first-version build, go-live, training, and a bug-fix window. Optional monthly support is separate so maintenance is not mixed with construction. Staged payment is tied to a testable demo, not a promise. Source code and server access should belong to the client; we write that in the contract. If the project is a website, use the programming service path on kgsm.ir; if it is an app, we keep the client estimate separate from the API. To start, send that one scope page or even a sample of your current file to contact. We quote after reading that page.

The client spreadsheet mixed date columns and migration was not priced; the project stalled. Name a product owner with a two-day response window in the contract.

Tie payment to a testable demo, not to a percentage of calendar time. A demand to launch web and app together pushed version one back six weeks.

The cheaper quote kept source on a personal account and leaving became expensive. Source code and the hosting panel should be in your name.

Write buffers against named risks, not as a hidden margin. A lump-sum quote without phases almost doubled after the payment gateway was connected.

Shop content arrived late and the date looked like an engineering miss until content was tied in the contract. Do not price phase two until version one produces real data.

Implementation checklist

• Ask for three separate numbers: discovery, version one, and the first month of support.
• Write assumptions about integrations, content, and server access inside the estimate.
• Define version-one acceptance before you sign.
• Name a product owner with a two-day response window in the contract.
• Tie payment to a testable demo, not to a percentage of calendar time.
• Source code and the hosting panel should be in your name.
• Write buffers against named risks, not as a hidden margin.
• Do not price phase two until version one produces real data.

Field scenario 1

A lump-sum quote without phases almost doubled after the payment gateway was connected.

Ask for three separate numbers: discovery, version one, and the first month of support.

Field scenario 2

Shop content arrived late and the date looked like an engineering miss until content was tied in the contract.

Write assumptions about integrations, content, and server access inside the estimate.

Field scenario 3

The decision-maker was travelling and two sprints waited only for approval.

Define version-one acceptance before you sign.

Field scenario 4

The client spreadsheet mixed date columns and migration was not priced; the project stalled.

Name a product owner with a two-day response window in the contract.

Field scenario 5

A demand to launch web and app together pushed version one back six weeks.

Tie payment to a testable demo, not to a percentage of calendar time.

Field scenario 6

The cheaper quote kept source on a personal account and leaving became expensive.

Source code and the hosting panel should be in your name.

Related KGSM pages

Continue with KGSM services: طراحی سایت, برنامه‌نویسی و توسعه نرم‌افزار. Related reading: پشتیبانی بعد از تحویل نرم‌افزار چه چیزی را پوشش می‌دهد؟. For a scoped estimate, use the contact form.

When you apply this on a live team, write it as an operating rule, not a slide: Ask for three separate numbers: discovery, version one, and the first month of support. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Write assumptions about integrations, content, and server access inside the estimate. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Define version-one acceptance before you sign. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Name a product owner with a two-day response window in the contract. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Tie payment to a testable demo, not to a percentage of calendar time. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Source code and the hosting panel should be in your name. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Write buffers against named risks, not as a hidden margin. Then assign an owner and a review date so the rule survives the first busy week.