As a freelancer with years of experience taking over abandoned, failed, and partly-working projects I can offer some tips and point at some causes of failure.
You can find competent freelancers and dev shops, and you can find incompetent developers. Because of the low bar to entry and usual knowledge mismatch between customer and developer, you face a higher probability of hiring someone who can't deliver, or delivers the wrong thing, and not seeing how off the rails the project has gone until you have invested considerable time and money.
Before you hire anyone you should have a very clear set of requirements, in detail, describing the product or business problems you need solved. Doing that takes effort and skill, so if you don't have experience writing good requirements find someone who does. An experienced CTO in your example should know how to do it. If they can't I would wonder what CTO means on their CV. I typically spend significant (and billable) time with my customers refining their requirements.
Ask other business owners in your field, or any field remotely related, for recommendations. Contact references just like you would for an employee. Sadly lots of scammers and low-skilled people present themselves as freelancers (and dev shops) so you have to vet and do your due diligence. Positive word of mouth goes a long way.
Then when you interview developers you go over the requirements and pay attention to their reaction. Do they seem to understand? Do they ask questions about the product/service and your business, or do they just talk about languages and their "stack" and technical details? You want to find developers who focus on delivering business value, not on technology. You don't want to hire developers who use you as their hobby project for learning new languages and tools.
Don't write a contract with hourly charges, or an up-front deposit with the remainder at the end. Describe specific deliverables based on the requirements, and tie payment to those. You should have definitions of what "done" means for the entire project, and for every intermediate deliverable along the way, with calendar-based estimates, and agree to those before signing anything or paying out any money. If the developers won't work that way, find someone who will.
Lack of clear requirements understood by both parties, and open-ended hourly or lump-sum payments based on off-the-cuff estimates lead to failure and recrimination almost every time.
You also need to establish very clear expectations around communication and schedule. You don't want to micromanage, but you need to see constant progress. The developers should have a staging environment available and working at all times, and a process for feedback and reporting issues. They should respond to all emails, calls, comments, etc. within a reasonable time, no more than 24 hours. If the developers try to push you to use their project tracking software or their communication process, and that doesn't work for you, move on. Poor communication will kill the project and the relationship. The number one thing I hear from customers when I take over a project: The last developer(s) took a long time to reply or acknowledge emails/calls/issues, and eventually stopped responding at all.
When the developers reach their deliverable milestones you need to review and approve (or send back) their work right away. Don't add friction or the developers will lose momentum. Pay immediately when you approve deliverables.
Projects fail mainly because of poor or mismatched communication and personality conflicts, not because of technical problems (though those happen too). Don't expect to write a vague description of what you want, sign a contract and write a check, and then get a satisfactory product months down the road. You have to stay engaged and work with the developers. Once you have established trust and have confidence you can give the developers more leeway.
You may get advice about hiring lawyers and writing ironclad contracts. Unless you have the goal of spending many hours in mediation and paying attorneys, focus instead on solid and clear requirements and setting very clear expectations for performance and payment. The best contract will not prevent conflict or breach, no judge or mediator can compel someone to deliver code they can't write. You need a contract but remember that laws cover most of these situations already, and breach of contract suits will drag for years through courts or mediators, with the best resolution a judgement you probably can't collect.
I have some articles on freelancing, and one specifically about hiring freelancers, on my web site typicalprogrammer.com. Free, no ads, links, popups, or other nonsense.
Good luck.