Inexpensive ones. Kidding aside, as a startup, our needs and capabilities are quite different from a more established company. We can't afford to pay for cons

Inexpensive ones. Kidding aside, as a startup, our needs and capabilities are quite different from a more established company. We can't afford to pay for consultants to fly business class, nor expensive per diems. We can't afford to implement heavyweight development processes, nor should we since being nimble is one of the few advantages we have as a startup. Software licensing costs is a concern at this stage, so we'd rather do a subscription for a (for example) CAD package even if it's not the industry standard over buying a license for the industry standard package. Also frustrating in general is that as a medical device, our volumes are never "large" in the consumer sense and so many common manufacturing processes (e.g., injection molding) are not practical, nor are companies excited to supply parts in our expected volumes—our consultants need to consider what are sometimes less common processes or smaller, "hungrier" suppliers. For many things, the budget is driving the bus, and it's within reason acceptable to need to spend more in the future if it means we can spend less now. It can be hard to find the a consultant at an experienced group (and domain expertise is what we need) that is willing to work with us. Our future business is not guaranteed (statistically we are likely to fail), the business we will be bringing is small, and we're pinching pennies on what we bring. What seems to have worked is to find a "hungry" associate-level consultant (keeps costs lower) at a larger group who can tap into the experience of senior/principal-level consultants on demand. We point out that, if successful, we'll be able to bring more business to the associate-level consultants, so we both will grow together. I'll give a specific example, stream of consciousness style partly out of laziness. We have a software component, and a portion will be safety-critical... crap, things just got more expensive. We know we need to develop the device under a risk-management plan (ISO 14971), so we don't need consultants to tell us that, but we may need them do to a design review because we don't have enough in-house experts (how many do we need?). We know that the software component must be developed under a SDLC (ISO 62304). Should we do it agile (as per AAMI TIR-45, not cowboy agile nonsense), or a more traditional V-model? Does CMMI or PSP apply to us? Should I listen to the nice people at IBM and use Harmony, or are they preying on a poor (emphasis on poor) innocent startup? It'd be nice to have a consultant advise us, based on their experience, that one or the other works better for a startup. Have we properly identified the safety-critical portions of our design? What should the development environment look like: is MISRA-C everywhere the right answer? Probably not. So MISRA-C for the safety-critical portion, and regular C everywhere else? Or should we do Java/RTSJ with a fancy JVM? Ada/SPARK? We could justify any of these, and probably others. What are the costs of tooling for each choice, licensing costs, how hard will it be to find employees/contractors (should we use contractors? how many will I need to hire?), and what will productivity look like? What about maintainability? Is QNX better than VxWorks? Is model-based systems engineering worthwhile, or is it an expensive buzzword? Those nice people at IBM said Rational is great, and it'll tie into DOORS! And they said DOORS is great! Maybe I should use Excel instead of DOORS, I heard from a guy on the internet that works just fine. And so on... So for much of this, we want an experienced consultant that can review case histories and show us that in the past, comparable companies were successful by doing X, and so it makes sense for us to go that route too. Many times we know we need to do something, and frequently how to do something at a larger company, but not the optimal way to do it at a startup. I can do a decision matrix, but without the case histories, there's too many gaps in the matrix to be useful. We also need to have external people for design reviews, and figure out when we need to pull in those external people, when we don't, and when we should. I need to be able to tell the regulators that our processes were based on industry best practices. I need to be able to tell board members the same, and be able to tell them that our processes and plans have a successful track record at comparable companies to justify the time/cost/etc. I want to be able to show shareholders that we're being good stewards with their investments, and we're doing that by making careful, informed choices.