Making change requests is like the black death to your project, not just a paper cut. Imagine building a building, you start with the idea to build a house, you draw up the architects plans and start building. A third of the way through, you decide to add on an extension, this is more work and your deadline has to go back. You then make changes to interior design, a new wall here, remove that one there.
Stop making changes!!!!
When you make a change, it affects every part of the whole and the cost and the deadlines.
We in development have a methodology called Agile... the team creates a backlog of all the bits required to make the project. We have 3 week sprints to complete a selected set of this backlog jobs. You seriously need to read up on this Agile Method in Software Development.
A poor quality finish? Has Microsoft Windows ever lived up to being a good quality finish?
Get it done and get it on the market as soon as possible.
And don't think for a second that you won't be paying for this product FOREVER... for the length of time that your business runs you will be paying these developers to continue to develop the product. Each year tech changes, new business requirements, your code becomes old and no one knows what or how it does what it does. You'll have new costs.
Mitchell is right too... so you can use this leverage to say that you might not hire them for the next go around... but do remember that they wrote the code and the code could be terrible to look at for a new or even their development team.
Technically you should have a CTO and /or a Product Manager.
Software is expensive, time consuming and a never ending money pit, the rewards to for getting it right are big but the costs to get there are equally big.
Enjoy.
This is a story told over and over again for years and decades now. I've lived it from both sides.
You mention "change order" and talk about the product being finally "delivered" per a "deadline." This tells me you are using some form of the waterfall method. If I were you I would ask the team to shift to agile. They probably know how but are using waterfall because they think it's what you want.
Here are some big changes you should expect:
- No sign-off of specs, no change orders, no fixed "deadline" for the whole project
- They should deliver working software to you within 2-3 weeks and then every 1-2 weeks after that, if not continuously
- Your specs will be vague, short, and changeable with no formal change process
- Expect to be high engaged with your dev team -- every dev can reach you on IM or phone -- expect several calls per day
- Expect to personally review and jigger priorities often -- maybe once per week
These are simply the markers of the agile method, which is very mature and SOP in most quarters for a long time now. Beg pardon if I sound condescending and you are well aware of agile, but if you're not there's massive amounts of material about it on the Interwebs. IMO it matters little what flavor of agile you adopt: scrum vs kanban vs XP vs whatever. But any way you go you will have more satisfying outcomes that with a waterfall method.
What you lose with agile is a sense of certainly and control at the start of the project. You lose the liberty yo check out of the process and let the sausage be made by the experts absent ongoing guidance from you. What you gain is visibility, insight and meaningful control and, in the end, better software faster.