Founder's Desk
Few things fill an engineering team with more trepidation than a request for a "ballpark estimate." The request usually arrives from management in a form like: "if we had to build a new e-commerce experience for selling furniture, in addition to our current clothing line, roughly how many engineers and how many weeks or months will you need?"
At this stage, not much more information is typically available, because the business is often trying to decide whether the project is even feasible based on the engineering team's answer. What follows from that answer, and how to give one without trapping your team, is what this piece walks through.
Why the request is dangerous
The business needs to make some level of commitment to external parties, clients, customers, or investors, before more resources can realistically be committed to a project. But only once resources are actually committed and the team starts digging into the requirement will the full extent of the work become clear. By that point, the "ballpark" qualifier attached to the original number is often quietly dropped, and the team finds itself held to a deadline that was based on genuinely partial information.
This is the structural bind at the heart of every ballpark estimate request, and it's worth naming explicitly rather than pretending it doesn't exist. Acknowledging the bind openly, with the stakeholder, is usually the first step toward defusing it.
The accuracy of your estimate is directly proportional to how much information can be made available to you and your team in the time you have. If necessary, request to suspend other work for the duration of the exercise, and schedule a series of long, focused sessions, an hour or two each, with the stakeholder who actually understands the requirement.
Prepare a specific list of questions in advance rather than improvising in the room. Good questions cover the critical user journeys end-to-end, expected scale in terms of users and volume, how ongoing data and content will be maintained, what admin or operational functions are needed beyond the core flow, and what platforms or devices need to be supported. Coming up with a genuinely useful list requires either prior domain knowledge or the help of someone in your organization who has it.
Turn uncertainty into documented assumptions
You will not get answers to every question during these sessions, and that's expected rather than a failure of the process. Rather than leaving those gaps as unspoken uncertainty, make reasonable, explicit assumptions and write them into the document you share back with stakeholders, so they can agree with each one or correct it directly, in writing, before work begins.
This single habit, writing assumptions down instead of carrying them silently in your head, is probably the single highest-leverage practice in this entire process. It turns invisible risk into a visible, negotiable line item.
Break work into phases
Not all requirements carry equal priority to the business, even though they may feel equally important from an engineering perspective. Once you understand what actually matters most to stakeholders, and why, you can break the work into phases that can be estimated separately, rather than treating everything as one large, undifferentiated project with a single number attached to it.
This phased approach does something else valuable: it gives the business an early opportunity to reconsider scope once real numbers are attached to each phase, rather than discovering the true cost only after committing to the whole thing.
What this is really about
The underlying discipline here isn't really about estimation techniques. It's about converting an inherently uncertain request into a shared, written understanding between engineering and the business, one that both sides can point back to later. Estimates drift. Written agreements about scope and assumptions are much harder to quietly reinterpret.
