Process Spotlight: How We Create Engineering Estimates

Estimating a new website project may never be perfectly predictable, but it doesn’t have to feel like a shot in the dark.

At Mostly Serious, we treat estimates as the product of real data—not just gut feel. Over time, we’ve refined an engineering estimating process that’s more data‑driven, transparent, and reliable for both our team and our clients.

This Process Spotlight takes a behind‑the‑scenes look at that system: how we collect time data, build a thorough task list, and apply simple formulas so estimates stay realistic even when projects are complex.

The foundation: collecting and analyzing data

Reliable estimates depend on reliable data—specifically, the time our team tracks and categorizes over the life of a project.

We collect and analyze the time we spend to spot patterns, learn from past work, and inform future estimates. When we look back at a project, we’re asking questions like:

• Which modules took longer or shorter to develop than expected?
• How much time was spent on revisions versus initial development?
• How much time was required for multi‑developer collaboration, and how does that compare to solo work?

Understanding the actual results of past projects is key; it helps us calibrate expectations instead of guessing.

Those insights feed directly into our estimating formulas, making it easier to repeat past successes and avoid making the same mistake twice.

Creating a task list

Our estimates start as a comprehensive list of every module, feature, and task required to build a website from the ground up.

To speed that up, we maintain a robust template for estimating new Craft CMS websites. The real spreadsheet is more granular than we can show here, but it’s broken into familiar sections:

• Frontend
• Backend
• Features
• QA
• Meetings
• Account
• Optional

Frontend development

On most projects, frontend development includes work like:

• Creating the base layout and all global, single‑use modules (like the header and footer).
• Implementing the repeatable modules from which pages are built.
• Building page‑specific modules that only appear in certain contexts.
• Creating shared components—smaller parts of a module, such as buttons or icons—that show up across the site.

Clients often also leverage our team’s brand design, copywriting, SEO, and content population services, but we usually treat those as separate scopes outside of the engineering estimate.

With a solid task‑list framework in place, our engineers review the UI in depth to confirm nothing has been missed before we start assigning time.

Applying a formula to each task

Once we’ve captured all of the tasks, we estimate each one using a formula informed by the data we’ve collected from past projects.

In practice, our estimates rely on two simple approaches:

• A three‑point formula for engineering tasks.
• A percentage‑based formula for relative tasks (like QA, meetings, and account management).

Let’s take a closer look at each.

Three‑point formula (for engineering tasks)

Engineering tasks use three data points and a weighted average to produce an estimate that’s both realistic and honest about uncertainty.

A single data point—for example, “this callout module will take six hours”—is sometimes fine for small, predictable work, but it doesn’t leave much room if development moves slower or faster than expected.

Two data points (a low and a high estimate) are better, but we’ve found three is often the sweet spot:

• An optimistic estimate—if everything goes smoothly and we move faster than expected.
• A realistic estimate—what we think is most likely to happen.
• A pessimistic estimate—when unexpected complications show up and slow things down.

From there, we give extra weight to the realistic estimate, since in our experience it’s the most likely outcome.

One common pattern is a weighted‑average formula that looks like this:

This approach has proven intuitive for our team and helps us forecast engineering time to a higher degree of accuracy.

On larger projects, we sometimes have multiple developers estimate the same task independently and compare their results, which helps surface hidden assumptions before work begins.

Percentage (for relative tasks)

Not every line item has a clean “hours per module” relationship. Relative tasks—developer meetings, QA revisions, account management, and similar work—tend to scale with the overall size of the build.

For those tasks, we estimate using a simple percentage of the total initial development time. The exact percentage comes from the averages we’ve calculated across similar projects.

For example, if historical data shows that QA revisions usually account for around 15% of total engineering time on comparable builds, we’ll apply that ratio up front instead of guessing.

We also adjust our percentages based on how many developers will be working on the project simultaneously, since coordination overhead tends to increase with team size.

A live example

In our internal estimating spreadsheet, each module or task gets its own row with optimistic, realistic, and pessimistic estimates, followed by percentage‑based line items for things like meetings and QA.

As the sheet fills out, we get a clear picture of the total expected effort, plus how much of that effort is dedicated to pure engineering versus supporting activities.

We revisit these sheets during and after projects to compare expectations with reality and refine our formulas over time.

Making it part of our process

For us, good estimates aren’t a one‑off exercise—they’re part of a continuous loop: collect, estimate, review, repeat.

At the end of each project, we schedule a team review (post‑mortem) to analyze how time was actually spent, what surprised us, and where our original assumptions held up.

We maintain a master spreadsheet that tracks engineering projects over several years, and we use it to periodically recalculate and update our formulas.

That discipline helps us spot trends early—like modules that are consistently under‑estimated or new patterns in collaboration time—so we can adjust before they turn into problems.

Transparent estimates lead to better conversations

By regularly collecting data and developing reliable formulas, we’ve been able to estimate projects with a high level of accuracy.

Clients appreciate the transparency and the way we can talk through tradeoffs in hours instead of hand‑wavy ranges, and our team feels supported by expectations that line up with reality.

De‑mystifying the estimating process also sparks better conversations about what features matter most. When everyone can see how the estimate is built, it’s easier to move scope up or down with confidence.

If you’re planning a new website or a significant rebuild and want to talk through how this approach could apply to your project, we’d love to hear from you.

When you’re ready to explore the next steps, get in touch with our team.