Dear [Under-Capitalized Business-Guy who wants me to work on your site for 'equity'],

Thanks for taking time to meet today. It was interesting to learn about what you’re doing.

I’ve put some thought to what you’re trying to do and I have to be honest, I have some reservations about it. The business model itself may work, though I don’t know that much about the kinds of businesses you’re hoping to get as customers. But the very rough proforma you’ve put together gave me a bit of pause.

I appreciated that you’ve had the foresight to put together some financial modeling — that was reassuring. But it concerns me that you felt you could somehow spend only $50,000 on developer salaries over a 5 year period. And while I understand that at this point the numbers are all pretty rough, it just seems way low for what you’re trying to do.

A single developer (one with the skills to handle all aspects of the site, build it and keep it running, backed up and responsive as your customer base grows) would cost a very minimum of $75-80K/year (plus benefits, etc.) For $10,000/year you might be able to hire a single person at far less than half-time. That’s to me just so unrealistic as to be almost impossible. I can’t imagine it. You can’t build a software-based company without software developers. To realistically handle what you’re trying to do would likely require an ongoing staff of 2 or more people once you got to 2-300 or more customers using the application.

And if you can’t find someone willing to work for free I’d recommend a budget of closer to $50K to have enough to get things live with a decent design and cushion for when things go wrong — which they will.

But given your current funding level you probably can’t afford that. So what I’d recommend is finding a ‘technical co-founder’ that you can partner with. The only appropriate thing to do, though, would be to be up front that you don’t have money and are looking for a co-founder — and provide co-founder-level equity participation for their efforts (meaning probably no less than 30% ownership). Otherwise you won’t likely find someone with the level of skill and experience to make this thing work. You have sales experience and the idea, and that’s worth a lot.

But either way, given your current unrealistic expectations regarding cost I don’t think I can in good conscience refer you to contacts of mine as a potential partner. I wouldn’t feel right about it.

Maybe we can get together in a couple weeks and talk about where you are. I’m happy to meet and provide what guidance I can over coffee periodically.

Best of luck,
Kevin

I completely understand the issues behind the story and I agree — it’s much easier to create a new instance on AWS than it is to understand how secure it is. A lot of people have the skills to create instances; fewer have the skills to ensure they’re secure.

This, by the way, is one of the reasons I really like deploying Rails applications on Engine Yard.

When you create an instance on Engine Yard, here are some of the security features you get:

• It’s impossible to ‘ssh’ directly into a system with a username/password. ‘ssh keys’ are required.
• You can only connect to the machines as the ‘deploy’ user — not as root or any other user.
• Once you login, you have sudo access and can swith user to root, but only after you’re on the machine already.
• To enable ‘ssh’ connection for a particular user, you have to log into the Engine Yard admin panel and upload the user’s public key then specifically authorize them on a particular instance.
• The apps in the stack (passenger, rails, mysql, postgresql, etc) are run under accounts with restricted access.
• The database passwords only exist on the instance and are generated random strings.

This isn’t to say that they’re perfect, but I think it does say that a good deal of care has been taken to make sure the instances are secure. Most of the examples in the article were from users who were inexperienced or lacked the knowledge to secure their instances.

I once worked with another customer who deployed their applications using a different (yet commonly used) deployment tool. It created their instances using one of the popular Ubuntu-based AMI’s.

There were a number of security issues with the implementation — primary access to the instances was done using ‘ssh’ with ‘root’ as the login, the database accounts were setup with no passwords, etc. Not that the tool they used didn’t allow these things, but they took extra time to implement and the person who’d set it up hadn’t done so.

From the site:

“BarCamp Boston is Boston’s geek unconference, organized on the fly by attendees, for attendees. Visit the website and wiki at BarCampBoston.org. There is no registration fee, and all attendees are equal… but you don’t just attend a BarCamp — you can participate in discussions, host a session of your own, or join in another cooperative event (startup founder match, programming contest, design competition, and more…).”

Link:  BarCamp Boston 6 at 1 Memorial Drive, Cambridge, MA – Conferences,seminars on Plancast.

I really loved this blog post. It hits the nail on the head for a lot of reasons. The writing style is good and catchy. The content is real and valuable. It’s worth checking out if you’re looking to develop income at any level for your business.

I’m using it for some work I’m doing with a client of mine (Practically Green – a great little eco-startup) and ran into an issue with how it created callback url’s — the url where the user is redirected after the Oauth authentication is completed.

The issue was with the way our web listeners are proxied back to the rails application servers. Behind the scenes, the rails application servers have a host name of something that’s not really a valid domain name (say, something like ‘railsserver’).

Omniauth was grabbing this value from the request object and forwarding our users back to an Oauth callback url like ‘http://railsservers/auth/twitter/…’. Obviously, this isn’t what we wanted — the Oauth callbacks were failing.

After digging through the Omniauth code, I ran across the offending piece of code:


 def full_host
  case OmniAuth.config.full_host
   when String
    OmniAuth.config.full_host
   when Proc
    OmniAuth.config.full_host.call(env)
   else
    uri = URI.parse(request.url.gsub(/\?.*$/,''))
    uri.path = ''
    uri.query = nil
    uri.to_s
   end
  end


Basically, if this config paramerter :full_host isn’t set to either a string or a proc, omniauth pulls the uri from the request object — this is where it was messing up.

Since the Omniauth config object is a singleton, I just set that parameter in config/initializers/omniauth.rb like so:

(in config/initializers/omniauth.rb)
# Set the default hostname for omniauth to send callbacks to.
OmniAuth.config.full_host = "http://practicallygreen.com"


With this, the full_host param is a string and now the redirects are always created to come back to where we want.

One of the answers, though, I think got it all wrong:

“Selling the engineer on the vision is key, but it doesn’t need to be the same part of the vision that you think is exciting. You may have to frame it differently in terms the engineer will understand as valuable to their learning and reputation as an engineer.

Want to eliminate third world debt through micro-finance? Ok…that’s great but might not excite an engineer. It involves implementing a machine learning algorithm to arbitrage risks based on someone’s social graph? That might be a wee bit more exciting for an engineer to implement.

Finally, just get them to help you with a very small part of the problem. If you can get them to write a few lines of code, odds are a good engineer will not be personally satisfied until it is a 1000 line elegant solution. At that point, they have sold themselves on the project.”

I have to be honest, I’m not sure I agree with this approach. It may work to sell some engineers, but not the engineer that can bring your vision to reality.

‘frame it differently in terms the engineer will understand as valuable to their learning and reputation as an engineer.’ – this is just not accurate. An engineer capable of bringing your vision to reality needs to clearly see *your* vision and buy into it. If you get them excited about a technical solution that they think will make them more valuable, what happens when the technical solution needs to change? Are they still bought in?

You and the technical founder need to be aligned on what the vision and the value are. And a good engineer for that stage in a business’ life is one that can see your vision and also see the way to make it real.

And this sentence to be honest is a bit insulting and niave – ” If you can get them to write a few lines of code, odds are a good engineer will not be personally satisfied until it is a 1000 line, elegant solution.”

A good engineer is satisfied when the solution fits the problem, not when they have a 1000 line elegant solution. Engineers that ‘over engineer’ in the name of finding elegant solutions will kill your startup.

It’s better to enlist them as a full partner with the whole team focusing appropriate levels of resources to achieve a clear business end. Great engineers are those who can do that. And they exist.

1. Raises were based more on how the company was doing rather than individual contribution. I remember one year my entire department was given a 4% raise. Everyone got the same regardless of how hard they worked.

2. Risk taking was only rewarded if things worked out for the best. Trying a new technology that ended up not working (even the failure didn’t impact delivery schedules or business goals) would result in a negative at review time. It encouraged people to not suggest new approaches or technologies in case they didn’t work. It was great for people who played it safe and didn’t try new things.

3. Management was always working to reduce development cost — meaning they worked to outsource our work if they could. I was in a meeting once where the CIO told my team he could probably outsource our work to a 3rd world country for 10-20% of what he paid us. What an ass.

On the flip side, many of the people I worked with are still there and have had stable salaries and good benefits in a job where they didn’t have to work that hard for years at a stretch.

I guess what’s best depends on what you want from your career and how driven you are to create new things and work on the edge of technology. Personally, I work now with startups and love that I’m always on the edge of what’s new.

The challenge is that thinking 3 steps ahead too often will get you into trouble as you can lose site of the things you need to execute on today.

I’ve always said the hardest thing in business (especially in a startup) is to ‘execute effectively today while also building tomorrow’. Most people have it in their nature to do one or the other.

To be really successful, you need to do both. At the same time.

If you’re going to be a co-founder and receive equity on par with the other co-founders, it seems appropriate that you should receive income on par with them as well.

In other words, it depends on how much cash is available. ‘Co-founders’ that get significant ownership should receive similar ‘salaries’ initially.

So rather than think of things in terms of how much of a discount against salary you should ask for, I think it would be more appropriate to think in terms of what you bring to the table — and what the others are bringing. Then, see what cash is available for you all to share.

If you want more cash than others, then you should be prepared to get less equity. Some technical co-founders take no salary at all in return for more equity.

Co-founders that bring money to the table in addition to time would be right to ask for a greater equity stake.

To begin with, I’m not sure I agree with the premise of the question, in general.

If you want good solid work and it’s early, then pay people or make them cofounders.

Offering them a revenue share later (assuming revenue shows up) is problematic for just the reason you’re asking — what do you do if the revenue doesn’t show up?

Trying to find programmers willing to work for a promise of a share of potential revenue is likely to attract only programmers who can’t get a better deal. In other words, if they were really good they’d either be co-founding something or getting paid well for their skills.

Bottom line — either make them ‘co-founders’ or pay them. If not, you’ll increase your potential to attract people with nothing better to work on.