|
People won't onboard a freelance developer for a short project unless they are desperate (and startups can often be desperate in different ways), but they will onboard advisors and consultant leaders to get them through tough periods. The difference in actual day-to-day can be minimal, but it's how you present yourself. "I'm a CTO", not "I'm a dev (also a CTO)". You could become a consulting CTO for hire. Talk to some of the startups in your target group, and to non-technical founders, to understand more about what they would pay for, and what results they would want to see in order to pay the bill. For example, selling the product might not be the goal; raising investment is more likely. For some, it may simply be coming in, assessing the state of things, making a list of recommendations, and hooking them up with full-time CTO candidates. For others, having a technical advisor who can screen, interview and hire their future tech team is incredibly valuable. For MVP building in the specific stage you refer to, as others have said, profit sharing isn't a particularly reliable model. The MVP may never take off, and by the time it does, they may have built a whole team and rewritten your code. Other than content, here's one thought. What if you built up a set of talented developers who need your skills too - junior folks looking for exposure to portfolio projects, senior devs happy with a 9-5 but wanting some intellectual stimulation and to learn new techniques and technologies. Then effectively set up a MVP shop, where you manage the first stage of the 'idea to code' pipeline, but hand off the bulk of the implementation to others. Perhaps these others bill hourly and you get a cut. You can even be a broker for just introducing the two and still get a cut, though smaller. One thought, I think that this pattern of work can be detrimental sometimes. An engineer joining a startup doesn't want to see a bunch of spaghetti code written by some consultant who is no longer around. It's often the case that she has to deal with it, but it can be a red flag of sorts. There's a whole second set of consulting needs around transforming a messy MVP which has started to show traction into a scalable, reliable product. It's uglier, harder, and therefore probably harder to find people who are truly good at it. But a lot of that may be relationship-based -- understanding what the startup leaders really want and what's working, translating that into new requirements, and keeping them happy if the work required to make it scalable is a lot more complex than it seems from the outside. |