A while ago I saw a post on Radar of a developer who was given the task to replicate Woo-commerce and was given two months to do so, he was having problems digesting the task. This is a very common problem in contract work. I get a lot of requests from potential and current client's to "just do this task" not understanding the time or the complexity of it. In a previous post, I explain how really well-built software always looks simple. This can lead to non-technical people under-estimating the work needed to replicate that piece of software and this even fools seasoned developers to give very optimistic estimates, so I decided to share the answer I gave to the original poster, which is the technique I use with my clients today but in a generic format.
Take a moment and step back, catalogue all the features of the app you are asked to clone. No feature is too big or too small to add to this list. As long as it is a standalone feature, it should be added to the list
Now go over each feature and estimate how long it will take you or your team to build each one. Be very generous with the estimates. Developers are notorious for underestimating how long something will take to build. A rule I use all the time is, whatever your gut tells you about how long it will take... double it. Being optimistic here can only burn you, no one wins awards for having small estimates and meeting it, but you get praise for finishing earlier than expected.
Figure out the MVP
Talk with your client again, Do not bring up your estimates, it will sidetrack the conversation. Tell them you need to understand the core of their problem in order to build the best solution for them, with the right architecture. Work with them to figure out what the Minimum viable product version of this product is. Ask them to name the most important feature, it is normal for them to still name everything and the kitchen sink, resist this and press them till you understand what problem they are trying to solve exactly and what is the cheapest and least technical way to solve this.
Build a road map
Based on the information you have acquired from them above, go back to your estimates and figure out a road map. Decipher what critical features you can build within the amount of time they need the product completed and a path to how they can proceed from that point to add all the other features they need.
Come clean to them, be honest and tell them how long it will really take to build all of what they want. Use analogies, stories and pictures to explain to them in the simplest of terms what they are asking you to build. Make sure you do not use technical jargon that will only succeed in making them feel stupid. Explain as simply as possible because if the software is really too big to build in that amount of time, your simple descriptions will make it self-evident to a 5-year-old.
Offer them an alternative route
A big lesson I learned from the CEO of the last company I worked, he says "Never say no to a client". Business is always a negotiation, someone is offering you money for your services. Give them a route to help them reach their end goal. This shows you care about them and their mission and you have carefully thought out a path to satisfy their problem when you could have easily had told them what they need is not feasible.
Be ready to lose the contract
Sometimes the client still does not understand or even worse they are a slave driver and does not care that the task is not feasible and so they will find you "incompetent" or "not a match". Be mentally ready for this as a potential scenario and be ok with it. You do not want a project where you are destined to fail, your reputation is also on the line and you will be unhappy with your life and work during this period. It is not worth it.
If you do find common ground with the client and now have a path to creating what they want. Make sure you set up a win-win situation. One that sets realistic goals and allows you to create your best work for your client. Do not be afraid to push back on clients if they have an unreasonable request, they are paying for your expertise and showing them you understand your business only makes them respect what you bring to the table and allows you to turn a bad project into a good one.
Subscribe to The Art of Coding
Get the latest posts delivered right to your inbox