This approach has a lot of pros and cons.
By committing to a fixed price for a project, you're taking a lot of risk on yourself.
What if it takes more than Y?
What if you weren't able to expect the true scope of the project?
What if the customer isn't cooperative and wastes your time?
What is considered a reasonable delivery? How many bugs do you continue to fix for free without charging more?
How many changes to you put in your design without charging more?
Working at an hourly rate saves a lot of legal and contractual headaches. Its also critical when you're working with an agile company that has constantly changing needs and expectations.
Many of the issues you mention are solved by carefully defining the scope and what is included for the price. You typically don't productize a service until you have done a number of similar projects on a hourly basis and truly understand what the "typical" customer needs and what it takes for you to deliver it.
You can also win more work because some clients aren't comfortable with the undefined nature of hourly work, and prefer to pay a fixed price for a service so they can budget accordingly and not get any surprises at the end of the month...
I don't have a lot of experience with software services but when I was a consultant (IT industry analyst), most of the work that we did was fixed price. Sometimes this was straightforward because the time was explicitly capped (e.g. an advisory day). Other times, it was a standard deliverable of a type we had done many times before (e.g. a paper); these could take more or less time in a given case but they were pretty predictable. And sometimes, it wasn't all that standard but we knew the day rate we were aiming for and could take a pretty good swag at the time required; here is was very important to spend time up front scoping the work.
(And sometimes, we really weren't sure, in which case we wouldn't do the job for a fixed fee.)
No problem there. Educate your clients. Tell them if it takes significantly longer than expected you will come back to them. Tell them it is not likely but you want to be straight from the beginning.
You still end up taking the financial risk on yourself.
It's one thing if the project is delay because of you. Its another thing if the project is delayed because their backend guy hasn't fixed a few bugs and you're stuck creating ugly workarounds in the client code.
In the contracting world these types of contracts have more risk but are more profitable. The key is to get you ducks in a row beforehand. Your project management has to be very good. There is some type of work fixed price isn't suited for, obviously, but lots of work where fixed price makes a lot of sense.
What if it takes more than Y? What if you weren't able to expect the true scope of the project? What if the customer isn't cooperative and wastes your time? What is considered a reasonable delivery? How many bugs do you continue to fix for free without charging more? How many changes to you put in your design without charging more?
Working at an hourly rate saves a lot of legal and contractual headaches. Its also critical when you're working with an agile company that has constantly changing needs and expectations.