Roughly / Approximately

• Casual estimate → roughly · around · about · give or take
• Formal estimate → approximately · in the region of · on the order of
• Vague estimate → a ballpark of · somewhere between · in the low hundreds
• Precise claim → exactly · precisely · to the day

Compare three messages to a client:

• "It'll take two days." → a commitment. Day three is a failure.
• "Roughly two days." → an estimate. Day three is within tolerance.
• "Two to three days." → an explicit range. Day three is expected.

Nothing about your actual work has changed. What changed is what the client will call it when it happens.

The test: would I be embarrassed if this number turned out wrong? If yes, hedge it.

Hedging is not weakness. English-speaking clients read unhedged estimates from developers as either inexperience or overconfidence — because everyone knows software estimates are guesses. The hedge signals that you know it too.

• "Roughly two days."
• "Roughly 300 lines of code."
• "It's roughly a 40% improvement."
• "Roughly half the users are on mobile."
• "Roughly speaking, the API does three things."

• "Approximately 12 hours of work."
• "The dataset contains approximately 40,000 rows."
• "Delivery is approximately three weeks from signature."
• "Approximately 8% of requests time out."

Approximately in casual speech sounds stiff — "approximately two beers" is a joke. Roughly in a formal contract looks careless.

The two words mean the same thing. What differs is the room they belong in.

• ballpark — a wide, non-binding guess. "Ballpark, a week." (noun-ish: "give me a ballpark")
• somewhere around / somewhere in the region of — deliberately loose. "Somewhere around ten grand."
• roughly / around / about — the everyday default. "About two days."
• approximately — the formal default. "Approximately 48 hours."
• give or take — attaches a tolerance after the number. "Two days, give or take."
• or so — casual, follows the number. "A week or so."
• just over / just under — you know the real figure, you're rounding. "Just under 5,000."
• exactly / precisely — full commitment. "Exactly 40 hours."

❌ "roughly approximately two days" · ❌ "about around ten." One hedge per number.

❌ "That's approximately what I meant." → ✅ "That's roughly what I meant."

Roughly also means violently, harshly. "He grabbed it roughly."

Context separates them completely — nobody misreads "roughly two days" — but it explains why rough the adjective doesn't mean approximate in most positions:

• "a rough estimate" ✅ (fixed phrase — approximate)
• "a rough draft" ✅ (unfinished)
• "a rough number" ✅
• "a rough person" → unpleasant, not approximate

"This will take 14.5 hours" invites the question how do you know that? — and you don't. Precision you can't justify undermines you.

• ❌ "Approximately 14.5 hours." → the hedge and the decimal contradict each other.
• ✅ "Roughly 15 hours." → honest about the resolution.
• ✅ "Somewhere between 12 and 18 hours." → most honest of all.

Match the roundness of the number to the confidence you have. Round numbers signal estimates; specific numbers signal measurements. Mixing them confuses the client about which one you're giving them.

• "Two to three days."
• "Somewhere between one and two weeks."
• "Three days at best, a week if the API fights back."
• "Call it four days, five if the data's messy."

Give the range, then name the variable that decides it. "Two days if the schema is clean, four if I have to write migrations." Now the client understands the estimate instead of just receiving it.

• "Roughly two days for the report logic, assuming the spec doesn't change."
• "Approximately 20 hours across the two tools."
• "That's a ballpark — I'll firm it up once I've seen the data."
• "Three weeks, give or take, depending on how fast feedback comes back."
• "Roughly 70% done on the first milestone."
• "I'd say somewhere in the region of $4,000 for the full scope."

• "Ballpark, it's about a week — I'll confirm once I've read the existing code."
• "Roughly two days, but that assumes the API behaves as documented."
• "Approximately three weeks from kickoff, subject to review cycles."
• "That's a rough estimate; happy to break it down by task if useful."

Notice the pattern: hedge + the assumption behind it. The hedge alone can sound evasive. The hedge plus the condition sounds like someone who has actually thought about the problem.

• "The endpoint takes roughly 200ms."
• "Approximately 5% of the rows are malformed."
• "It's roughly O(n log n) in practice."
• "The bundle is just under 400kb."
• "Roughly speaking, the worker polls, transforms, and writes."
• "That's a rough draft of the schema — nothing's final."
• "Give or take a few edge cases, the two functions are equivalent."

• "It's roughly twenty minutes on foot."
• "The flat's about 60 square metres."
• "Rent's around 500 a month, give or take utilities."
• "I sleep roughly seven hours."
• "There were, what, thirty people? Approximately." (spoken, slightly ironic)

📏 A ruler with no fine markings. You can read the centimetres but not the millimetres. That's roughly — a real measurement, just at lower resolution. The number is honest; the precision is not claimed.

Presumably / Admittedly · Apparently · Actually / Currently / Eventually. Not written yet: ideally / realistically.

Which one undermines itself?

• ❌ "Roughly 15 hours." — fine; round number, honest resolution.
• ✅ (undermines itself) "Approximately 14.5 hours." — the decimal claims precision the hedge denies.
• ❌ "Somewhere between 12 and 18 hours." — fine, and the most honest of the three.

Which is the strongest client message?

• ❌ "I think maybe around two days or so?" — stacked hedges; now they doubt you.
• ❌ "Two days." — an unintended promise.
• ✅ "Roughly two days, assuming the API behaves as documented." — one hedge plus the assumption behind it.

1. approximately — formal written register; roughly is too casual for a proposal.
2. roughly — the non-numerical sense. Approximately can't modify what I meant.
3. give or take — the tolerance that follows a number.
4. ballpark — a wide, explicitly non-binding first guess.