If you can properly justify your estimate with sound reasoning, and show this to your client(s), then this is what matters most.
What follows is a particular experience I had which, I hope, will help you understand the statement I just made - which is my answer to your question.
A few years ago, at a former employer, I had a team "lead", with a background in mechanical engineering, not software engineering, pitch his "solution" to upper management about how a problem could be solved with a "Simple System"™. The Simple System™ had to manage user accounts, track hardware inventory, notify specific users when certain component quantities were below a user-given threshold, allow users to place orders for more parts, produce reports, etc. - you know, the works. The estimate that he came up with for his "Simple System"™ was 3 months and I would be the one to do it. I said I thought it'd take longer than that.
I was basically asked to do a full project estimate - waterfall style. So, this is what I did:
- I spent about 2 weeks (that I could've spent working on the "Simple System"™) breaking down high-level feature requests all the way down to stories (with point estimates) and associated tasks.
- I looked at my individual velocity per iteration in unrelated projects and used that as the basis for my assumed velocity on this estimate.
- I did not estimate time - I estimated effort based on task size and then derived a time estimate from it (using velocity points per iteration, etc)
- Documented a margin of error for the estimate. (This came from empirical data in the book Agile Estimation and Planning; it shows an error margin between -40% and +60% relative to the original estimation value.)
I explicitly documented the following assumptions:
- estimates are estimates, not commitments;
- waterfall-style estimates (which they asked for) are less reliable, need to be revisited at least every 6 months, and should be considered completely invalid if at least that much time has passed without a revision;
- my degree of familiarity with the technologies that would be used in the project (i.e., I didn't have to spend time learning them from scratch).
- I'm the only dev working on the system;
- I have other responsibilities that will sometimes require that I stop working on "Simple System"™ (i.e., I'm not working on "Simple System"™ 100% of my time without interruptions)
- That velocity-based estimates were based on unrelated projects and may be different in practice. (In reality, velocity is a measure for a team, not individuals)
- The estimate was only as good as the documented assumptions - break the assumptions, and you invalidate the estimate.
Long story short, my estimate came to 15 months to implement all the features, with the -40%+60% margin being down to 9 months (best case) and up to 24 months (worst case). (NOTE: This was 15 months to complete all features, not 15 months before we could have a portion of the system up and running in production while making incremental improvements.) They didn't like my estimate, so what was their solution? They delegated the project to an inexperienced intern and invalidated the whole estimate instead. After all, the intern was expected to be around for up to a year and they knew for a Fact™ that building Simple System™ wasn't going to take more than 3 months, so they could go overtime 4x over without it being a problem, right? GENIUS! (No, I'm not joking.)
The first Git commit in the Simple System™ repo was April 29th, 2014. For whatever reason, my brain committed that snapshot into its own memory and remembers. I had made that commit.
Well, fast forward 7 months and it seems reality is starting to rear its ugly head back at them. My manager, the very person who made the decision to hand it off to an intern, made a comment saying "Well, no one's talking about the Simple System™ project estimates anymore...". I just gave her my I-tried-to-tell-you-shrug and kept going. It was their own self-inflicted problem, not mine.
Fast forward again. It's been a year. The intern left for another team. They brought a new inexperienced intern to work on the previous intern's codebase.
Fast forward yet again. It's been at least 1.5 years since work on Simple System™ had started. It's June 30th, 2016 and it's my last day at the company. Simple System™ still had zero working releases in production - not even a partial one.
A friend close to the project within the same team at the company told me it took them about 7-9 more months to make a first release - and there were still lots of missing features.
If you're doing the work, then it's your estimate, based on your knowledge, experience, and ability. If you can show sound reasoning to your clients on why you're estimating something in a particular way, then that may or may not help. You could explain that you're trying to account for some unforeseen events and that, if things go smoothly, you'd expect things to take less time overall, and so on.
Keep in mind that some tend to provide their "best-case" estimates, assuming nothing goes terribly wrong - since it might be unlikely - and then, as soon as something worth mentioning does happen, they inform the client of the delay and adjust the estimate. At the end of the day, client assumes that particular risk.
Also, keep in mind that you have no idea about how others have justified their own estimates - if at all? Perhaps they've solved that kind of problem so many times they already have enough experience to know how much work that is "by heart". Perhaps they have more people. Perhaps they're full of crap. It's up to the client to weigh in those factors.
 I argued against this, but it was a waste of time.
 While this is speculation, I took this to mean that Mr "lead" and Mrs manager had been, basically, trashing my original estimate behind my back in their pRoGrEsS mEeTiNgS, and how I (in their view) had no idea what I was saying/doing/etc, prior to that point or whatever. (Note that no one ever bothered to challenge the reasoning and justifications behind my estimate, but that's probably beside the point. As far as I could tell, they just "felt" Simple System™ was Simple Enough™ to take 3 months because they kept referring to Simple System™ as "simple".)
 When I say inexperienced, neither knew Python, SQL for databases, how client-server systems worked, Django, Git, Apache, etc. They were computer engineering majors, not computer science majors, so I don't blame them.