3 ms·

Landing big contracts as a small company - it's not all bad. They can bring in a lot of revenue, for not that much sales effort. And if you have good processes

Landing big contracts as a small company - it's not all bad. They can bring in a lot of revenue, for not that much sales effort. And if you have good processes down, they can also be much easier to deliver on. At least in the US, contract law can be very fair, financing options to facilitate large contracts are plentiful, and most large businesses act in good faith. So it isn't so much landing a big contract is bad, but landing a big contract that you can't deliver on is very bad. Determining what you can and can't do, how much you need to invest into your internal processes and capabilities - that is the challenge of running a business. Usually, in successful businesses I have worked at (or business units), I see a split. Ideally it would be 50-50 large contracts to small accounts, but usually realistically is is more like 60-40. Probably depends on the industry too.

jrockway 3y ago
Yeah, it's a double-edged sword. On the one hand, you are getting a lot of money and probably a great case study for your marketing material. On the other hand, you are probably going to be asked to move your product in a direction you wouldn't have otherwise taken it. Sometimes that's great, sometimes you're just a contract software engineer for much less money than you'd get doing that explicitly. You can be wary or you can be excited, every case is different.
- no_wizard 3y ago
  Rollout clauses can help with this. For instance, don't draw up a contract blindly, mandate an install base and training as part of the package, and that contractually, it must be installed, training complete, and in process for X number of days, and in that time period requests are limited to direct support (IE, actual bugs or user questions). You should be meeting with users as much as possible during this time, if you can. Make it clear that you only want and will listen to their feedback and make changes in that respect. Then, schedule a meeting with the users at the end of the specified period, to get a sum of all the positives and negatives of the product, and have a separate with management about whats next, what your roadmap with them looks like (if applicable) etc. This keeps the relationship in control in a positive way, usually for everyone. I've seen clauses like this before in enterprise contracts. If you can everyone to agree to it, they turn those fears into assets real quick, and helps manage the burdensome spam of support requests for X or Y feature.
withinboredom 3y ago
How does “I want x feature for $y or I terminate the contract according to our terms” bring contract law into the equation. Most often you have a single person in the big org as your champion. If they leave, you leave. There are many ways to be their bitch. Many, many ways.

jrockway 3y ago

Yeah, it's a double-edged sword. On the one hand, you are getting a lot of money and probably a great case study for your marketing material. On the other hand, you are probably going to be asked to move your product in a direction you wouldn't have otherwise taken it. Sometimes that's great, sometimes you're just a contract software engineer for much less money than you'd get doing that explicitly. You can be wary or you can be excited, every case is different.

no_wizard 3y ago
Rollout clauses can help with this. For instance, don't draw up a contract blindly, mandate an install base and training as part of the package, and that contractually, it must be installed, training complete, and in process for X number of days, and in that time period requests are limited to direct support (IE, actual bugs or user questions). You should be meeting with users as much as possible during this time, if you can. Make it clear that you only want and will listen to their feedback and make changes in that respect. Then, schedule a meeting with the users at the end of the specified period, to get a sum of all the positives and negatives of the product, and have a separate with management about whats next, what your roadmap with them looks like (if applicable) etc. This keeps the relationship in control in a positive way, usually for everyone. I've seen clauses like this before in enterprise contracts. If you can everyone to agree to it, they turn those fears into assets real quick, and helps manage the burdensome spam of support requests for X or Y feature.

withinboredom 3y ago

How does “I want x feature for $y or I terminate the contract according to our terms” bring contract law into the equation. Most often you have a single person in the big org as your champion. If they leave, you leave. There are many ways to be their bitch. Many, many ways.