Look for a technical partner that shows interest in your business and listens to you.
Software development is a continuous process of decision making, therefore developers need a deep understanding of the underlying goal of their work.
The traditional approach where developers just follow instructions or specifications causes a lot of trouble and friction. It puts all the burden of requirement engineering on you. And even the most detailed specification leaves enough wiggle room to build something completely useless.
Experienced engineers can provide a lot of valuable input and ideas on how to structure requirements, find shortcuts, avoid unnecessary costs and optimize the overall process. Requirement engineering and software development should be highly interactive.
Build a long-term trustful relationship.
You have to trust your engineer because there are important parts in the development process you can't control.
Here is an incomplete list of the hidden qualities of a software solution:
- Security: There is huge number of possible vulnerabilities, here are some examples https://www.owasp.org/index.php/Top_10_2013-Top_10
- Consistency: A system might show correct behavior under low load, but when exposed to high concurrent access suddenly generates random corrupt data. These kind of errors are typically not reproducible and might even corrupt existing data.
- Protection against data loss: Your data is you most valuable asset. Software bugs can be fixed but lost data is gone forever. Is there a regular backup plan in place?
- Availability: Is the system able to run 24/7?
- Scalability: What happens if your application suddenly gets a lot of traffic? Is it easy to scale up without investing in new expensive hardware?
- Maintainability: Even if all other qualities are Ok, you might have a solution where the source code is of so poor quality that it is impossible to make changes or add new features without breaking things. I've seen projects where the entire solution had to be rebuilt from scratch for this reason.
Although I've just scratched the surface I think you get an impression how crucial and potentially dangerous these high risk factors are for your business, but it's completely impossible to verify these for a non-technical person. The consequences might show up only months or years after the completion of the project.
So why should a developer care about this if it's so easy to rip off a client by just ignoring these factors?
First of all, good engineers have a sense for these qualities ingrained in their DNA. It hurts them to ignore these issues.
And second: the fuel of a software engineering business is reputation and referrals. Experienced developers are totally aware of this.
Talk to the person and build a personal relationship. Ask about these hidden qualties and how they should be handled.
Use a written contract
This might look like a contradiction to the previous point, but it really isn't. Things can go wrong, even in relationships that started really well. It's a bit like a pre-nup ;)
Avoid time-based rates
Trading time for money automatically generates a conflict of interests and for a non-technical person it's impossible to check if the hours on the bill are realistic or not.
On the other hand, real-life projects are just too big and too much in flux to agree an a fixed price.
I prefer an iterative fixed-price approach:
- define a first package of features which can be delivered within less than two weeks and agree on a quote.
- after the package is finished, review the result and check if it conforms to the package definition.
- At this point you have the opportunity to revise the overall direction of the project and react to changed business requirements. Define the next package and reiterate.
All these steps should be conducted in close collaboration of business and engineering.