Contact us

How to Estimate Time for Projects You’ve Never Done Before

by Arif Ikhsanudin, Backend Developer

Estimating a project you’ve never tackled can feel like guessing the weather on Mars. But with the right approach, you can make surprisingly accurate predictions.

Start with the Known Unknowns

The first step is to list everything you know and don’t know about the project.

  • Break the project into smaller tasks, even if you aren’t sure how long each will take.
  • Identify dependencies and potential blockers.
  • Flag areas where you have little to no experience.

Acknowledging uncertainty is better than pretending you know it all.

Use Analogies and Past Experience

Even if the project is new, similar projects can guide your estimates.

  • Think of past tasks that share similarities in complexity or scope.
  • Ask colleagues or peers who have done something similar.
  • Don’t copy numbers blindly—adjust for differences in scale or unknowns.

An educated guess beats a wild guess every time.

Break It Down and Add Buffers

Small tasks are easier to estimate than the whole project.

  • Estimate each task individually.
  • Add a buffer for learning, interruptions, or mistakes.
  • Consider multiplying your initial total by 1.3–1.5 if it’s completely new territory.

Buffers are not padding—they’re sanity insurance.

Validate As You Go

Once the project starts, check your estimates against reality.

  • Track time spent on each task.
  • Adjust future estimates based on what you’ve learned.
  • Communicate changes early if deadlines will shift.

Learning from real data is the fastest way to improve your estimates.

Communicate Uncertainty Clearly

Clients or managers often fear vague timelines. Be transparent.

  • Explain which parts are uncertain and why.
  • Offer ranges instead of single numbers when possible.
  • Show confidence in the process, even if the timeline isn’t perfect.

Being upfront about uncertainty builds trust and reduces panic later.

Estimating something new is part art, part science—but with the right mindset, you can predict with surprising accuracy.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Say Hej

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

Spring Boot API Rate Limiting — rack-attack Equivalent in Java

Rate limiting protects APIs from abuse, enforces fair usage, and prevents accidental runaway clients from taking down infrastructure. Here is how to implement per-user, per-IP, and per-endpoint rate limiting in Spring Boot with Bucket4j and Redis.

Read more

Stop Writing Loops When SQL Aggregations Can Do the Work

Fetching rows and aggregating in application code is slower, uses more memory, and is harder to maintain than letting the database aggregate at the source — yet this pattern persists because developers reach for familiar imperative constructs instead of SQL aggregations.

Read more

The Engineering Practices I Advocate for on Every Project I Join

Some practices are context-dependent — they make sense for certain team sizes, certain stages, certain domains. Others are close to universal. Here's the short list I push for regardless of where I land.

Read more

Git Is Not Just a Backup Tool. Here Is What It Actually Is.

Most developers use Git as a glorified save button. Understanding what Git actually models — a directed acyclic graph of snapshots — changes how you use every command.

Read more