A client came to me with a simple requirement:

“I want a Microsoft 365 clone.”

The easiest thing to do would have been to throw out a number and say, “We can build it for ₹X in Y weeks.”

I didn't.

Instead, I treated it as a commercial estimation problem.

The objective was to move from an ambiguous requirement to a signed-off MVP, defensible effort estimate, development cost, commercial price, and change-control mechanism.

The final approved MVP quotation came to ₹28,09,669, with a delivery planning window of 10–12 calendar weeks.

Here's how the journey worked.

---

1. Don't Price a One-Line Requirement

When a customer says:

“I want a clone.”

You don't yet know:

• What features are required?
• What's actually part of the MVP?
• What platforms are required?
• Which integrations are needed?
• What security requirements exist?
• What are the expected user volumes?
• What is explicitly out of scope?
• Who owns infrastructure costs?
• What are the acceptance criteria?

So the first question isn't:

“How much should I quote?”

It's:

“What exactly are we agreeing to build?”

---

2. Start With Requirements & Analysis

The first commercial phase was Requirements & Analysis.

Instead of jumping directly into development pricing, we created a requirements baseline covering the MVP scope, user journeys, functional requirements, user stories, acceptance criteria, NFRs, integrations, business rules, roles, risks, assumptions, dependencies and traceability.

The requirements pack was explicitly designed to create a controlled MVP scope and a development-ready requirements baseline. Detailed UI/UX design, coding, production architecture and legal certification were excluded from this phase.

This is an important commercial principle:

When the scope is uncertain, sell certainty before selling development.

---

3. Use WBS to Break the Requirement Down

The next step was creating a Work Breakdown Structure (WBS).

Instead of estimating:

“Microsoft 365 clone = ₹X”

we break the project into manageable work packages.

For example:

Project
│
├── Requirements & Analysis
│
├── UI/UX
│
├── Backend Development
│   ├── Authentication
│   ├── User Management
│   ├── Core Business Logic
│   └── Integrations
│
├── Application Development
│
├── QA
│
├── DevOps
│
└── Project Management

Now every work package can be estimated independently.

That makes the final quotation traceable.

---

4. Don't Ask for One Number — Use Three-Point Estimation

This is where PERT becomes useful.

Instead of asking a team member:

“How many hours will this take?”

ask for:

• Optimistic
• Most Likely
• Pessimistic

For example:

Estimate	Hours
Optimistic	48
Most Likely	60
Pessimistic	90

Then calculate:

PERT Expected Effort

(O + 4M + P) / 6

So:

(48 + 4 × 60 + 90) / 6
= 63 hours

The PERT expected effort is therefore:

63 hours

This is much more defensible than simply saying:

“I think it will take 60 hours.”

---

5. PERT Is Not the Same as the Customer Commitment

This was one of the most important lessons from the exercise.

The 63 hours is the statistical expected effort.

It doesn't necessarily have to be the number you commercially commit to the customer.

For the requirements phase, the commercial commitment was:

70 hours

So:

PERT Expected Effort = 63 hours

Customer Commitment = 70 hours

Commercial Buffer = 7 hours

That distinction matters.

PERT = estimation metric

Customer commitment = commercial decision

They serve different purposes.

---

6. Charge for Discovery / Requirements Separately

Another important lesson:

If the customer has only provided a vague requirement, don't immediately commit to the entire development project.

A better model is:

Phase 1 — Discovery / Requirements

Customer pays for:

• Requirements analysis
• MVP definition
• FRD / requirements baseline
• User journeys
• Functional requirements
• Acceptance criteria
• NFRs
• Integration analysis
• Business rules
• Traceability

Once the customer approves the baseline, you have a much stronger foundation for pricing development.

---

7. Customer Review Will Change Things

And it did.

During the requirements review, the customer identified gaps and requested clarification around:

• MVP scope
• UPI / payment capabilities
• KYC
• Payment-provider integration
• Financial business rules
• Open decisions
• BA effort baseline

Instead of simply absorbing these changes informally, we treated them as a formal Change Request: CR-MVP-001.

The CR required an impact assessment before development scope was assumed.

This is critical.

A customer review is not automatically free scope expansion.

You assess the impact first.

---

8. Re-Baseline Before Development

The BA assessed the change request and identified potential impact across:

• MVP scope
• Functional requirements
• User journeys
• User stories
• Integrations
• Business rules
• NFRs
• Roles and permissions
• Traceability
• Development estimation
• Timeline

The customer then approved the revised MVP Requirements Baseline V1.1.

At that point, the requirements became the baseline for development estimation and planning.

This creates an important project gate:

Customer Requirement
        ↓
Requirements Analysis
        ↓
WBS
        ↓
PERT Estimation
        ↓
Requirements Baseline
        ↓
Customer Sign-off
        ↓
Development Estimation
        ↓
Cost Calculation
        ↓
Customer Quotation

---

9. Only Now Calculate the Development Cost

Once the scope is signed off, estimate the development workstream by workstream.

The approved commercial quotation ultimately contained:

WBS	Workstream	Quoted Amount
1.2	Complete UI/UX using Wireframe	₹3,76,750
1.3	Senior Full Stack Development	₹9,56,250
1.4	Full Stack Development	₹7,68,752
1.5	QA Assessment	₹2,92,500
1.6	DevOps and Infra	₹1,19,167
1.7	Project Management	₹2,96,250
	Final Total	₹28,09,669

Notice something important:

Requirements & Analysis isn't included in this development quotation.

Why?

Because it was already completed separately.

The commercial document explicitly excludes WBS 1.1 — MVP Requirements & Analysis because that phase had already been completed.

---

10. Separate Internal Cost From Customer Price

This is another fundamental pricing principle.

You need to distinguish between:

Internal Cost

What it costs your organization to deliver the project.

Customer Price

What you charge the customer.

Profit

Customer Price − Internal Cost

Margin

Profit ÷ Customer Price

Don't confuse markup with margin.

If your internal cost is ₹100:

20% markup

₹100 × 1.20 = ₹120

Your margin is only:

₹20 / ₹120 = 16.67%

For a 20% margin:

₹100 / (1 − 20%)
= ₹125

That distinction becomes very important when negotiating large software projects.

---

11. Client-Borne Costs Must Be Separated

Another lesson from this project was understanding who pays for what.

The approved quotation explicitly states that:

• Cloud hosting/infrastructure is paid directly by the client.
• Payment-provider charges are paid by the client.
• KYC-provider charges are paid by the client.
• Notification-provider charges are paid by the client.
• Other third-party usage charges are excluded.
• Taxes, where applicable, are additional.

That means these aren't part of our internal delivery cost.

But that does not mean the related work disappears.

For example:

DevOps engineering effort → our cost

AWS/Azure consumption → client's cost

Similarly:

KYC integration development → our cost

KYC provider usage charges → client's cost

That separation prevents accidental double charging and makes the commercial proposal much cleaner.

---

12. Don't Forget Tooling

Internal tooling is different from client infrastructure.

For example:

• GitHub/GitLab
• IDEs
• Postman
• Docker
• Figma
• Project management tools
• Test management tools

If these are company-borne costs, include a reasonable project tooling allowance.

But don't allocate the same shared tool cost to every developer row.

Otherwise you will double-count.

---

13. Protect the Project With Change Control

Once the customer signs the requirements baseline, the baseline becomes your commercial reference point.

The approved quotation explicitly states that any material scope expansion beyond the signed-off MVP baseline will be separately assessed and quoted.

This gives you a simple rule:

Baseline scope = included

New material scope = impact assessment + change request + commercial approval

That's how you avoid the classic:

“It's just one small feature.”

followed by 25 additional features. 😄

---

14. Fixed Price Doesn't Mean Guessing

Once the requirements are sufficiently defined, you can offer a fixed development price.

But the fixed price should be backed by:

Approved Scope
      ↓
WBS
      ↓
Resource Plan
      ↓
Three-Point Estimates
      ↓
PERT
      ↓
Internal Cost
      ↓
Risk / Contingency
      ↓
Target Margin
      ↓
Customer Price

The customer sees a fixed commercial commitment.

Behind that fixed price is a structured estimation model.

---

15. The Final Commercial Result

The final MVP quotation was approved at:

₹28,09,669

with an overall delivery planning window of approximately:

10–12 calendar weeks

subject to dependencies such as provider access, client decisions, UI feedback and UAT.

The customer formally approved the quotation and authorized the project to proceed against the signed-off MVP requirements baseline.

---

16. The Complete Pricing Strategy

The entire approach can be summarized as:

Customer says:
"I want a clone."
        ↓
Don't guess the price
        ↓
Sell / conduct Discovery
        ↓
Build Requirements Baseline
        ↓
Create WBS
        ↓
Estimate O / M / P
        ↓
Calculate PERT
        ↓
Set Commercial Commitment
        ↓
Customer Review
        ↓
Handle Change Requests
        ↓
Customer Sign-off
        ↓
Freeze Requirements
        ↓
Build Development WBS
        ↓
Estimate Development Effort
        ↓
Calculate Internal Cost
        ↓
Add Contingency / Risk
        ↓
Apply Target Margin
        ↓
Create Customer Quotation
        ↓
Contract + Change Control
        ↓
Execute

---

17. The Five Numbers You Should Never Confuse

When pricing software, keep these separate:

Number	Meaning
PERT Effort	Expected effort based on uncertainty
Internal Cost	What it costs your company
Commercial Commitment	What you commit to deliver for the agreed scope
Customer Price	What you charge
Profit	Customer Price − Internal Cost

Once you understand those five numbers, software pricing becomes much less mysterious.

---

Final Takeaway

The biggest mistake in software pricing isn't necessarily getting the arithmetic wrong.

It's pricing before understanding what you're actually selling.

A one-line requirement like:

“I want a Microsoft 365 clone.”

doesn't contain enough information to responsibly produce a fixed development price.

The professional approach is:

Define → Decompose → Estimate → Validate → Baseline → Cost → Price → Contract → Control Change

And that's the difference between guessing a project price and building a defensible commercial estimate.

The Excel template used for this approach covers the same concepts: WBS estimation, three-point/PERT effort, resource costing, contingency, margin, negotiation boundaries and change-request pricing.