The term "founder" describes your relationship to the history of the business. Page and Brin will always be Google's founders. The term "CEO" is about your position in the current organization's hierarchy. Some founders will be CEOs, at least for a while.

Titles are the easy way for outsiders to understand how to connect with your organization. So if you're the head, just use the title CEO unless you have some strong reason not to. That way people will know to come to you with CEO-ish things. There's no harm in putting "founder" on your business cards as well. E.g., "Founder / CEO" or "CEO & Founder". But things like "CTO & Founder" are also legitimate, so don't go with "Founder" alone, or people will be left wondering which things they should contact you directly about.

A founder is a person who's in at the beginning. But beginnings are slippery things. For me there are three characteristics I look at: early contribution, risk, and ownership.

The most obvious founder is the solo founder who worked a long time on their own, took most of the risk, and owns the whole company. When they eventually hire employees, those people come into an established structure and are just there for a paycheck. Those employees didn't make an early contribution, they aren't taking much risk, and don't have ownership, so they're clearly not founders.

It gets fuzzier when you have more people, especially ones who didn't all start at the same time. If two people bump along for a while and add a third, can one call that third person a founder? Often I'd say yes when that third person made key early contributions, took a lot of risk, and was rewarded with a significant percentage of the company. They weren't there at day 1, but they still joined before the company had significant investment or traction. Without them, the company really wouldn't be the success it ended up being.

An example from my own life: I was one of 6 people who were there at the beginning of Sidereel. I spend a couple of months with them defining the product and writing a lot of the early code. But then I left to do other things. Was I a founder? I say no: I was there from the start, so I made an early contribution, but by leaving I passed on the risk and the ownership.

It's good that you know what you want, but I expect that here you will be constrained by the market. I've been involved in startups a long time, and I have honestly never of a developer who is not only being asked to work for no salary, but to buy in with cash. You may see it as "giving away equity for nothing", but they're going to see it as payment for work. "Please pay me so I'll let you work for free on my business that, as far as you know, will probably fail" is not a particularly appealing pitch to anybody who can turn around and easily get a solid salary.

Instead of buying in, the typical way this is handled, at least in Silicon Valley, is to adjust the amount of equity. The more value they bring, the more equity they get. The more valuable the company is right now, the less. The lower the salary, the higher the equity. Whatever relevant factors get rolled up into a single number.

Yes, you'll definitely want vesting. Hereabouts 4 years is pretty typical. For people joining later, a 1-year cliff is typical. But if they are coming in early and aren't getting salary, then I think it's normal to start vesting right away.

As to the actual amount of equity, there's really no guide for this. If you're before both investment and revenue, there's little objective data to say what the equity is worth. You can see noted venture capitalist Fred Wilson talk more about that here:

http://avc.com/2010/11/employee-equity-how-much/

I haven't watched it, but he also did a live class on the topic here:

http://new.livestream.com/Skillsharelive/MBAMondays/

You're approaching this the wrong way around. People don't join up because *you* want them to. They join up because *they* want to join. So you have to be talking about the latter.

You've listed a bunch of places to find designers with strong pedigrees. But those people are all a) doing something interesting and rewarding right now, and b) have plenty of opportunities. If you contact people like that cold with notes like what you've written above (demanding, presumptuous, randomly punctuated) you will have zero success. Zero.

Instead start talking about what you have to offer. Tell people about the great opportunity you see. Tell people how design will be key. Tell people how you know you can't do this yourself, and so you're looking to find and enable a designer to do things you can't imagine. Tell people about the money you've raised, the partners lined up, the distribution channels ready to go. And talk about it not to the designers directly, but to your friends who know designers. Because the people you are looking for will take you much more seriously if the opportunity comes recommended by a friend.

And if you can't do that, then yes, just go raise money and hire a designer. Co-founders are partners, almost family. Too many people say they want a co-founder, when really what they want is an employee who will work for free. If you want an employee, just pay 'em. Partnerships that aren't true partnerships end up a mess for everybody.

You're focused on the stick. What's the carrot?

This guy is giving you a great opportunity to figure out what his job lacks for him. And, perhaps, what issues other people might have.

It could be that it's time for him to move on. Sometimes we all want a change of scenery, and your company may be too small to provide that for him. Or it could be that you kinda want him to go anyhow. In either of those cases, in your shoes I'd give him a firm date at which he is leaving. Whether or not he has his next job lined up by then is not your problem.

But if you want him to stay, then I would work hard to make your company a place he's excited to come to every day. He may not really know why he wants to leave; we developers are not generally very introspective. That means you may have to spend a fair bit of time with him figuring it out. But if you can come up with some options, then I'd offer those as the reason for staying, and forget entirely trying to find a stick.

I'll note that studies show that surveys of managers and developers show different motivators and priorities when choosing jobs, so the things that appeal to you may not work for him. You may need to check with other developers for ideas. And I'd also suggest that your joint reluctance to have him starting anything serious is a sign that you could improve your process by reducing grain size and shifting responsibility from individuals to teams. That will help you not just in this case, but with the engineers who aren't so open about their plans to leave.

Personally, when I am cash-poor and time rich, my preference is to dig in and learn the basics of whatever it is that I normally would hire somebody else to do.

That's especially true with user research and user testing. Those are skills that any founder should have. As a founder, your number one job is to understand your customers, their problems, and exactly what it is about your product that works and doesn't work for them.

So I'd suggest you buy Krug's "Don't Make Me Think" and Kuniavsky and Goodman's, "Observing the User Experience". Read the first, and use the second as a resource. Then start doing that deep research yourself.

At some point you may reach the limits of your design skills, especially for thinks like interface or visual design. At that point, you can look at bringing someone in to help. But early-adopter audiences are frequently insensitive to design, so you should be able to get a fair way toward product/market fit before that happens.

Before I get to your question, let me give you a tip: always aim settle questions of payment before the work happens. It is ten times easier to agree on a price beforehand, and having done that doesn't stop you from changing it by mutual agreement later.

The problem with paying cash is pretty obvious: you don't have a lot of it. The problems with paying equity are subtler. The first one is that early-stage equity is extremely hard to value. A second is that equity transactions require a lot of paperwork. Third is that entrepreneurs tend to value their equity much higher than other people would; if not, they wouldn't be starting the company. And fourth, people like designers are rarely expert in valuing businesses or the customs of of startup equity valuation. In the past, I've both given and received equity compensation, and it's a lot more of a pain than I expected.

In the future, what I think I'd try is convertible debt. That is, I'd talk with the designer and agree on a fair-market wage. E.g. 100 hours x $100/hr = $10k. The next time we take investment, the $10k turns into stock at whatever price we agree with our investors, plus a discount because he was in before the investors.

Note, though, that this will increase your legal costs and your deal complexity, so I'd personally only do this for a pretty significant amount of work. And I'd only do it for somebody I trusted and respected enough to have them around for the life of my business.

My take: never solve a general problem. There are no general problems.

Individual humans have specific problems. If you spend enough time talking to individual humans, you will start to see patterns. Those generalizations are things you make up in your head, a convenient way for your brain to handle and incredibly complex world. They are false, but a pretty useful kind of false. They help you think and talk about the world, and can help you generate testable hypotheses.

So what should you do? Go talk to people about their problems, their annoyances, their frustrations. Just listen and ask good questions, without a lot of judgment. Eventually they will mention a problem where your developer-brain will say, "Oh, maybe I could help with that."

Which people should you talk to? Pick people you will enjoy serving, and pick a domain where you can make use of your strengths. I knew a guy who was working on software for printing shops to manage their workflow. His dad owned a print shop, and as a kid he worked in it. Right now I'm doing the user research for an app for medical residents; a friend runs a medical residency program and talked about a big problem they had. A possible solution fits with an interest I've had for years.

Once you've found the people and the problem, solve it for very specific people and a very specific problem. If you can knock it out of the park for them, only then look at how you can generalize the solution for other people, other problems. Google, for example, started out as an excellent search engine for stanford.edu pages, and then betaed as an excellent search engine for Linux-related web sites. Facebook started as a solution for one college, the one the founder was attending. Only when it worked there did it broaden to other colleges. And only once it dominated colleges did it expand to the broader population.