If you’re just booting up a start-up, and need to hire your first developer, you’ve got a rather unique set of hiring hurdles in front of you.

You’re, by your very nature, an unstable bet for a developer to make. You could fall down and go boom next week or next year. And that circumstance is much more likely than the wild success you have in your head right now, by an order of magnitude.

And every developer you meet and pitch likely knows this … even more than you.

At the same time, making a poor hire here can greatly increase the already astronomical chances for a poor outcome. For most tech startups, development and engineering is ultimately the Product … it’s what you, Mr. Growth Hacker or whatever you call yourself these days is growing and selling.

Much of the focus of late on hiring a technical co-founder has been on making a marriage and dating metaphor: The thought is you need to be like an old married couple, practically from the jump. There are actual, real-life, founder dating nights intended to match marketing founders with technical co-founders.

I’m not making that up.

Thing is, nobody ever talks about moving in together for a while first.

And that’d be my primary suggestion: Pick someone you’d like to try out for a while, talk about it, and then begin a freelance arrangement on the product you’re building.

Not because you’re not sold on him or her, but you want to make sure you’re both a good fit — for each other and for the product you hope to build together.

It’s a lower-stress, lower-risk initial step for both of you. You get the chance for a potential technical co-founder to work on the product itself and hopefully see your vision for it over an elongated period instead of a quickee dinner date.

For the developer, he gets a low-risk way to see what it’s like working for you and see if this is a product he or she can believe in and make that highly unstable bet on.

And if they’re moving from a steady job, at least you cushion the transition with some cash and a reasonable sure paycheck (so to speak) for a bit. You also shouldn’t be afraid of just nights-and-weekends work for a bit if they’re currently steadily employed.

Essentially, your bet is that once he gets into the product he can really dig in and forget (at least partially) all those risks I mentioned above.

Are you going to actually pay this technical co-founder for this freelance work? Yes. Is this going to cost you actual, cash money? Yes. And if you’re truly ambitious it could cost you quite a bit.

But in the grand scheme of things, it’s not going to make or break your startup. At some point, after you flail around trying to find a developer who’d work for free in exchange for the privilege of the title, you were going to be paying somebody to do this anyway.

We’re just moving it up a little higher in the process.

At the end of the day, the type of developer you’re looking for in this role is likely one that’s strangely risk-adverse compared to his peers. We’re alleviating some of his sense of risk with the try-it-on period, but you’re still asking him to take a big-ass leap of faith after all.

You’re likely also looking for, ideally, a pretty deep amount of domain knowledge in either your planned market, and/or similar problem sets. And a self-starter and all that.

But we’ll get into that in later chapters.

Other early developers

When you’re pre-revenue/pre-venture funding, the above tactic should also work well for other early engineers. Try the relationship on for a bit, lower their risk threshold, give them a chance to see how you work and still get paid for it.