This Is Why Your Web Developer Quit On You (And How To Fix It)

Have you ever had a development project that went poorly? Did your developer quit on you or give up the project unexpectedly? I can imagine that it was a very painful, frustrating and expensive experience for you. It’s probably one that both you and your developer prefer not to relive.

While there are many reasons why this can occur, I believe that simply adjusting your approach can solve the majority of your problems. After you read this guide, you will see why your developer quit on you, and I am going to share with you exactly what you need to avoid this kind of problem in the future. I am going to help you understand how a developer should be thinking (even if they don’t realize it themselves). Once you understand the proper thought process, you’ll be able to win when it comes to a development project of any kind.

1. Let’s Take a Journey Together

Take a moment and imagine that you are standing on the edge of this prairie, and you can see the future of how this beautiful stretch of land is going to look. At first, everyone sees this when you tell him or her what your new project is going to be like:

You can see the future. You know what your project will bring to your team, your clients and the entire world. You know that, someday, the flat prairie everyone else sees will turn into a busy metropolis that brings value to the entire community:

So the big question is, how will you get there? How will you take an empty field and build something amazing? I can tell you that the first step is to build a road. Once you have a reliable road, people can use it and your dream will start to come true.

Hiring your developer to build your website, mobile app or software is like hiring someone to build the road. I want you to write this note down now, “Developers are linear thinkers. They build roads.”

2. How to Hire the Right Developer (Your Road Crew)

Now that you’ve made a note to yourself that developers are linear thinkers, I am going to help you take the right steps to recruit and hire the right developer. Sometimes you need one person, and sometimes you need a team. This approach will work, in either case.

2.1 Build the Map:

Imagine yourself standing on the edge of that prairie above, and you’ve brought your road crew in to get started. The foreman walks up to you and asks you, “Which way are we going?” and you reply, “I don’t really know yet, it’s all in my head. You can go whichever way looks good to you.”

This level of uncertainty may seem ridiculous to you in that scenario, but have you ever been unclear in your vision before? Lack of clarity doesn’t help linear thinkers move forward. You need to provide very clear details in order to achieve success in your web project. Here are a few steps to help you get there:

1. Write a one-page summary of what your vision is. Keep it at one page to start. The summary should include:
2. What you want to build
3. Who will be using it
4. Why you want to build it (what problem does it solve)
5. When you’d like to have, it completed by
6. What your total budget is for the project (make an internal note to yourself to allow an additional contingency of 20% overage)
7. Find 3-4 examples that already exist and explain what parts you want to take from those projects and incorporate into yours. For example, “I like the slider on this site,” or, “My app should have a profile view like this,” and then take screenshots.
8. Annotate everything you are gathering with Skitch.

Once you’ve invested the time to follow the three steps above, you’ll have a short information packet that will help you more clearly think about and communicate your project. One-page summaries are by no means technical specifications, but they do allow you to start off your communications with your developer on the right path.

2.2 Have the Meeting:

Now that you have your basic map together sit down in person or have a virtual meeting with the person you are interviewing and share a copy of your basic details. Give them a few minutes to review the material before or during the initial part of the meeting, and then ask them these questions:

1. Do you understand what needs doing here? Explain it to me in your words.
2. Is this something that you can accomplish?
3. If we both agreed to everything today, is my budget and timeline reasonable?

Start with those questions and see how the meeting goes. They will tell you a lot about your partner and their abilities and confidence. Once you’ve covered those initial questions and gotten to know each other, ask these questions as well:

1. Can you write me an expanded specification and proposal using my one-page summary and examples?
2. Can you tell me what technology frameworks and code you will use to build this for me?
3. Can you share the following examples with me:
4. Some examples of your completed and successful work along with references I can speak to
5. Some examples of a failed project and why it failed
6. Any in-progress work that you can demonstrate to me

Once you’ve asked those questions, schedule the follow up meeting for a week from the first meeting and ask the developer to send you everything you asked for before that second meeting. This will give them adequate time to prepare and gives you both a set time to revisit the project.

2.3 Hire Your Team

When you come back together for your follow up meeting, be sure to have thoroughly read and reviewed everything that they have provided for you. If they didn’t provide you everything you asked for, find out why. These are red flags that I watch for when hiring a developer:

1. The developer didn’t respond when they said they would
2. They provided unorganized or incomplete information
3. You had to remind them of the meeting or didn’t show up

I recommend that you meet with 2-3 developers and choose the one that meets your requirements. Don’t rush this part of the process. It’s worth investing a little extra time to make the right choice and get the results you want.

2.4 Create Demonstration and Payment Arrangements

Right now, there is a failed model in the development industry, and I am going to share with you how you can eliminate it. If you believe that you’ve found the right developer, ask them to help you work out a rough schedule for your second or third meeting. Here are the steps you need to take together:

1. Re-read the specifications they provided you, out loud, together, and ensure it incorporates all of your needs. Revise it right then if you need to include something.
2. Look at the launch date you are asking for and re-confirm with your development partner that they can attain that goal. Remind them that if they realize that the launch date needs to be adjusted, after you both review everything, which is ok. It is of the utmost importance that you are both on the same page at the end of this meeting.
3. In a spreadsheet or document, write down each weekly objective that it will take to reach the full goal on time. One column is for you, and one column is for your developer. You will likely have to provide content, feedback or decisions as you progress, so clearly outline these.
4. Ask your developer if they will be working on this project only, or if they have other projects they have to focus on as well. Remember, if your budget is small ($5,000 or less), it’s unrealistic to ask the developer to focus on you only. If your budget is larger ($15,000+) then you can get more attention, but not necessarily their entire focus.
5. Now review the weekly objectives one more time together. Take this time to ensure that your developer is confident that he/she can reach the preset goals.

After you’ve marked out the objectives and timeline, divide your budget by the weeks you’ve outlined. For example, let’s say that you have 12 weeks of work and the budget that you and your developer have already agreed to be $5,400. This means that each week’s financial cost is $450. Go through that math with your developer and then follow this plan of attack:

1. Let your developer know they will need to be able to demonstrate a functional piece of the project for you each week, from the previous week’s work. Let’s say that this means you both schedule a 30-minute meeting each Tuesday Morning.
2. Let them know that you will pay them every week, after the demonstration, if you both agree that the objectives for that week have been met at a reasonable level. Add these two conditions to that plan:
3. If you cancel the meeting due to your schedule or delays, you will pay them the weekly amount.
4. If they cancel the meeting due to their schedule, you will need to see the demonstration before releasing payment.
5. If there is nothing to demonstrate or, the week’s objectives were not met, payment won’t be released until the objective is met.
6. Let them know that if, for any reason, you get a part of the way through the project, and they are unable to complete the contract, you will not ask them for a refund. However, in exchange, they must provide all of their work and a short piece of documentation to hand over to the replacement developer.
7. Write these terms into their proposal review the proposal carefully with your attorney if the cost is over $5,000 and then sign the proposal. You should each retain a copy.
8. Make a deposit of two weeks cost for $900 so they have the resources to get started.
9. Schedule a consistent time on Tuesday morning for the demonstrations and let your developer get started!

3. Keep Your Project on Track (Follow the Plan)

Now that your project is underway, it’s very important that you follow the plan. Be sure that you provide everything that you agreed to provide each week, and make sure that your developer is demonstrating new functionality each week. In some cases, there is a short period where wireframes or design views are acceptable progress, but this should not be a deliverable for more than two weeks. Make sure that you can “touch” the project by testing actual working functions within the first 3-4 weeks.

Once your developer gives you something to test, test it thoroughly. Don’t make the mistake of assuming that it works the way you want and forego testing. When you do have your weekly meetings or test the project, take a few minutes and write clear feedback notes and provide screenshots of what you are referencing using Skitch. This will keep you and your developer on the same page.

At each demonstration meeting, be sure to ask these questions and listen carefully to their responses:

1. How do you feel about this project?
2. What problems are you facing right now that may be stopping progress (if any)?
3. Do you need any clarification about an element or function?
4. Do you believe we can still deliver on time and budget?
5. What can I do to make this project go smoothly for you?

Pay close attention to their answers. If there is an issue that they need help with, respond immediately and solve their problem. If they start to falter on delivering demonstrable functions or meeting deadlines, pay close attention. One of these two things will need to happen:

1. You will need to provide extra support or resources to help them succeed.
2. You will need to consider wrapping up your contract with them and finding a replacement.

I only recommend option two when you are not seeing demonstrable progress each week. If you see weekly progress, but need to make a small adjustment to your budget or time frame, that’s ok. Take the time to make a careful decision. Don’t be rash and end your contract if the developer hasn’t met every objective but has met some. At the same time, don’t let them get paid every week without demonstrating functionality. Protect yourself and don’t squander your money when you don’t see results.

Make sure that you are living up to your objectives. If you don’t provide content or decisions, you still need to pay for their time; it’s not their responsibility to make you act on your objectives. Be fair, and you’ll find a lot more success in the development project world than you will if you are unreasonable and hard to work for!

4. Do NOT Rip Up the Roadway

One of the most destructive things that can happen to a developer is often called “scope creep.” I think that you should make note of this in a different manner. Write this phrase down now:

Road Bombing Must Be Avoided

It is extremely important that you stick to your plan and don’t add extra pages, extra functions, or change the specifications of construction. Stick to the objectives and deliver them. When you ask for a change or say, “I realized after testing this that I want to add this function as well,” you are asking for trouble.

Take a moment and look back at the analogy of the road crew. If you hired a crew to build a roadway straight across the prairie, then they would make sure to have enough manpower and supplies to get there.

Imagine that your crew needed 100,000 tons of asphalt to reach your destination and, during the middle of the project, you decided that you no longer wanted to go straight across the prairie. Now, you would rather turn just before the middle point and head south. It’s all well and good that you changed your mind, but what would have to happen?

• Part of the road would need to be ripped up
• You would need to buy more asphalt
• The crew would be extremely demoralized and discouraged about their wasted efforts in trying to go straight across the prairie

When you arbitrarily make changes to the project, you are effectively road bombing your developer. There are two key resources that get used up when this happens:

1. Your developers motivation can be used up (you need this the most)
2. Your developers time and money can be used up (they can’t focus on you without adequate funding)

As you consider asking for something extra or look at changing your plan, take this decision very seriously. It is so much better to complete the original scope and come back with more paid changes and additions than it is to try to manipulate the scope.

Just a few weeks ago, I was chatting with a developer friend of mine, and he was completely discouraged and burnt out. His client continued to add new features and kept pushing the deadline for launch back. My friend was being paid for the changes, but he was so discouraged because he had wanted to launch the project in which he had invested so much time. A great developer takes pride in their work and is motivated by successful completion. They are linear thinkers!

It Wasn’t Me, Was It?

If you honestly look back at your last failed development project, was there any road bombing going on? Did you squash your developer’s motivation by:

1. Not getting back to them with resources they needed?
2. Changing your mind after an approved design or function?
3. Adding too much to the project?

While the changes may not have seemed like a big deal to you or your developer at that moment, those things add up quickly and can become the demise of your project faster than you realize.

5. Plan For and Achieve Success

In this guide, I’ve done everything I can to give you the tools to complete your next development project successfully. You may need to make some slight adjustments, but I can tell you from personal experience that this type of approach will help you succeed overall!

Rather than waste the time and money that neither you nor your last developer had to waste, I would strongly encourage you to take the time and steps necessary to succeed. A successful project is a big investment on both sides, so stop assuming things and start communicating clearly. There is nothing worse than having to throw away a few months’ work because the project didn’t get setup or run properly.

Take full ownership of the outcome and choose to serve your development team with your whole heart. A good client is worth everything, and a developer will instantly be able to tell if you care about them or not. No matter what happens, treat them kindly and take time to think about what it would be like to be in their shoes. Remember that the words and deeds you put out into the world around you have a way of finding their way back to you, so choose wisely.

Wrap Up

As someone who’s been developing websites for over 15 years now, I wrote this guide to help you and your developer succeed. I hope it’s something that you will find useful for years to come. If you are in a position where your developer or your mistakes have burned you, and you’re looking for help, please contact us. I’d be happy to see how I can help you on your next project, with a better plan, a better process, and better results.

What do you think of this guide? Please share your thoughts in the comments below.