This might help:
https://twitter.com/jugurthahadjar/status/131066829330549965...For 1.3., in addition to geography and time, limit "sector" as well. For the software in general, make sure to have a modular/plugin architecture from the get go so that it is as easy to remove functionality as it is to add it. The frustration of developing a bespoke solution for a client that you cannot sell to another client who has practically the exact same need just because it is so bespoke that you cannot easily tailor it to someone else is immense.
Make it easy for you to make another product if retaining IP for a specific solution is not feasible. Ideally, a lean/light core that does practically nothing but load extensions/plugins that encapsulate the functionality, so that the whole value is in the plug-ins themselves, which you can develop fast enough for other clients/use cases/verticals/sectors/roles and then abstract in another product.
Unrolled for the reader here with minor edits:
0. Form:
0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.
1. Contracts:
1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.
1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.
1.2. Retain intellectual property to amortize engineering and sell what you make to others.
1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.
1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.
2. Presentation:
2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.
2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.
2.1. General presentation with broad strokes of your capabilities, including previous work with other clients
2.2. Conversation with the prospect on their worries in a given space
2.3. Conversation with the prospect on their worries in a given space
2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.
2.5. The client finds one problem urgent/highest priority/highest value
2.6. You get together and talk about "desirability, fasiblity, viability".
2.7. Once you agree on what to do, prove the concept.
2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.
3. Execution:
3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.
3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're in, you're in.
3.2. Listening and assuming the client is smart goes a long, long, long way.
3.3. Send meeting notes to the client. It clears ambiguities during/after the project.
3.4. Press to get the client's domain experts' collaboration. They will actually use what you're building. Get them at the table.
3.5. Some of the most valuable insights are gleaned after a meeting and not necessarily with your "counterpart".
Don't build the wrong thing.
4. Abstract:
4.0. When you solve many problems, some patterns emerge. You built custom products for your clients, but you can abstract functionality and build tooling to scale your services, and enable others to do the same.
4.0.0. e.g: we we built machine learning products for enterprise clients. After many projects, we built our own machine learning platform to "Get Data Products Released".
4.1. One advantage of this approach is to explore the space while being profitable. Some problems exist not for lack of a nice front-end or lack of knowledge of the target audience. Coming at them from a purely "webdev"/"devops" mindset can bring bad surprises.
All the best,