1. Are you willing to pay my normal rate?

2. If so, can you convince me the market is there and you know how to address it.

3. Can you convince me _you_ are the guy who's going to be able to bring it all together?

I know that after rule 1 I shouldn't care, but with so many potential projects out there, I like working on ones I think will amount to something rather than spending two months coding and then having it all thrown away. Call it a personal satisfaction thing.

Fundamentally, the rules amount to equity isn't tasty.

You likely setup the entire system so if something goes wrong, whether its you're fault or not, you're on the line. It's all about reputation. And if you tarnish that by leaving a paid client behind when their server catches on fire, it will be remembered negatively.

It's hard to do this type of contract work continuously. You build up a portfolio of apps that you have to maintain. Most of the time you're clients are out of cash.

Equity is great but it doesn't put food on the table today. On the other hand it puts you in contact with some really great ideas and you get to play startup founder several times and you gain enormous perspective on what works and what doesn't.

Always charge. People will respect you more, and any work you do for them for free will be abused. This is simple human nature - when you give away work for free, all you are creating immense confusion in the recipient. "Why did I get this for free? What's wrong with it? Is this guy so desperate?" This line of reasoning will quickly blossom in your clients mind, and before long your client will expect you to get up at 3am in the morning to add in some new feature he just dreamed up. When you refuse, his expectations of you are shattered and you will be remembered negatively - even when you just gave him free work!

Always charge. The less you need the work, the more your charge. The less you want to do the work, the more you charge. The more difficult the work is, the more you charge. No freebies, unless you make the reason extremely clear up front to prevent any confusion.

The other correct response is "We can agree on a monthly retainer of X days for maintenance."

I try to avoid fixed cost projects, especially in early stages when specs are likely to be very fluid.

There is also the excellent resume and street cred of working on a successful startup, possibly with name recognition, vs a 'failed' one.

I've done consulting, startups, and free work on side projects. At this point, if I find people and projects that meet my requirements, I'd probably prefer to become a co-founder and make a real go of it. I don't think I've ever taken a small amount of equity as compensation for substantial unpaid development work. Under those circumstances, equity is not tasty. I'd rather do well-paid consulting work or find a great team and go all in.

Honestly, I just find working with startups and small companies in general to be more interesting, even though there is usually slightly less money involved. I got into this type of work by hanging around Hacker News and writing blogposts aimed at a hackerpreneur auidence.

It's amazing how many great projects you can attract if your writing is half decent and you have a good idea once in a blue moon.

As for jumping full in, yeah I'd love to eventually, but I've learned to be cautious and cover my bases first. Maybe when I have money saved up so I don't have to earn anything for months on end. Being young has its disadvantages.

For instance, a developer could quote Price X to non-technical co-founders to develop a simple, proof-of-concept MVP with an agreement to would receive Equity Y upon completion if the developer either (1) stays on for Period P or (2) helps the founders successfully land a more suitable, long-term developer to take over the project. The parties could even agree that Equity Y would be larger (e.g. 2Y) if the developer stays on.

Benefits to the non-technical co-founders would be (a) a proof-of-concept (or failure), (b) alignment of incentives with a developer to try hard, and (c) access to an insider to help find a permanent developer upon completion of the MVP if the MVP developer wants to exit (e.g. for a better opportunity).

The benefit to the developer would be (i) guaranteed fees, (ii) potential for equity (even if he exists) and (iii) flexibility.

More, a subsequent developer would have the chance to deal with someone who speaks his own language in the negotiation with the non-technical cofounders, and could avoid and annoying and/or exhausting translation of technical details.

An obvious objection may just be that non-technical co-founders never have money to pay for an MVP. I am far from an expert, but I would think that some do.

The options for a developer in today's marketplace are such:

1. Technical founders who can offer equity only

2. Technical founders who can offer equity and money

3. Technical founders who can offer money only.

4. Non-technical founders who can offer equity only.

5. Non-technical founders who can offer equity and money.

6. Non-technical founders who can offer money only.

In either type of founder, the best option for a developer is equity+money, if they can afford a full-time commitment.

If the founder can only offer equity, this raises the stakes significantly and is a problem. Especially if the founder has overlapping skills with the developer. But the overlap of skills also breeds a certain camaraderie that is not to be ignored.

If the founder can only offer money, that makes it a clean [probably ongoing] contracting job with the flexibility to work on separate projects and whatnot.

The real problem with equity+money is that you are roped in full-time and tied down for an extended period of time. The reason I personally got into freelancing instead of having a normal job is that it gives me the freedom to change projects frequently - every couple of months. I advance quicker as a developer, grow my network quicker and my life is more interesting.

Knowing that I will spend the next 2 years working on a specific project is a very big commitment indeed and I want to be damn sure it's something I am extremely passionate about. (hint: this is usually reserved for my own ideas)

Perhaps it's just a sign of the times that I am happy taking on clients with no more than a few months' commitment and be certain that my bandwidth will always be filled to the brim for the foreseeable future anyway. In fact I am strongly thinking about expanding myself into a small team just to keep up with demand.

PS: there's also likely a bunch of legal and tax hassle in having my consulting company or myself be part owner of a bunch of other companies.

That got zero offers.

To be your cofounder you must also convince me that this project is something I want to spend the next several years of my life on and it must be great enough to convince me to drop other projects and start working on this full time. I don't believe in part-time cofounders, that way lies burnout and failed projects.

And despite all that, equity still isn't tasty so I will need to earn at least some of my normal rate anyway.

I guess you're saying that you'll only build MVCs for cash, but then will consider joining as a cofounder afterward if the project looks promising and you can work out a fair equity agreement?

But building a MVP together before jumping into a full blown partnership is also rather important in terms of finding whether there's a general fit in working together, you're actually able to deliver on the non-technical aspects of the project and so on ... MVP's are also incredibly good at confirming assumptions about the market.

This is the part about equity that is most likely to bite you in the ass if you receive equity but ultimately do not control the allocation of it. (Common for early employee or founders on the technical side of things).

Day 1: Awesome, I own 10% of this company. If it sells for millions I will make a significant amount of money!

Day 630: Due to the "almost infinite" nature of equity and dilution, I now own 0.05% of the company. If it sells for millions I will be able to buy a cup of coffee!

Smart, experienced founders would rather spend money than equity on anything other than a top quality cofounder.

It takes years to reach a reasonable level of competence in software development and on the order of a decade to master it.

The problem with taking people's word on how much work they do when they are involved in marketing and the soft sides of business is that they have a disproportionaly (as compared to tech specialists) large amount of experience in marketing, negotiation and soft skills. Hence, they market themselves and over inflate how important their contribution is. In my experience.

I tell the person to sketch out the how a user moves through the app, what they can do where, and how it should work. I even tell them to sketch out something basic with powerpoint.

If they make it through those stages, it does two things: First, it demonstrates that they're relatively serious about the idea. More importantly, it lets them get a bunch of the oddities, inconsistencies, etc figured out before there's code involved. Making radical changes at that point is File->New.

You're absolutely right that this isn't scalable, but if you're just looking to validate your idea why shouldn't an app made by someone with a few months of experience suffice? Once you've proven there's value in the idea with the prototype, I imagine it'd be a lot easier to get more experienced developers on board.

* we already have a working product

* we might aswell just add the features and visual polish we need and then launch as soon as possible

* we have too much work to do to rewrite it

* we can't refactor effectively because automated tests are mostly missing

This results in the project becoming increasingly burdened with technical debt, where it becomes impossible to add new features without breaking something. The next step after this is usually a rewrite (which, given the low quality of developers already in the company, since nobody sane will work on such bad code, is also likely to fail, unless IT is restaffed completely).

If the prototype is binned outright and the rewrite happens at the very start, I imagine that this can be avoided. Again, the trap here is that if the founder learned to write code in 6-12 months then they will be in that cute phase where they think that programming is easy and will not realise this.

In short, having a senior developer on board (at the very least as a consultant) from the very start appears to be mandatory for long term success and minimisation of headaches. It's just what I've seen in the real world. Companies which went for quality from the very start grew rapidly. Those which attempted to minimise development costs at the expense of quality did not reach the heights.

They claimed it would take "a really long time" to rewrite everything. I can understand a junior developer thinking that (it apparently took them 2 years to create the code they were using at that point). But using good engineering practices, building a site that did what they needed could have been done within a few weeks using Django and MySQL. Its really hard to make this point stick when you're dealing with developers in that "sophomore zone" of programming ability.

Needless to say, they told me "no way jose". I ended it with them right then and there. I can't tell you how many times I've seen that happen.

If it's a cat pictures site maybe a few months is enough to learn enough code to validate the idea. OTOH if you want to build a search engine maybe not so much.

Is this a bad idea? Would like to hear your thoughts. I have to admit I do feel like I'm in a little bit over my head, in that once/if I start getting a lot of users, I really have no idea how to scale this thing. I figure I need to start networking to find a brain that wants to team with me.

I'm glad I've learned to program though, even if at a beginner level. If this fails (I already have a previous project that was a resounding failure), I can test out new projects easily.

However if you've fought even the initial stages of the battle yourself, you understand the idea of the vision, and the reduced scope which is your next step toward the larger goal. Further, we understand that the part of the learning curve you're in right now is the steepest, and if you're willing to endure it you're either stupid or you really do believe in your business.

haha, I'll refrain from trying to answer that for now ;) You're right in that by far the most challenging part of the learning so far was the first day, and trying to get rails working on a Windows PC. For a person with no technical background, it takes a huge amount of persistence or stupidity to get past that stage.

I actually learned to program so that I'd be in the position to build my own MVCs. The idea came to me as I was learning.

I don't have a lot of money, so I figured the only way to win over a good developer was with credibility (an actual product that at least somewhat works and has some traction).

A cheaper (no money but more time spent) alternative is to use forums and IRC channels to get advice. There are plenty of knowledgable people who are more than willing to help if you ask.

Some basics which are vitally important to cover are ensuring that the object model and database schema are solid and extensible, that there are automated tests in place (especially for business critical functionality), that everything is documented (otherwise you will waste inordinate amounts of time explaining how things work to any developers you hire in the future and/or relearning parts of your own code after forgetting what it does) and that everything is backed up to multiple locations. Addressing those concerns puts you well ahead of the pack.

It's so tempting to keep build quick and sloppy, but I know I need to be more diligent with testing and documenting.

I'm setting a relatively low target number of users to acquire just to make sure this idea has a chance, before bringing on a developer.

Very broad question, but how does one find an experienced developer? I live in New York, but have zero tech connections.

That's normal when you're starting out. The only reason more experienced developers do not give into this impulse is because they've learned of the consequences through painful experience.

I would recommend looking at the people who contribute to Rails, Ruby and related projects on Github. The core developers will be far too expensive but people who throw some code out every so often (assuming that their pull requests are usually accepted and nobody is shouting at them in the comments) will likely know their stuff and may have reasonable prices.

IRC channels on Freenode such as #ruby and #rubyonrails will likely prove useful too. Look out for people who answer a lot of questions (and get them right). One strategy is to try to design a solution for a feature by yourself, then summarise the design (i.e. show the relevant code snippets) in a Github Gist or pastebin page and ask for feedback. If there are any glaring faults or simply better ways to achieve the result then they will be pointed out to you.

Actually, beautiful women are hardly rare. But it's the qualifier that's important: "models I can date??"

Good developers might be rare, but they're not hard to find. They are, however, hard to woo. You know the drill on how to woo them, it's just inconvenient/hard/expensive. But at least it's pretty well laid out.

One of the things which good code and inline documentation (comments) do not communicate very well is a high level overview of the architecture of the application. In my opinion, it is better to describe such things using external documents and diagrams.

The same goes for the deployment procedures and the way the servers are laid out as well as dependencies. For example, the place I'm currently at had no documentation what-so-ever for the libraries and modules necessary to run the in-house web application and, consequently, it took us more time than it should have to figure out what needed to be installed when we moved to a new server.

Thanks for the book recommendation, seems like a great one judging by the reviews. It's always useful to learn more - will add it to my 'to read' list.

Damn, ideas are never bad. As long as you do stuff, it's all good.

I suggest reading up on memcached (since you're using heroku).

However... I would like to start building out some of those "annoying itch" ideas I have been sitting on and feel this enables me not only to prototype those out, but also allows me to have a half-intelligent conversation about my idea with someone who is a far better dev than me.

Oh man, I can't tell you how much instant respect this would gain an "idea guy" who contacted me for development. If you've already tried to prototype your idea, it would tell me that not only are you dedicated, but you will also not underestimate my contribution to the endeavour.

Are you saying you are only capable of implementing one idea? Then maybe you should work on that, instead of taking offense at other people learning something new.

Would you say that to a lawyer? To an engineer? To an athlete? To an artisan? So why do people say crap like that about programmers all the time?

Programming might be easy, but programming a product you can sell is hard alright. Let's stop pretending programming is sitting in front of an IDE and typing something that compiles/runs, in the same way we pretend anyone who operates a DSLR is a professional photographer.

   http://norvig.com/21-days.html

And by "something", I don't mean code (nor the idea, but there are things beside those). Seriously, I'm a developer, I don't give a damn if my potential cofounders could code or not, that's redundant. I would look for someone who has what I can't easily get. Someone having an accurate view of the state of an industry, or being nosy and/or well-connected enough to be able to get this view. Or someone some marketing/sales skills. Or someone with some proof that people (preferably people with money) are interested in the product.

So if a developer comes to me with an idea, I can evaluate the partnership better- it is less risky then to go with a partner with complementary skills (not saying it's better to do it, it's just easier to figure out what you are getting into)

If you can define precisely what you want, then you will have much more hope in recruiting developers.

Why? 1. The lack of ambiguity of the scope gives developers the opportunity to determine their costs with some accuracy. 2. The requirements define the benefits of the project. Either the developers are convinced your logic is correct, and therefore will make money, or they do not. The former lot are those that you can convince.

infinite ideas vs. limited time

There is an unlimited amount of ideas out there, so these are not the scarcity at all. So they are pretty cheap.

Being able to execute them is the big thing. The ideas that sound really worth something, like patents are created by the Engineers themselves with an incredible amount of work.

Why should anybody care about your shower idea?

This also annoys me about the "idea guys", they are often incredibly simple. They didn't do any market research to validate anything, or thought about all the possible risks.

When somebody comes to me and says: "I had an idea and spent the last 2 months doing research about it. So I modified it and now have something where I am pretty confident there is demand for it."

This is something I would take serious.

I think the best thing a non-technical founder can do is follow lean principles and bring actual data to the table. Show they've actually done the research - MVPs, letters of intent, etc - and make it clear they have a vision they can execute on. All of that is in the realm of possibility for someone who's not a programmer, and would help to make the case they're serious and capable.

A chicken tells a pig that they should start a restaurant together. The pig tells the chicken no. "Why?" asks the chicken. "Because you'd be involved, but I'd be committed."

Revenue share is a great idea, but there's no way I'm working on your idea for free while you just sit around and wait for me to make you money.

If someone comes along with a great idea and suggests a revenue share, reminded him about the old truism that the idea is 1%, while execution is 99%. At least that will give you a starting point to negotiate the percentages of the revenue share...

Maybe if you are getting approached by morons a lot you might want to review where you are hanging out - just there mus be some reason

- They cannot pay my rates.

- The client seems shady.

- The team/person will not agree to my terms.

- We have a chemistry clash.

- Red flags regarding the way they talk about people.

But good ideas are quite rare.

"...and i think it's not that complicated"

"...it shouldn't take more than ... to complete"

"...Joe Blow said it's simple and let's assume that"

But then I think that nearly everyone has a tendency to think that anything they don't fully understand must be simple.

You don't have to hang around here or on Slashdot for long to see that programmers suffer from this too...

I often get requests of ideas but they are so hard to execute that you would need a bigger team to do it and a lot more money then the idea holder has...

I wrote a post covering 'Business Product Responsibilities' with a graph here: http://simplyryan.com/2013/01/19/business-product-responsibi....

I have found that I don't want to work with non-technical founders because they often don't take ownership of their responsibilities.

For some reason developers/engineers tend to be pessimistic while leaders/idea people tend to be optimistic.

In order to produce really great products you probably need both sides -- so don't dismiss the "idea guy" without giving the proposed idea at least some thought. Perhaps the original idea is too broad but can be the basis for a useful product.

I'd add underestimate the cost of a decent final product to that too.

I want to work on my idea - and that's hard enough

You have included 4 weeks of holiday, but not sickness, training courses, conferences, company admin, next contract sales and worst of all bench time between contracts.

My calculation are you are down to 45 weeks after 5 weeks holiday and UK bank holidays. Add 5 days for illness, 7 days for courses and conferences, 1 day a month for admin, 3 days every 6 months for sales, and suddenly you are down to 39 weeks. Add at best 2 weeks of bench time as lining up new contracts perfectly is tricky and you are down to 37 weeks.

£350 * 5 * 37 = 64,750 before tax.

Then it is the whole consideration of whether you are within IR35, which basically taxes you more than a normal employee, and is very difficult to not be within if freelancing on longer contracts in the UK.

Then accounting, insurance, hardware costs etc.

You would have to be on some real long term contracts without benchtime, no illness, no training and no expenses to get towards you numbers.

Working in Shoreditch myself I know most of the decent developers with 10 experience around here are earning a lot more than a contract guy would make on £350 per day.

Freelancing is different. You have to deal with all of the issues you mention above, cost of sales etc (though, get yourself an accountant, seriously) but the reward is higher. You're doing things at your own pace and if you're good you can really focus to make solid profit.

Contracting is just a regular hourly wage (and as you rightly point out, not always as good as it looks on the tin).

IR35 is a good point. If you have multiple contracts and don't work in any one place for more than two years you should avoid any questions around if it's really a contract or not. Most employed coders I know hardly stick around in a place for more than two years here in London.

Also who gives a fuck about money above 50k GBP? If you're young work a cool job, meet interesting people and learn lots of new stuff. Freelancing is almost never that. Working at a startup is, provided you pick the right one.

Not my experience. Freelancing is what you make of it. To get some experience you may do some boring stuff early on, but if you've got no or little experience your 'startup' will likely fail.

90% of the freelancing work I've done over the last few years has generally been 'learning new stuff' and 'meeting interesting people' in somewhat challenging problem domains (trucking logistics, education, etc).

"Working at a startup is, provided you pick the right one."

Freelancing is what you make of it. Find interesting projects.

Now, since (good) employers often manage to look past a lack of credentials and connections, I was able to get a great job at a YC startup (run by entrepreneurs with past successes/exits). They're taking a chance on me, which almost never happens with freelance work (especially not if there's a dude with 10 years experience competing with you).

And also I would argue that is much easier and quicker to find a good startup (just go down the list of YC companies) than to find amazing freelance work.

I'm suspecting that you had a hankering to work at a "startup" and that colored your behaviour. I know many people without any major credentials who are doing just fine in freelancing, making good money doing what they like to do.

Never bother with odesk - you wouldn't have gotten a YC-startup gig on odesk - why look for anything else there? Work your network/connections - if you don't have any, build them up - that's what takes time and effort.

I also suspect many people on this forum (and on specific topics) are 'startup' focused. While there's nothing inherently wrong with that, I do feel it sets a lot of people up for failure ("fail fast! fail often!") when many of them aren't psychologically or financially prepared for so such failures. We rarely read about the failures of people who attempt 'startups'. Even when we do, it's often a post-mortem look from someone who's now writing from a position of success, reviewing their own failures in public for others to see. The implicit (sometimes explicit) message is "see, even if you fail, you can be successful later in the same space".

Good luck to you on your journey.

>Work your network/connections

That's exactly the issue. I didn't have that. At all. Before that I just hacked on stuff because I thought it was fun / interesting. I also came from a tiny country without a tech scene.

>I'm suspecting that you had a hankering to work at a "startup" and that colored your behaviour.

I do love startups. But I before starting my job search I spent about a month trying to figure out freelancing. In the end I decided against it (for reasons listed above) and went onto what I -- at the time -- considered the second best option: employment.

It was a great success. Instead of trying to cold-email people for dev-scraps that are so un-important that they'll let someone with no degree and no industry experience and no references work on it vs. someone with a CS degree + 5-10 years of industry experience + heaps of people with impressive business titles who can recommend his work and doing whatever crappy work I can get my hands on just to "work on connections", I now get to work every day among a set of incredibly smart, compassionate, warm, successful people who want to invest in me and want me to become the best programmer and contributor that I can be.

That's why I chose the employment route: Once you're in, you're in and you can focus on what you love and growing yourself instead of constantly having to worry to put food / contracts on the table.

If my math is right, that works out to about $70/hr (USD), which is well on the low side for a 1 year contract, even assuming you're out in the sticks. That's closer to what you'd expect for a day rate as a salaried employee if you have any experience.

So no, you need to take on board that this is the sort of money you should be making. If you're not (and by assuming that only magical freelancers make that much, but only for a few weeks at a time, it sounds that way), you'd be well served to spend some effort getting your rate up where it belongs.

We'd actually all be better off were you to do so. As long as there are people willing to work for GBP65k/year, there will be companies taking advantage of them. But those same companies will happily pay market (as plenty of us can attest) if they have to.

Money doesn't motivate me. I thought it would. Made a bunch of money (much more than me or anyone I knew made) doing IM stuff. Turns out what I really wanted was interesting peers, people who I could become long-term friends with, learn from and share experiences with. Freelancing doesn't offer this, finding the right people and working with them at a company however can.

>But those same companies will happily pay market (as plenty of us can attest) if they have to.

>market

You use the word market as if you knew what it meant, but apparently you don't. Developers being happy to accept lower rates than what they could make freelancing means there's some mysterious, secret value-offering that becoming part of a team offers humans. For a lot of people that's stability. Or because becoming an employee is the "normal thing to do". For me it's much more. And I imagine for many of the most brilliant programmers who are alive today (of whom almost none earn their living as freelancers) as well.

This has not been my experience. I've been doing this for years and I don't think I've ever spent more than two weeks looking for a gig. Even during the current crisis the market is great for developers (here in Denmark at least).

These projects have typically lasted three or four months. That makes me enough money to live off for the rest of the year which I have then spent travelling and working on my own projects.

Someone with 2 children in private school.

If you're a consultant, spending time establishing thought leadership etc etc then yeah, but you'd be crazy to work for 350 per day in that case.

£350 * 200 = £70000 before taxes, I think £84000 is overly optimistic here.

Also, which startups here in the UK give you 12 weeks off a year?

I think I worked more than 200 days in the end, but I like to calculate pessimistic and be positively surprised at the end of the year.

OK but then also maybe forget HN and entrepreneurship?

I have met some talented developers who are keen to build a business of their dreams. I'm glad they're doing it as (1) they are trying to reach their goals in life and (2) they aren't competing with me for work :)

So far it is going fine. I think that this approach will see a lot of interested developers.