Can you ask them at all?
Many, many companies do not allow you to talk to the developers directly. You have an account manager that you talk to, and they usually handle all the communication, forward questions etc.
While this may make a lot of sense, talking to your account manager exclusively can be a big problem. They are usually much less technical than developers, and there is a big risk (or, rather, a certainty) that a miscommunication will occur.
In a world where details matter, you don’t want that. Managers are good at managing, scheduling, and making sure that things are done (although systems and processes do a much better job at that). Developers are good at coding and understanding complex issues. Talk to them directly when you can, make them tell you how they understood your issue, and make sure that nobody is slowing down the communication between you and them.
Don’t bother them with the organizational things - most developers aren’t good at that. However, if it’s tech you need them to understand (and you always do), just talk directly.
If a company does not let you do that, it’s a red flag in my book. It most likely means that they do not have a team of their own, or that they are working through layers of intermediaries. Perhaps developers can’t speak your language. In other words, their kitchen is dirty, and they don’t want you to see it.
But, let’s assume you can talk to them directly. What would you ask?
How do you know it will take that much time?
Most disputes with development companies start around estimates. Why did you say it would take 8h if it took 30? Why do you want 10 hours for something that will take a 20 minute action?
Depending on the contract between you and the developers they can do things for as much time as it takes, while providing reasonable estimates (non-binding estimates, also known as time and materials, or T&M). They can also provide a fixed quote and charge you that, never mind how much time it actually took.
There are other approaches, such as a monthly budget, retainers, target cost contracts, etc. However, most of them boil down to paying for things based on time, which is what they are selling you.
In most of these cases, they provide estimates. That is to say, they tell you how much they think things will take, which is also how much you will have to pay for those things.
The problem with this is that humans are notoriously bad at estimating complex systems. Unforeseen interactions, changes in libraries, systems, platforms and development tools, as well as simply doing things for the first time make estimates in software extremely hard.
There are people who believe that estimates are so bad that they should just go away: the #NoEstimates movement is a good example of that.
However, if you do use estimates, there are objectively bad and good ways to do them. When people actually visualise the steps necessary for completing a task, break them down into smaller chunks and estimate those, estimates get to be better statistically. Applying one of the many statistical methods for software estimates (at Mementia, we like this one).
Or you can just spitball. Which is what most people do. Yes, most. Most of the time, due to the fact that they are usually not paid for estimating a task, developers just rush through it, give a too large or a too small figure, and get on with their life.
If you continually ask them how they came up with that figure, it tells them that 1) you are interested in the estimate accuracy, so you would be willing to help them do it better 2) “just because” will probably not be a well-accepted answer, and 3) the fact that they are not using a methodology for the estimates means that their credibility should be low.
If people become defensive and hate to provide details, it’s a red flag. It probably means that they provide estimates based on their “gut feeling”, and they also probably think that this is the best it can be. Try and persuade them to use a methodology - any is better than none. Humans are really bad at this, and need all the help they can get from statistics.