It seems like you are using an ad blocker. To enhance your experience and support our website, please consider:

  1. Signing in to disable ads on our site. Our users don't see ads
  2. Or, Sign up if you don't have an account yet
  3. Or, disable your adblocker by doing this:
    • Click on the adblocker icon in your browser's toolbar.
    • Select "Pause on this site" or a similar option for lancecourse.com.

Your job isn't to finish, but to start

A website has a start, but never an end. In fact, this isn't applied to websites only. It's a general phenomenon to any living project. One big and funny mistake project owners and some developers commit is to believe a project needs to be finished. One good question which proves that is when clients use to ask us: when do you think you will finish the project?

Although it's a normal question, I believe it's not the right question. In addition, I agree any project must follow a time frame. It must be executed through a project management lifecycle: Ideas, planning, research, execution, testing, etc. But, in no case, a project has an end.

This is an arguable opinion though. The fact is that when you are lucky to have a client who has a clear idea of his basic needs, it will allow you to see the main modules or features to be implemented in order for the client to see his system running. For example, when you are to create a blog for a client, it will be obvious to give him an option to add/edit posts. Allow his visitors to comment under each post. And, maybe, before that, you would have given him a nice design. At that point, a client could assume his project is at the end. Because it does what he needs to do. In this case, you can assume you've finished the job.

But we all know that a blog can be more complex. When you decide to handle multiple administrators, posts drafts, adding tags to posts, changing themes, automatic/scheduled publication, and so on, this can become a very tedious task. And these are things most clients can't see at first.

In reality, what we call the end of a project can simply be considered as a stable state. And this stability may not have anything to do with the code stability. It's just a phase whereby all basic/main or obvious features are working. In most cases, depending on the importance of the project, we can deploy. Also depending on the type of project your client might not need to come back on the project. That's the case of static websites. But, in other cases, there is a high probability that your client will come for an update, a fix, or an upgrade.

There are so many reasons why a project does not have a real end. A change to the user experience can be a big catastrophy to the code base(mostly in projects that are not well planned). In the beginning of any website development project, there are always more challenges which slow down the work. The collaboration developer-client is tedious. At this stage, most clients don't have clear/final thought of their idea. Their business model can always require a modification of the site. Most clients I had the chance to work with find their real goal after I have drafted the first version of their site, or after two to four months of launching.

A common phenomenon that occurs all the time is that, just after launching a website, clients tend to realize what exactly they want. Then, they start building it up step by step through continuous updates and modifications. That time is when you realize that launching a website is launching its start. That day is when you start building the real website. One of the main reasons why that happen is that the online market is very hard to target and predict. So, you need to dive in and get feedbacks. From there you will start to understand the real thing people need.

Your job as a developer is not to finish the site right the way. You have to make sure you get to a stage which covers the most important features of the client's goals. Then, again, expect to continue the job. Many developers feel bad and always have issues with their clients because they need updates and upgrades.

Personally, the first version of my sites I build is meant to help me easily build the upcoming versions. The coding style you choose, your workflow, your choice of technologies should be defined with the optic of helping you easily update, upgrade, or even downgrade at any time without you having to go through many struggles.

Another thing you need to take into consideration is that, if you don't accept the fact that you can't complete the website at once, you will waste so much time in decision making, building, and testing. And time is something clients will never give you.

So, next time you have a new job you have to consider that fact. That will greatly help you make your prices and tell the minimum time frame required for you to complete the first working version of the site. Don't exaggerate in your estimations, let the client understand the challenges related to his idea. Help him to avoid feature greediness and focus on a launchable version, and make him understand that you will stick around in case he needs to make a few changes. That will save you a lot of time.

Thanks for reading. If you liked it, kindly share with your friends.


Cover image by pixabay.com