I actually fell into that trap during my second development job, and it’s haunting me still.
I’ll add some context as I’ve seen many, many developers after me believing that this is wrongful and should be corrected.
I started as a regular Joe and soon became “promoted” to a mix of lead developers and business analysts. At some point, I had to deal with estimates, feature requirements, things like that.
As someone inexperienced and young, I kept sending my estimates for, what I believed to be, the entirety of the project to be worked upon. That went on for two or three projects in a row until I accidentally gained access to the final offer hanging in a shared folder.
The final quote was 8x – 10x larger than my estimate.
I thought it was a steal. I firmly believed that.
More importantly, we didn’t land 2 out of those 3 projects. I was confident it was purely due to the markup on my estimate.
All I thought about is how we could have sorted this within budget, or even with a 2x or 3x multiplier (as a safety net). Boy, I was wrong.
Fast-forward a few years, here’s why my misinformed and careless idea was not applicable in a real-world scenario.
- My math was probably wrong. Being less experienced, I couldn’t estimate all edge cases, extra fixes, additional requirements properly.
- I wouldn’t have developed that alone. Even if I worked as a lead developer, I would have pestered other peers in the dev team for help, extra debugging, support.
- Development is not the only portion of work that goes into a project. Presales negotiations, proposals, project management, QA, meetings, there’s a lot more that goes directly (or even indirectly) into a project.
- The initial discovery phase/proposal wasn’t billed. This had to be included somehow into the final proposal – and sometimes, it was taking over a couple of months in R&D.
- The business, as an organization, pays taxes, fees, office costs, and a lot more. Someone has to pay for it, right?
- Management salaries as well.
- Marketing, recruitment, sales, branding, PR – all of that brings business.
- Extra resources. A company can’t ensure that all of their team members will clock 100% billable time. Some would be much busier than others, which requires additional resources. Add that to holidays, vacations, sick leaves.
- Idle time. There are gaps between meetings, between projects, while waiting for requirements, feedback, assets, the list goes on. The fact that a project would take 3,000 hours doesn’t mean that you can complete it in 75 weeks (40 hours each) – it will probably take twice longer, or at least 50% extra.
All things considered (and some atop of that), the actual development time is a tiny fraction of the business expenses. There’s the “rainy days” buffer, the profit curve allowing a business to grow, additional costs and expenses for expansion, innovation or investment budget, and a lot more to that.
The business should have that buffer to survive during slow seasons or unexpected delays in payments, and everything in-between.
Sometimes, the revenue generated from a project does not directly translate into immediate profits due to various business expenses, investments, and debts that the company must manage.
Employees might not always be privy to these details, which can lead to misunderstandings about the company’s financial decisions.
A business won’t land a business without the brand, portfolio, combined experience, reputation on the market. That is developed over time and gets more and more valuable. And all processes in place are proven to work (for the most part) – unlike offloading this to a brand new team or a freelancer.
The numbers make sense—but usually, much, much later on.