I have been building custom software for close to 20 years now, 14 of those years have been in a consulting role. For the last 8 of those years I have been running my own company, most recently Red Rectangle.

This is fairly obviously but, there are a few of different reasons you might want to hire a person to help you build custom software:

• You have a specific problem that doesn’t seem to be addressed by existing software.
• You already have software that isn’t meeting your needs.
• Your existing team either doesn’t have enough capacity or doesn’t have a specific skill set needed in the short term.
• You believe you have a better solution to a problem and can make money off it.

The first thing I would advise is to search the internet again, because the number of problems already solved is much higher than most people realize. There is a reason why lots of multi-million dollar companies are basically managed off an Excel spreadsheet or two.

Normally there comes a time in almost all companies where it makes financial sense to have custom software. Whether, competition comes in that is cheaper or labor becomes more and more expensive.

When is it time?

Ultimately, the decision gets made when a product owner believes they can save money with an upfront capital investment. I don’t think it will come as a surprise to anyone when I say, the main motivation is to do more with less resources. The most common resource in this case is employees.

Talking about automating work and doing more with less people is obviously a touchy subject. This is because people initially think about layoffs and the rich getting richer. But depending on the type of company the people whose jobs are getting automated, are generally not automated fully. This gives employers opportunities to retrain and reassign employees that already have some understanding of their business. This can be a big win for employees, because the most repetitive and tedious tasks are automated first.

Another big reason to automate tasks is for consistency and quality. If you have a task that is very tedious, humans tend to make mistakes more often than if it is difficult. This is because we tend to underestimate easy tasks and overestimate hard tasks. The brain is setup to put more energy into difficult tasks. These tasks also tend to be the easiest, this makes repetitive tasks an especially good target for automation.

What is it like working with a consultant?

For some people this is going to be super obvious. Start by asking friends or family if they have any experience hiring someone to help them. In my experience, you might have to go to friends of friends to find someone with relevant advice. Ask all your questions no matter how dumb or irrelevant you think they are.

This gives you some vocabulary you might not know and also helps exercise that part of your brain. Building software requires thinking systemically. You might know what your pain point is, but sometimes the steps before your pain point can be easier to fix and provide 80% of the value.

Go into any talks with a software consultant with an open mind. The best consultants will ask questions about your business that seem very obvious to you. That is ok, they might be checking assumptions, or helping themselves build a mental model of your business. Before a line of code is written or a screen is wireframed, everyone has to understand and agree what the current process is.

Try to do less. Software can always be made more complex in the future; solving evermore complicated problems. But in my experience, software is frequently over complicated before a better solution to a problem can be discovered. Then what happens is the current piece of overcomplicated software is slowly morphed into a system that more closely resembles the ideal solution. The biggest downside to this approach is wasted time and money.

How do I find a good consultant?

If only a little tongue-in-cheek, I would suggest you already found one (me). But more seriously, make sure you talk to a few people and to make sure it isn’t all smoke and mirrors and you have a good grasp on the process.

You should expect that any person you are going to work with is going to be evaluating you as well. Beyond the usual time and budget considerations. You need to consider other characteristics such as likability and temperament. If you are the type of person who likes to work with someone who is very direct then say that. Setting expectations early is the key to a good relationship.

I have personally never used any of the freelance websites such as upwork, freelance.com, etc. There would be noway for me to comment on them. But I would only suggest using these sites for very small projects with easy to define specifications. They probably have their place for people who know what they are doing, but are a bad fit for building long-term relationships on both sides (consultant and business owner).

How much should I pay?

I know this is the main question every client has. There is a constant cost benefit analysis that takes place to decide both, how much software to build and whether or not to build any software. Sometimes the right answer is to not build a product.

I am not going to write down specific prices because I want this article to be evergreen. There are basically 2 different ways to structure payment for services.

1. Money for software
2. Ownership for software

Money for software

Fixed bid

This means the consultant and product owner agree on a price and scope before getting started. This is a good fit for well understood small projects. I usually don’t structure projects on fixed bid. This is because you have to have a very good understanding of what is getting built before the project starts.

A big down side to fixed bid contracts is change requests. When the product owner’s understanding of a project changes and a change to what the project does is needed, a new statement of work is needed that changes the original scope with the new budget. As a consultant, I usually make these additive. So any changes are in addition to the original scope, even if the project owner is removing features from the original.

One way fixed bid contracts can work is if the consultant already has a software product that solves most of the product owner’s problems. A fixed bid statement of work can be written that covers the customization needed for the business needs. But this essentially fits my definition of a small project.

Time and Materials

Time and materials generally means paying per hour, day, week, month, etc. You get what you pay for and generally have flexibility to change at anytime. I always push people in this direction first, this is because I have never done a project where the scope didn’t change significantly in the middle. Also, as apposed to fixed bid, developers don’t have to apply some multiplier on this. When I worked for consulting firms, they would ask us how long it would take then multiply that number by 2 or 3 depending on how bad each individual developer was at estimating.

Ownership for software

I personally have a lot less experience with this so I would caution anyone entering this type of agreement to do a lot of due diligence.

Percent of Profits / Stock

The most common approach I see is a business person says, I will give you X% of my profits / revenue / company. Sounds great on paper. Both sides share the risk and reward. The trouble is from the consultant’s side, if you took a stake in a lot of companies, consider the tax complications you are looking at. I already pay my accountant a substantial amount of money every year (money well spent). I assume taking a stake in a company would complicate that.

Co-licensing software

This is a less common approach. The idea is that custom software is written for a business at a discounted rate. In exchange for the discounted rate the software developer receives the opportunity to reuse the code for an internal product or another client. This usually comes with a clause that the consultant won’t compete directly with the product owner.

This is a good approach if the product owner isn’t trying to make a product for resale. For instance, I can imagine a dentist office needing some very specific integration between a piece of equipment and their billing system. The dentist just wants to automate some tedious task, but the consultant could potentially resell the same solution to 100 dentist offices for very little work after the initial project.

Venture backed companies will never take this approach, especially with small consultancies. This is because even if the product the venture company is making fails, the VC can always sell the intellectual property to try to claw back some of the money.

Conclusion

To sum it up; make sure you are solving the right problem, at the right time, with the right people. Focus on the easiest things first to get quick wins and to build a rapport with your team. Product owners and consultants will have a good outcome if they try to understand the tradeoffs and risks of the other party. But, it can end up falling into patterns and ruts like any relationship. Like any great relationship, the most important aspect is communication.