You need to get results. You're building software to solve your problems.
A quick google search states that somewhere between 50% to 80% of software projects fail to meet their requirements. Requirements in terms of cost, schedule, quality, or meeting their goal.
One reason can be that software projects are hard to estimate. Developers tend to be overly optimistic in their abilities or what tasks involves.
A rule of thumb to estimate development time is to take the original estimate, double it and then add more padding... And you'd still be wrong, it's not very scientific... Some tasks may take a lot less time than you expect while other that appear mundane would take a lot more. On top of that, the time spent doesn't match with the expected impact.
To ensure your project doesn't suffer the same fate, you can take some precautions.
Start with your why. In most cases, one of your goals when starting the process of building tools, for any kind of use, is to get results, to solve problems you have.
So, you've decided on building and found someone to do it, Great! How familiar are they with you? your work? your clients? your processes? your industry? How much do you trust them to do the right work, the first time?
With that in mind, don't let your developer(s) disappear and not deliver or show you something, anything for a while before you are able to review it.
You want to make sure that they are making progress, beyond what they tell you.
You want to be sure that they are making the right kind of progress.
Make sure that they are giving you something, anything. Whatever that is.
Get results from your new tools faster. Any little help is better than nothing.
Not following the development process and progress closely leave you exposed to more risks and costs than you would expect.
It costs money to get to where you are. Whatever you got, you have already spent money and time to acquire it. If it doesn't match, you have wasted all those resources.
The later you detect an issue in a feature, the more costly it gets. Not only you've spent more to get to that point, but, it will cost more to fix it. It is possible that some features have been built on top of that feature, meaning that they are also wrong and will need fixing or being rebuilt. That will cost even more and can quickly snowball. Especially if you let your developer disappear again with a big list of things to fix.
Following the process shows that you care and that it is important to you. But don't micro-manage either, leave people the freedom to do their best work. Keep people motivated and engaged. Adjust your involvement to something that suits you and would make things work long term with your team.
Extract any possible value from the tools as you can.
When you get something, review it, test it and provide feedback in a timely manner. Not only it can prevent going deeper in the wrong direction, it will keep the developer engaged, caring and willing to assist you ... as long as you're being reasonable and worrying about the right things.
One of the most frustrating thing as a developer is to build something that doesn't get used or worse looked at. It is understandable if it takes some time to be useful, but a quick validation or acknowledgment of the work can go a long way in the relationship.
Also, try to give feedback in a timely manner. It has a big negative impact on moral and future work to receive a big list of fixes weeks or even months later. It's the same feeling as the one you may have if you are not able to get anything shown to you. On top of that, having to return to an old code, an old context that may have gone out of mind requires more work to remember why things are the way they are. Making adjustments is much easier when fresh and on top of mind.
Be timely
When providing feedback, try to make it as comprehensive as possible. Multiple aspects of a system may be related in ways you don't necessarily expect. Some changes may be quick to do and accommodate. But also, keep your focus on the right things and expectations.
Talking about expectations, make sure they are communicated and understood by your developers. It depends on your context, what you want to achieve and how. Mention any change. You won't be able to get everything right at the same time. Figure out what matters to you now and focus on thast aspect. It can be anything:
Let your developer know what matters. They will be glad to delight you if they know what matters most. If you don't, they may be annoyed if you focus on the colors when they would like your attention on the process and vice versa.
Align expectations
Once you start seeing results from your development efforts. You may get ideas. Ideas of what can be possible. New things to try, new things to do. That's great!
However, don't overwhelm the development team and change your mind on what to do too frequently. Make sure that your priorities remain the right ones. That if still relevant, what can be finished and useful gets done before embarking on something else. Remember, you need results, compounded over time, the small wins you can get now could be more impactful that the big one you might get in 3 months.
Feel free to change what's next, not what's now.
I will refer to my article Own & Control.
You want to limit the risks of not having anything (everything) under control.
You want to be in charge and control what you are paying for. Don't let your code be hostage.
It may be annoying but the setup costs are nothing compared to what you could loose.
It's yours