Do you have a smallish bit of programming type work you need done? You are thinking of either hiring somebody or getting contractors in? There are several pitfalls that you could experience and not all of them are the fault of the people you hire. I am here to set your expectations.
Know what type of people you hire
By the way I will use hire in this post to mean either employ or contract, you choose.
Historically programming have been done by programmers, or software development engineers. These would throw code together and tell you it is finished. Sometimes within deadline and sometimes not. You would then have QA people write test specifications and test the software and produce a list of bugs that then the programmers would have to fix. if you had a small budget you would forego the QA and try and test it yourself. This is not the way to do things.
If you insist on hiring an old-fashioned programmer, make sure you also hire an old-fashioned QA because otherwise the software you are making will never work. This project of yours is still probably doomed to be over budget.
A better way would be to hire a pair of modern senior agile developers that have learned the skills involved in QA-work and can design correctness into the system by clearly defining acceptance critera and handling edge-cases up front. You can advertise for an agile tester or something, if no developer you find admits to being great at testing, but ideally you are looking for a pair of developers that are close to the complete package.
Yes, by the way, hire at least two developers. As the mythical man-month says you can’t double project performace by doubling the number of resources, but a pair of developers are much more effective than a lone developer to the point that it definitely is worth the upfront cost.
You will need to be on hand to look at the software as it is being constructed and make decisions on what you want the product to do. Your developers may give you rough estimates (S/M/L or similar) on how much effort certain things are and suggest solutions that achieve your objectives in an effective way, but you need to be available or else development will halt. This is not a fire-and-forget thing, unless you can fully authorise some person to be product owner for you that you can place next to the developers full time.
The thing you are doing, owning the product, is crucial to the success of your venture. I will post a link below to reading material as recommended by Stephen Carratt, a product owner I work with on a daily basis, that helps you define the work in small, clearly defined chunks that your developers call User Stories.
Start out with small things and add features iteratively. Start by finishing core functionality first and always only add the most important thing. Don’t get me wrong, do have a roadmap of what you want the piece of software to do so you know where you want to eventually end up, but avoid spending time on specifying details right away. There will be cheaper or better options becoming apparent as you go along. You may be able to release working pre-releases to a subset of the intended audience to validate your assumptions and adapt accordingly.
Read up on working in a modern way
To help you create user stories that will help organise the work Steve recommends User Story Mapping (Patton).
Read about Lean Software Development (M Poppendeick) and Agile Testing (Crispin, Gregory) to know why the old way of making overly precise specifications (either of tests and code) ahead of time is wasteful and how working closesly with the development team is more effective in making sure the right thing is built.
Also, to understand why your developers keep banging on about delivery automation look at Continuous Delivery (Humble, Farley) although there are fictionalised books that illustrate all these benefits such as The Phoenix Project (Kim, Behr, Spafford).
But hey – when am I done? And what about maintenance?
Exactly! Why did you develop this product? To sell it? Is it selling? To help sell something else? Is it working? Hopefully you are making money or at least building value. Can you make the product better in a cost effective way – do so, if you can’t – stop. Purely budgetary concerns rule here, but also consider the startup costs included in dismissing your first developers and then shortly aftewards getting two other ones in to evolve the product, needing to first spend some time learning the codebase from scratch before they can work at full speed.