Strategy decision - hours vs. man-days

It is psychology, not just math

When you create a new project in devtimate, the first decision you make is choosing the Time unit: Hours (h) or Man-days (MD).

Many project managers click this randomly. That is a mistake. The unit you choose changes how the client perceives the scale and cost of the project.

In this lesson, we will cover the strategy behind this choice so you can maximize your conversion rate.

What you’ll learn

• The psychology of numbers: Why “100 MD” sells better than “800 h”.
• The estimation lifecycle: Why you should start with MDs and finish with Hours.
• When to use hours: Best for smaller scopes and T&M.
• When to use man-days: Best for larger projects and Fixed Price.

---

The psychology of large numbers

Clients get scared easily. If they see 1,000 hours, their brain immediately thinks: “That is a lot of time. That is expensive. Are they slow?”

If they see 125 man-days, the scope feels manageable. It represents a few months of work for a developer, which sounds reasonable for a big platform.

The value is the same, but the feeling is different.

The estimation lifecycle

Experienced agencies know that estimation evolves as you get closer to closing the deal.

1. The “Ballpark” stage: When requirements are vague, speed is key.

   • For large projects: Use Man-days (e.g., “Payment module: 3-5 MD”). It keeps the conversation on value, not minutes.
   • For small projects: Use Hours (e.g., “Landing page: 40-60 h”). For small scopes, days can feel too abstract, while hours show you know exactly what to do.

2. The “Contract” stage: Once the ballpark is approved, you need precision. Now you usually switch to Hours to detail every task. This protects your margin and gives your developers a clear roadmap for delivery.

Strategy A: When to use hours (h)

Use hours when you want to show transparency and precision.

• Final scope: When you are ready to sign the contract and need strict boundaries.
• Small projects: If a project is 40-100 hours, showing it in man-days (5-12 MD) might make it look too small or trivial.
• Maintenance & retainers: When you bill for specific tasks or bug fixes.

The vibe: “We are precise, and we account for every detail.”

Strategy B: When to use man-days (MD)

Use man-days when you want to sell the outcome and value.

• Early estimates (Large scale): When requirements are high-level and you want to avoid lying with fake precision.
• Large projects: For a SaaS platform estimated at 2000+ hours, man-days make the number digestible.
• Discovery phases: Workshops are usually sold in days (e.g., “3-day workshop”), not hours.

The vibe: “We are partners delivering a solution, not freelancers clocking in.”

Configuring it in devtimate

You set this preference when creating a new project.

1. Click New project.
2. Look for the Time unit toggle.
3. Select Hours or Man-days.

Important: In devtimate, Man-days are a distinct unit. You don’t need to define how many hours are in a day here. You simply estimate in days (e.g., 1 MD, 2.5 MD). Later, when creating a proposal, you will define the Daily Rate (price per 1 MD) to calculate the final budget.

Pro tips

“Sell features, not tasks” According to sales psychology, clients do not think in “Backend tasks” or “API endpoints.” They think in Features. Using Man-days naturally forces you to group micro-tasks into meaningful business features (e.g., “5 MD for Payment Module” instead of “4h for API integration”). This aligns your estimate with the client’s vision and increases the chance of approval.

Key takeaways:

• Start high-level: Use Man-days for big ballparks, Hours for small ones.
• Get granular later: Switch to detailed Hours for final contracts to secure your margin.
• Focus on value: Man-days shift the conversation from “clock-watching” to “delivery.”

FAQ: Why no story points?

You might notice that devtimate does not support Story Points. This is a deliberate product decision.

Story Points are for delivery, not for sales. Story points are a relative measure of complexity used by Scrum teams to track internal velocity. They do not translate directly to money or deadlines in a contract. Clients pay for time (delivery date) and budget (cost), not abstract complexity points.

Using Story Points in a proposal creates confusion and contractual risks. devtimate is designed to handle the commercial side of the project (Proposal & Contract), while tools like Jira should handle the delivery side (Sprints & Velocity).

Next steps

Now that you have chosen your time unit, we need to talk about Risk.

In the next lesson, we will tackle one of the most powerful features in devtimate: Min/Max Ranges. You will learn why giving a single number estimate is dangerous and how ranges protect your profit margin.