Turning estimation guesswork into a calibrated tool
How I built an app that estimates DTP effort from the source files, and calibrated it against real jobs until the numbers matched reality.
This case study describes real methodology and work process, without exposing documents, clients, or specific data from any project.
01
Context
Every DTP job starts with a question: how many hours will this take? The answer drives quotes, planning and deadlines, but it was based on general guidelines and experience. The same document could be estimated very differently depending on who looked at it, and nobody checked afterwards how close the estimate had been.
02
My role and goal
I set out to build a tool that reads the source file and produces a consistent, explainable estimate, using Claude as a development assistant. My role was the domain expert: deciding what drives DTP effort, and how much each factor weighs.
03
Process
Defining what drives effort. Pages, tables, images with text, charts that need to be rebuilt, form fields, fonts, the file format and the type of service. I separated pre-translation work (preparing the file for the CAT tool) from post-translation work (formatting the translated file).
Building the analyzer. The app reads PDF, Word, PowerPoint and InDesign (IDML) files, detects those elements automatically and lists what needs a human check, such as images that may contain text or fonts that aren't installed.
Calibrating against real jobs. After each real job, I compared the estimate with the hours it actually took and adjusted the rules. Each change got a version number and a note explaining why. For example, small icons and logos stopped counting as images to prepare, and charts to rebuild went from 15 to 20 minutes after a real report showed the difference.
Separate rules per service. Accessibility work and interactive PDF forms behave differently from standard formatting, so they got their own rules (for forms, effort depends on the number of fields, not on the client).
04
Key decisions
- Explainable over clever. Every hour in the estimate can be traced to a rule and a detected element.
- Real data decides. A rule only changes when a real job shows it was wrong.
- Record the misses, not just the hits. Long Word documents with many layout tables were still underestimated, and that became an open question to fix with more data, not something to hide.
05
Final solution
An estimation app that analyzes the source files, breaks down pre- and post-translation hours, adds a safety margin and exports a clean PDF estimate. The calibrated rules were also written back into the team's estimation guidelines.
06
Results and learning
On calibrated job types, estimates now land close to the real hours: a 28-slide deck estimated at about 2 h for a 2 h budget, a 33-page report at about 4.8 h for roughly 5 h of real work.
The biggest lesson: a good estimate isn't a formula you write once, it's a loop. Estimate, measure, adjust, and write down why.