
Ask HN: Should I validate a client's idea? - JonoBB
I run a small, but successful, web development shop. We have recently been approached by a potential client to build a web application for them. Its a reasonably sized project that will take a few months. There are no great technical challenges in this project.<p>The app will be entering into a very competitive marketplace, with a slightly different spin. However, the founder has almost no experience of web development and what it takes to get an app off the ground.<p>Given what I have seen so far, I don&#x27;t think that he understands what it takes to make this thing successful. I don&#x27;t know, maybe he gets lucky or something, but lets just say its unlikely. Its going to take a LOT more money in marketing than he believes and I get the impression that he thinks that people will just come to the website and use it. He is throwing out numbers that he thinks are attainable and, having started a few web apps myself, I know that he is being unrealistic.<p>I&#x27;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.<p>I honestly don&#x27;t have the time to get more involved, and start giving him advice on all the different aspects from a business point of view. Technically, though, I can get the job done to an awesome standard. But not on the business side.<p>Do I just lay the cards on the table, and let him make the decision?
======
byoung2
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.

~~~
kjhughes
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.

------
onion2k
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.

~~~
bnt
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.

~~~
twic
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.

~~~
onion2k
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. :)

------
maratd
> 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?

~~~
chc
> _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.

~~~
maratd
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.

------
psyklic
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.

------
twic
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-...](http://www.mensjournal.com/article/print-view/the-blind-man-who-
taught-himself-to-see-20120504)

------
matthewmacleod
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!

------
iamben
"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!

------
aepearson
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.

------
contactmatts
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.

------
kvgr
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](http://6artisans.com)

~~~
normloman
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.

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

~~~
normloman
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.

------
andyjohnson0
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.

------
kubiiii
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.

------
NicoJuicy
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.

~~~
bnt
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.

~~~
NicoJuicy
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.

------
pjc50
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.

------
hkarthik
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.

------
rbalint
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.

------
centdev
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.

------
whyme
"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.

------
issa
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.

------
smartwater
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.

------
pcharles
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

------
danmaz74
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.

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

