I once had a client who mistook asking questions for incompetence 🤦. Instead, how to be a good client!

Collaboration misinterpreted

I pride myself in taking a collaborative approach. 

In understanding the client's requirements in depth.

In asking the right questions.

And in providing the best advice that I can, even if this advice is "I'm not sure, I'm going to read the docs and come back to you" or "Sorry I can't help you, your requirements are outside of my area of expertise."

My approach is finding the best AND most cost effective solution, to solve the priorities of the business. 

Running my ideas by the client and helping them to understand the pro's and con's of each. 

Often quality and cost are held at odds - but I would argue that the time spent planning as a software developer will produce 5-10x more effective work. 

But this can be misunderstood when clients have never built software before. 

Sharpen the saw

I resound with the following ideas:

Sharpen the saw and cut once with a sharp blade, rather than hacking away with a dull blade, getting nowhere. 

Plan the foundations properly rather than digging yourself deeper and deeper into a hole but never reaching the solution.

Sorry if I may sound uncertain, but I would argue that being confidently wrong is a worse position to take.

So how do these situations play out?

Building to scale

Let's say the brief is to build a scalable web application. 

Let's say we have several technical hurdles to overcome.

Let's say we report to the client "we've built something that works, but now we want to re-organise it so we will be sure it will work, at the scale required".

Let's say we are thinking about server workloads, to reduce later cost.

The only downside is that we need a few more weeks.

The upside, your app won't crash on the day of launch. 

Then the client comes back to us and says "do you really know what you are doing?"

Our reply? Scalability is a spectrum. Small decisions can make your solution more or less scalable. Hey we're on the same team trying to help here. 

Finding a definitive solution

Or lets say we have to perform an API integration.

A really complex, custom job. Integrating two remote systems with our app.

Worse, "remote system one" has a terrible legacy API that doesn't expose IDs properly.

Initially we recommended to the client that we move all data to "remote system two", but there was a late change of mind due to valid business concerns, and so we obliged and found an alternate solution.

We created and used metadata from each source system to categories listings, generate a mapping table autonomously from the inbound date, and performing a series of matching logic steps to handle:

(1) Historic data
(2) Current data
(3) Future 24hr updates to both data sets, passively triggered by the user logging in or using the app. 

The process is complex. It takes about 10 steps.

But it is tested and works definitively, without issue or bugs. And it's fully automated, potentially saving hundreds of hours of work or tidying up the data later. 

Even I was impressed. 

But the client comes back and says "I spent an hour googling it, why didn't you just use a webhook?"

Grrrrr... would you say that to your doctor?

Clients take note - things developers say, and what you should think

If your developer says "I need to do some research and come back to you" - this is normal. Good developers spend up to 50% of their day in Google or now ChatGPT! If they didn't, you should be worried.

If your developer says "I need a bit more time, so I can achieve quality with [insert issue here]" - this is a good developer. Don't mistake this for incompetence. 

If your developer says "Hey I was thinking about the solution we built, and your business needs, and actually I think we should do [XYZ] but it will cost 10% more"... do it. It will be worth it. 

If you don't trust your developer, don't hire them in the first place. 

How to be a good client

If you want to manage a software project, but it's your first time, I can understand how you would feel a bit exposed. Kind of like going to the mechanic and being told you have a $3,000 repair bill for bits and pieces you've never heard of. 

One mentor says "you should always have an understanding of the tasks that you manage".

You need to learn to reduce the "asymmetry of knowledge" in this situation.

If you want to manage an app development, we have developed a Bootcamp that will enable you to know:

1. The basics of software development.
2. How to identify a good developer.
3. What to expect during the process.
4. The right questions to ask and red flags to watch out for. 
5. What documentation and planning should be done to ensure the project is successful.

A message from all good developers ... please don't confuse collaboration or asking questions with incompetence!

Check out our Bubble Bootcamp to learn more.