7 Signs Your Project Will Never Make it to Production

Posted by Ben
on Thursday, March 15

As a freelance RoR developer, I run across all kinds of clients. My favorite kind of client is the type that will actually get his application into production. Beyond the rate that he pays me, a running-in-production application is what I want. We’ve all seen sites where people show off their work; you know the portfolio page that just shows thumbnails and an application description. Well call me crazy, but I want to see more!, and your next potential client will want to see more too. Ideally, you’ll be able to show off your hard work in all its splendor! Therefore, you need to work on projects that will launch.

There are clients, however, that want your services and are willing to pay, but won’t be able to give you another nugget for your portfolio. Most likely, the client is too emotionally attached to accurately weigh his chances of launching, but by running a few filters you’ll get an idea. A little disclaimer, none of these filters are right all the time. This is fuzzy logic. Use them as signals or cautionary flags.

1) The client doesn’t have wire-frames or any user interface mock-ups.

I described this in detail here. Essentially, if your client has mocked up his application, he has passed an important gate. If there are no mock-ups, then at a minimum he has some work to do before you really get rolling on the app-dev side.

2) The client would rather describe the application to you over the phone instead of with a document.

This is even worse than not having design. He is one of the most frustrating clients you can have, because he has probably seduced you with the big idea. You probably like the guy enough to overlook the fact that he has no written plan. But by taking this guy on, you become an enabler—you have set up your client to let you down. Put some gates out there before it’s too late and help him help himself. Don’t promise to work with him until he can show what he wants in writing.

3) Creating this application fulfills a personal mission for the client

Everyone has their white whale. Parents, past failures, messianic complexes, we all have something we want to “overcome”. If your client is on a personal mission, then he is polluting his business mission. I once had a client who basically said to me that he didn’t care if the application failed in the marketplace because he “had to do it.” Serious!? If this thing doesn’t launch, how am I going to show my next client what I’ve been doing for the past couple months? Aren’t therapists cheaper than Rails developers?

4) “Are you interested working for equity?”

Run!! The project you’re working on is so far from production, it’s not even funny. What’s funny is that you are still working on it, and haven’t been looking around for new clients to bail you out! I have a friend who was working for a database startup that was going to kill the relational database market with their new “organic” database. When I pressed him to describe the product in simple terms, he couldn’t. When I asked him who the beta customers were, there were none. That’s when I told him the writing was on the wall. Later that week, they laid everyone off, asked them to work for minimum wage in cash, collect unemployment, and work for equity. Later that month, the primary angel investor was arrested for funding the company with embezzled money.

A bird in hand is worth two in the bush. Always take money before equity. Only take equity if it’s on top of your full rate. If they try to cut your rate and offer more equity, the project won’t make it to production.

5) After a payment or two, the client asks if you can reduce your rate.

Oh man, this one is sad. Bad vibes fill the air here. You can just feel that your client wants you around, but that you’re eating into his financial bone marrow. For God’s sake, shoot ol’ yeller and get a new contract!

6) “I’m going to lean on you heavily to tell me what this application should do.”

I fall for this one all the time. Being involved in business decisions is really fun for me plus it makes me feel important—it’s ego-stroking. But am I the one who should be figuring out what the user of the application wants? Look, it’s great when the client values your opinion, but beware. Your client should bring the business/customer expertise, and you should bring the technical expertise. Start tapping your network for contract leads if you find yourself telling the client what the product should do.

7) The client doesn’t have a customer who wants to use the application before it’s built.

Evaluating this differs depending if it’s b2b or b2c. If it’s b2c, then the client should have a marketing plan that you can read and understand. It should breakdown who the customer is, how many there are, and what they’re willing to pay. Your client should also have a few regular joes ready to sign up. If it’s a b2b app, absolutely do not sign on until your client has businesses ready to go before the app is built.

In conclusion…

There are many signs that your project won’t make it to production, but these are a few that either I or my friends have ignored. Are there any I forgot? Let me know in the comments.

Comments

Leave a response

  1. Anon – March 27, 2007 @ 02:21 PM
    Frequent and significant changes to features and scope seem to be a bad sign. If every few months you seem to be working on a new project with the same name, you'll be working on code that will never ship until the end of time and/or the end of the money.
  2. Roger Keays – March 28, 2007 @ 07:36 PM
    It's *so* embarrassing when these things happen (4, 5 and 6 especially). I've printed this out and stuck it to my wall :)
  3. Tony Austin – March 28, 2007 @ 08:41 PM
    Oh, so true! And what about some others, such as: The client does not want to be involved with "mere technical details" and progress reviews?
  4. Kerosences Tim – March 29, 2007 @ 01:41 AM
    Ideal Scenario would be client send project scope with technology selection and sign up contract that he will not change requirment till time you deliver project. Anything other than this will always lead to miss deadline.
  5. JR – March 29, 2007 @ 03:44 AM
    For number 6, I would say you (or your customer) need a designer—someone who can determine what the user one and how to better provide it, according to business goals and the technical constraints.
  6. Derek Etnyre – March 29, 2007 @ 03:00 PM
    How about #8 - Customer shows no interest in developing a testing plan, or does not have time to test the application on a regular basis. When this happens - run!
  7. Ben Edwards – March 29, 2007 @ 11:11 PM
    Ben, I agree with much of this post (and also fall for #6 as well - it is flattering) but I am going to have call your first to points into question.
    1) The client doesn’t have wire-frames or any user interface mock-ups.
    First, mock-ups and wire-frames, should they prove useful are a great exercise for both the development team and the client to participate in together. Clients need not, and in many cases, should not do these for themselves. Maybe it is my bias as a designer but I would rather a client come to the table with 50 ideas and a sense of what they are looking for than a concrete prototype of any sort. This also says nothing of the idea of software as prototype which, in many cases, can be very effecient and frees the team to bring actual features to bear for use by the client - so they can see how they function in the context of the actual application. This one is bigger...
    2) The client would rather describe the application to you over the phone instead of with a document.
    This is a much BETTER way to go about software design and development than documenting things in artifacts that, if they ever represent reality, it is only for a short time. Having conversations with your clients are going to be the single most important thing you do with them. Deferring interesting, important information into a document instead of communicating directly with your client (even if it cannot be face -to-face) is probably the number one way to ensure that no one is happy with the project's outcomes. Why would you want to encourage the creation of documents and diagrams, and charts, and design mock-ups that, at their best, represent circumstantial agreement at one moment in time and at worst, provide a false sense of agreement and a maintenance nightmare going forward as the dev team is updating both software and software specifications in the hopes that when they are done they are close to what the document supposedly represents...something to which both sides can agreed. If it isn't obvious yet, yes, I am a believer in agile methods of doing things, and I will end by paraphrasing Kent Beck (I think) who said something pretty close to the following: A well-run predictive process (i.e. create specifications up front) can produce almost exactly what was first envisioned while a well-run adaptive process can produce something better than the originally conceived idea.
  8. NeedMoreCoffee – April 02, 2007 @ 03:39 AM
    Yes, "a well-run adaptive process can produce something better than the originally conceived idea"..., in an ideal world. The days of time and materials jobs are long gone. Up front requirements are no longer a "nice to have" they are an essential piece of documentation that form a contract between the client and software company/implementor. Business sees software development as just another service and as such it is treated like one. If you ask to get your house built off the plan and are quoted a price, that is what you expect to pay..., unless you get Multiplex to build it...
  9. Ben Edwards – April 09, 2007 @ 11:11 AM

    NeedMoreCoffee, you may need more than that. Its called flexible scope – we have just been telling clients for too long, that they must define everything up front. There is such a huge fallacy associated with this idea – that we can accurately predict what will be built in the end. Iteration and communication trump contracts any day. I’ll pit the satisfaction of my clients against those involved in a contract-for-hire model any day.

  10. Neeraj – June 06, 2007 @ 04:10 AM

    Hi One more scenrio that I have faced is when the client writes a short ending line in his specification document saying “And other minor modifications/changes”. Please be strict to ask him to list down the “other ” word in detail as sometimes it can lead to complete change of application.

    And documention is a good practice as it can be used for recalling what requirements were freezed and what are the suggested changes as we can always prepare an estimate for the change in requiremetns.