| I did this for 13 years. The basics are covered well in this thread already, so I'll just add a couple of points. The phrases we always used for contracts were "time and materials" versus "fixed price". We wanted time and materials, which means the client pays us a set rate for each unit of time we work (could be hours, days, sometimes months) plus the cost of any materials we need to do the job (software or SaaS licenses, assets, or special hardware we need for that job). This is a great model for the contractor, but riskier for the client. Clients always wanted a fixed price. That's when you guess up front how much the whole project will cost. This is obviously riskier for the contractor. In reality, most contracts we used were kind of a mixture of these. We broke it into sprints, and billed T&M within those sprints. If the client was unhappy with what they were paying for, they had the opportunity every week or two to pull the plug. The other point I want to bring up is that there's kind of a systematic flaw in how most custom software dev firms make money. I saw the exact same process ruin two different firms. Let's say you run a custom software dev shop. Every month, you need enough billable hours to pay them, so you find contracts for them to work on. And, at the end of each contract, you need to find the next contract. The problem is that not all your contracts end at the same time, so, you've always got a rotating assortment of employees sitting around waiting for the next project. Naturally, you've got a pipeline of new contracts, and something always comes up. The problem is, it's almost impossible to consistently find contracts that perfectly match the exact group of people you happen to have sitting around waiting for work. What most firms do in this situation is hire more people so they can take the contract, which increases their payroll, and requires them to look for an even bigger contract next time. The business model now becomes a riskier and riskier series of bets, as the business balloons. Meanwhile the quality of employees is dropping, because you just need butts in seats at a faster and faster rate. Your ability to succeed on contracts is put at risk, not to mention your company culture and morale. Eventually, you either lose a client due to incompetence, or you can't find a big enough contract to meet your expanded monthly nut, and the whole thing topples over. After living this for over a decade, I came around to the position that custom dev shops can't exist forever. They're unstable systems that will all eventually break apart into smaller custom dev shops, which then recapitulate the same unstable cycle. |
Then you keep one of employees, later maybe more, on that SaaS and slowly change your revenue mix. Then you still might get some additional projects but you always have something to spend your FTE time on. In the end you change the company profile where you chase different things than just having butts in the seats.
But that might mean you are not getting any salary for months because you have to reinvest in your SaaS idea. Of course having a viable product idea is another very important point.
Upside on the other hand is that selling viable SaaS business will be easier than selling dev shop, because dev shop only has developers. When developers quit dev shop value goes immediately to 0, with SaaS you still might have IP and paying customers.