Your Developer Just Quit! (…here’s how you prevent that…)

So you met a developer through a freelance board, referral, google search, whatever… you found them. They sounded better than sliced bread. The firm was affordable, sounded knowledgeable, and started off with a bang! And then the relationship went flat… Emails weren’t getting responded to as quickly. Your voice mails took a bit long to be returned. The work slowed to a snail’s pace. You think that you provided them with all of the instructions and changes. Why can’t they just get it right?!

It’s 5am. You’re mentally wiping the cobwebs from your still half sleeping brain. The mouse gets a little jiggle. Your screen fires up. Email is waiting. And on top… there’s your developer. It’s a “Dear John” letter.

That’s bad. Real bad. Forget delayed launch schedules. Now you have NO launch schedule. Forget marketing efforts. You can’t sell air (yet). All that hard work.. flushed… down the IT train. Oh you have your code. A download link is attached to the email. Before you go hunting for another developer, review this list. Maybe you can prevent this from happening again.

Top 5 Ways to Make Sure You Have a Good Developer/Client Relationship

1) Confirm They Are Qualified.  After 15 years in this web development business, I can PROMISE you that applicants embellish EVERYTHING.  I recently had a supposed iOS developer try to tell me that he, with his own two hands, developed the Fed Ex mobile app.  We dug a little harder into that, requiring references, phone numbers, points of contact, and he folded.  Often an ‘expert’ is a self taught, not formally educated programmer whose ego is 10x the size of his actual skill level.  You have to make sure that this individual has the ABILITY to easily deliver YOU REQUIRE of this individual.  Require 3rd party test results in the code discipline you are hiring.  Make them take a test.  Pay for it.  And before you balk, ask yourself… “Would you pay $10.00 to NOT have to hire another developer in the middle of your project again?”

2) Create a Project Document.  I cannot begin to tell you how many clients have pointed at one site and said “I want that” and in the end they actually wanted “something like that but with a LARGE number of modifications”.  Put your thoughts on paper.  Don’t try to be a programmer or database engineer.  Be a user.  Describe the end result that you want your users to experience.  Do this from a process perspective.  “I’m on the home page.  If I click sign up, then I want the sign up view (new page, popover, slidedown, etc) to appear….”

3) Require a Development Plan From Your Developer BEFORE You Start the Project!!!  You need a site outline that displays ever page in their proper flow format.  You need (at a minimum) page descriptions for each view.  This should describe what appears on each page and complete event outcome scenarios.  HyperPMA supports this style of planning by the way.  If you are using a HyperPMA Certified Developer, then this is standard fare.  You need to ensure that your developer has a very clear and complete understanding of your project.  Otherwise, the pricing and time estimates are going to be off.  And that’s one of the top reasons a developer will run.

4) Define Clear Deliverables, Incremental Milestones, and Expected Delivery Dates.  Once you have 3 out of the way, your new developer will have no problem giving you their preferred milestones, value, and delivery date.  Once you have these, discuss them with your developer.  You will find that 1 day means 3 with testing.  30 days is actually 45 – 60.   Be reasonable in your expectations.  Offer breathing room.  They want to make you happy.  You want your new technology.  They want to get paid.

5) Stay Within Your Phase 1 Scope.  So you have a 2am epiphany.  Write it down.  The goal of a Phase 1 project is MVP – Minimum Viable Product.  DO NOT “Kitchen Sink” your Phase 1 project.  DON’T DO IT.  You can be as agile as you want in planning.  You can be as agile as you want when you finally get to market.  You cannot afford to be agile in your initial product offering.  Talk to your developer.  Let them know what you thought about for Phase Two.  This will let them know there is more to do.  That means future business.  It also means feedback that isn’t defensive.  Though you are willing to pay for more work in this phase, I can promise you that your developer is focused on the finish line.  They want to get to the end.  They want to open a new project with you as soon as this first one is done.  DO NOT create the never ending project.

Leave a Reply

Your email address will not be published. Required fields are marked *