Ask HN: Should I validate a client's idea?

If you hired a contractor to remodel your kitchen, you'd expect him to give feedback on the design, materials, and construction of the kitchen, not speculate on the future resale value of the house. This guy is paying for a Web app, so take the money and deliver the app, giving him input on the design and implementation of the app. Let him worry about how to turn that Web app into a successful business.

This is the right answer but modified by an honest response to him when he inevitably asks your opinion on their prospects.

"I see challenges..." [and list them honestly, but don't overstate] is all you need to (and should) say. We've all looked at pre-successful businesses and thought they couldn't possibly work. Don't be so sure his will fail due to marketing requirements or any other shortcomings you perceive. Surprises surprise us all the time.

Client work doesn't always pan out this way though. They could see an unsuccessful business as an unsuccessful piece of technology. One that you the developer built. Of course large companies and established businesses don't deal like this but the rare individual whose got a lot of cash to throw around will bring the blame back on you.

I'd say tell them exactly what OP has written here. If they press on about it and you haven't got the bandwidth to educate them then perhaps connect them with a mentor or two. If the client wants to pay OP to help him make a successful business then I'd say that's a win.

If you do take on the client, be vigilant (and contractually bound) in what you provide. Don't go down the agile route. Specify everything to the n'th degree making sure you set out exactly what you'll provide. When his budget runs out and he still isn't getting the traffic he expects, your phone will be ringing off the hook as he thinks of fixes, amendments and tweaks that he'll expect you to do for free if there isn't a bulletproof design document to refer to.

Alternative is to have a very clear agreement about billing on a time and materials basis.

I second this. The contract should contain every little bit of functionality the client initially wants - from user registration to where the Twitter and Facebook icons will be on the homepage.

No, this is a terrible idea. It will be a huge and tedious effort, and it cannot succeed - you simply will not be able to write a specification that is watertight enough to prevent the client coming back and asking for changes. It will also eliminate any trace of the flexibility which gives the project even the slimmest chance of success.

The right approach is the exact opposite: make this a time and materials contract, where you bill every month for the hours of work done that month. He will be able to ask for fixes to things which are outright bugs (depending on how the law and the contract specify the warranty provisions), but tweaks or enhancements will cost him money. Using this kind of contract makes it very easy to stick to your guns over this.

If you've invented a way to conclusively differentiate between what is a bug and what is a change/new feature when you're talking to a client, the entire IT industry needs to know about it. :)

This answer is on point for sure.

This.

Don't ever go agile with a client you know up front has unrealistic expectations. Screw "customer collaboration over contract negotiation", you cannot collaborate with a client that isn't operating on the same level of reality.

This kind of client will screw you over the first chance they get, and the worst part is that half the time they won't even be aware of it.

If you can afford to say no, say no. If you can't, make sure you have a bullet proof contract, fulfill the contract diligently and then run.

Oh, and add a considerable percentage of overhead costs to your offer. Because even during the process you're going to be spending an awful lot of time explaining, negotiating and documenting everything.

Finally, check this client's network. If he has a lot of contacts and influence, and he can't manipulate you into doing lots of free extra work to salvage his project, he's likely to publicly blame you for his failure. One thing people with unrealistic expectations have in common is that failure is never their fault.

If you go the agile route you'd just repeatedly specify two weeks worth of features and implement them. When his money runs out, his changes run out.

Your phone ringing off the hook will only happen when he thinks he might get what he's asking for; which is a different problem altogether.

Generally I've learned to never dissuade someone from chasing their dreams, no matter how unrealistic I feel it is. I have learned to tell them what I feel they would benefit most from focussing on.

I should have mentioned this in the original question. I always work on a milestone basis. In addition to the initial contract, every piece of work is done something along these lines (obviously abbreviated):

Here's the work that I will do for this milestone. It will take me approximately x days and cost y.

I then get the client to sign off on that before commencing work. This make sure that I get paid for work that I do on a regular basis. If the client doesn't pay on time for the last milestone, then I stop work. It keeps everyone honest.

> I'm not sure that in all good conscience I can take on a project that is going to cost him a lot of money and not be successful.

Mind your own business. Literally. Every startup is a bad idea until it makes money. Then, magically, it becomes an amazing idea.

That said, yes, it will likely fail.

I have been in similar situations many times. An experienced client means very little, I assure you. They engage in similar stupidity, the only difference being that they will couch their nonsense as an "exploration" or "learning experience".

It's their money and they can spend it however they wish. My job is to deliver a product according to spec.

Now, I will politely inform them that based on my business acumen, understanding of the market, etc. that the success of their venture is extremely low. But that's as far as I go.

How do these projects end? Usually quite abruptly, when they run out of money. There is no hope of turning a client like this into a long-term client, because quite simply, they don't have any cash flow. They have cash, but it's a one time thing unless their business takes off, which it won't. But isn't that the definition of a startup?

> Every startup is a bad idea until it makes money. Then, magically, it becomes an amazing idea.

This is not remotely true. For example, Dropbox was not a bad idea until it made money; it was a brilliant idea with an unproven business model.

I think you're confusing stupid idea with bad idea.

Twitter was a bad idea. A stripped-down social networking site in a crowded marketplace ... unlikely to succeed. But succeed it did. Now it's a wonderful idea. But making a twitter clone now ... bad idea.

Now, a twitter clone with a 2 character limit, that's not a bad idea. That's a stupid idea.

I take on bad idea projects all the time, albeit with a warning to the client. I refuse to take on stupid ideas. I don't do crazy.

I see my job as not to just deliver a product, but to help my client be successful. If I do not believe that my help will help make my client successful -- e.g. make money, get investment, or satisfy a contract with one of their customers -- then I typically pass. An idea validation project is not good or bad by itself, but it is often followed with other problems with the project. For example, I have had first-hand experience with the following:

+ If a project is unsuccessful in a business sense, many clients will blame you, even if you deliver a perfect product.

+ If a client is bootstrapping with his own money (or friends/family), then the client will often try to get as much out of you as possible for as little as possible.

+ If a client does not listen to your recommendations and you feel it is irrational, you may find the client hard to work with.

+ If a client wants a "kitchen sink" product and often tells you things will be "easy", then the client may have unrealistic expectations for you too and/or continually want revisions.

Note that the core problem with many of these is that the client has a small budget and/or does not respect your time/work. If you can ensure that these are not problems, it is probably safe to proceed hourly/weekly but not for a flat rate.

Lay the cards on the table, and let him make the decision. It's not your responsibility, as a developer or as a decent human being, to stop other people making bad decisions. Indeed, making bad decisions is a vital part of a full life experience.

I'm reminded of the words of Daniel Kish, a blind man who has struggled against the wrap-them-in-cotton-wool approach generally taken in the raising of blind children:

> Running into a pole is a drag, but never being allowed to run into a pole is a disaster. [1]

Tell him about the pole, and about the pain of running into poles, but if he choses to run, don't try to stop him.

[1] http://www.mensjournal.com/article/print-view/the-blind-man-...

I've had exactly this issue in the past - worse in that the client was also arranging for third-party design and UX, and we were just to put together the technical solution.

Honestly, the best you can offer is advice - it's worth highlighting any particular problem areas that you may be able to help solve as part of the technical process.

However, at the end of the day, this guy's probably going to go ahead and build this app regardless of whether or not you agree to take it on. So the choice is a) it doesn't work, and you get the money or b) it doesn't work, and someone else gets the money. Sure, if there are going to be long-term ramification for you, of the "Hey, aren't you that guy who developed that awful website" kind, then maybe think twice. But it's realistically not your job to validate business ideas, and it's better not to even start down that road - because you'll end up sharing responsibility.

Just make sure that you're paid before launch!

"I'm not sure that in all good conscience I can take on a project that is going to cost him a lot of money and not be successful."

Love this attitude. There are too many people who simply don't care.

I agree with many others on this thread, lay the cards on the table (if possible with examples of your own apps and difficulties they've faced) and let him choose. Potentially also point him in the direction of a marketing/pr firm that may be able to help (ideally someone you're friendly with and can talk to beforehand). That way you're increasing the chances for him, reducing blame for yourself and paying forward with some work for a friend.

Good luck!

We deal with this sort of thing all the time. The best move, I think, would be to be very upfront about how competitive the particular market is and your thoughts on that. And be VERY clear about the scope and what he's getting from you. onion2k is right - when he's not getting the traffic he imagined, you're gonna be on the hook for the "fixes" necessary to make that happen.

The reason you are even asking this question on HN shows some moral obligation that you feel to do what is "right" in this case; whatever "right" may be to you. Due to this, I would present your concerns to him, and then accept the work if you feel comfortable with it.

A project like this seems to warrant an Agile approach; mitigating risk for both yourself and the client.

Me and my colleagues have created a company around validating clients ideas. So far we had some small projects and now are working on a bigger one. To tell you the truth it is fun, but it is more responsibility. The business part is the hardest, and takes more time then we thought.

But we are operating only few months, so it may be only the learning how to do business and communicate it that is hard.

Company web: http://6artisans.com

In this day an age, where Subway can make "artisan sandwiches" and Dominoes can make "artisan pizzas," you have the chutzpah to give yourself the titles like "Data Artisan," "Mobile Artisan" and worst of all, "User Experience Artisan."

I like the idea for your company, but the "artisan" angle ain't making me trust you. Instead it's making me laugh. Please take this as constructive criticism. I'm sure you folks know what you're doing. Just stop taking it so seriously.

Well, it is probably just language gap. I never heard of artisan sandwiches and pizzas ;)

Mmm, yeah. Totally a language gap. As long as you don't do business with clients in the US, you should be fine. See, there's this trend here to put the word "artisan" after everything to make it sound better (and charge more for it). It didn't sink in for me that you were European. My bad.

The key issue is: do you have ethical and professional obligations to a potential client. Or only to an actual, contracted client. Or not even then. Since you've posted this question, you presumably agree with the last two propositions.

So, you believe that you have knowledge that the client does not. And the lack of that knowledge will cause him to make a mistake. I would say that you have a professional obligation to advise him that the webapp is unlikely to succeed, but that this should not be used to override his freedom of action. If you explain your concerns and he still wants to proceed, then take the work.

The degree of any ethical obligation you might have depends on the harm that might be done to him by his failure. If he is wealthy and can absorb the cost of failure then, in warning him, you've probably discharged your ethical obligation too. On the other hand, if the client has re-mortgaged his house to pay for the app and he and his family would end-up homeless when it fails then I'd say you have a duty not to involve yourself. Obviously, the grey-area in-between is tricky.

If you don't think there is any ethical component to this then your decision will presumably be easier. I hope that is not the case.

This piece of advice only applies if you choose to go on. The main risk here is having your client blame your work for the likely failure of the app, even with no proper ground for that. Imagine that you propose some design improvement over his specifications, this could be (from his point of view) the reason why the app is failing! So stick to specs, validate and transfer the responsability of every design choice to him.

Lay the cards on the table... Eventually, it won't be good marketing if you didn't help you're client.

You can propose to create a MVP and just show screenshots of early twitter and facebook...

Say it will cost him less money and it will help him validate the idea. Show him some Analytics of some of you're apps.

Most people I've talked to don't understand the idea of an MVP and believe EVERYTHING they want in a product is an MVP.

Use Trello to seperate stuff if you're working with people who don't understand it... :)

Then notice that most of the stuff for the finishing product is in the current sprint backlog and explain that ain't a MVP.

Then start to filter stuff away for what isn't "required", the more you filter, the more it will become an MVP.

Last year we were contracted to do some IC verification work. The more we learnt about the system, the more we wondered, "doesn't this just duplicate existing successful products? What is the niche here, exactly?".

Meanwhile they ran out of money and didn't pay our invoices.

In my previous job, I made the mistake of joining an early stage startup as a full time employee with almost the exact situation (experienced founder with "if I build it, they will come" syndrome).

My advice is to pass on the opportunity from the technical implementation side and pitch some business consulting instead for a reduced or nonexistent fee. Then you can accomplish the following:

1) Help him out and not leave him completely hanging.

2) Remain engaged in case his business does take off and you gain enough confidence to take on some technical work.

3) Pass along the work to some contacts who might enjoy the technical work more than you would.

I was in a similar situation and I laid down the cards. I think I did the right thing by doing so and the client will reevaluate the viability of the concept as they said.

As everyone seems to agree, you're being contracted to build a web app for the client. The business model and marketing behind it, is essentially his challenge.

> I'm not sure that in all good conscience I can take on a project that is going to cost him a lot of money and not be successful.

No one can ultimately say a project will be successful or not as there have been good ideas that died, and bad ideas that took off.

Take the money, build the best web app that you can build.

"I honestly don't have the time to get more involved"

So don't. It sounds like you have quite a bit of work landing at your door to make the above claim. If that's the case then choose to work on the projects that you feel have the most potential to succeed. Doing so will, assuming you're correct, build a better portfolio and reputation for you, which will then lead to more opportunities and better pay.

This might seem like a strange response, but I think it depends almost entirely on what kind of person the client is. Are they the type to admit their own failings? Or are they the type who thinks everyone else is an idiot? The former will accept the failure of the app for one of the many legitimate reasons. The latter will blame YOU when they don't get rich instantly. Be careful.

Learning to present your opinion properly is an important skill. It's tough to know what will work or not, even for the most experienced people in Silicon Valley. One time, I thought an idea was garbage and the market oversaturated, their initial launch ended up receiving a ton of press and traction.

Yes. Do your due diligence & be up front & honest. Also prepare to have a 'backup' plan (other peson/people) in case he still wants to move forward

Yes, lay the cards and let him make the decision. But, as others suggested, be very clear (in writing) what he is going to get for his money.

What is your web development shop's URL? You may get some business ;)