15 Phrases That May Kill Your Web-Project

There are words and phrases you totally don’t want to hear or read during your web-project creation process. I’ve decided to take the most painful ones and make a list – would you recognize any of these happened to you?

Phase 1. Before the project

The first phase when things can go wrong is before the project even starts – when you get a brief from the client, or have first discussions.

1. Client: “I don’t know how to explain. I’m not a developer, You’re the professional here, you will figure it out.”

This usually happens when client isn’t an IT person. And that’s totally fine. What is horribly wrong is when the client refuses to take any part in any technical decision-making. This leads to guessing what the client actually wants and, believe me, it’s almost impossible to be right here.

How to fix: even if the client is not technical, get him involved in the technical part – they need to explain the things in their own words. Then you need to educate them on some basic technical things and make some decisions together. Alternatively, you might refuse to take the project, cause potentially it involves additional time to educate the client on technology.

2. Client: “It’s a simple project and it won’t take you very long”

This actually means “I don’t value your time and efforts and don’t want to pay much money”.

How to fix: in my experience, all the clients with this start of the relationship turned out to be horrible. Unfortunately, I don’t see any fix except for not taking such clients.

3. Client: “The last developer was horrible and I cannot find him now for a takeover”.

This phrase has a few different versions: “developer was too junior”, “developer had time management problems so I fired him”, “developer was bad at communication” – whatever is the reason for the divorce with previous developer, it’s usually bad for you. If the relationships ended on a bad note, it usually means that part of the problem was on the client side: small budget, lack of communication, unclear instructions etc.

How to fix: if you do want to take on project like this, raise the price at least 1.5x. It will compensate your time that you will spend trying to understand previous developer’s work.

Alternative fix: offer a complete start of the project from scratch, without using previous developer’s work. And, yes, charge for your time as for a new project.

4. Client: “We need this project done in Symphony or Lavarel”

Yes, those mistakes in the framework names are not typos – that’s exactly the point. This usually means that the client doesn’t actually work with that technology, and heard from somewhere that it’s good. In reality, client shouldn’t force any programming language or framework without any reason.

How to fix: ask the client what is the reason behind this choice, and offer alternatives – usually good clients trust professionals and their opinions.

5. Dev-team: “Angular 2 has just been released so we totally need to use it! It’s the future!”

This is a disease of some developers – always going for the shiny new object, just to try it out. Golden rule here is just-released technology is suitable only for testing projects in the first months – it’s not only about the quality, it’s about lack of documentation, forum topics and best practices.

How to fix: just stick to what actually works and where you have real experience – it might be an older version of the same framework (with the option to upgrade in the future), or totally different language.

Phase 2. During the project

Ok, the project is in development, everyone’s on the same page, what could possibly go wrong? Apparently, a lot.

6. Client: “I will prepare the texts as soon as you have the website up and running”

It involves not only the content, but actually any text information for the website launch: like various dropdown values, logo, branding stuff etc. The problem is that if client doesn’t spend time upfront, it may delay forever. Another thing is that designers or front-enders might not know how much space certain element would take – “Lorem ipsum” can only take you so far.

How to fix: list all the related questions for the texts and elements upfront and push the client to deliver them as soon as possible, with argument that it’s best for the client and lessen the risk of delay.

7. Client: “Here’s a logo attached in a Word document”

This typical scenario is only one ridiculous case of a bigger issue – when the client and the dev-team don’t know what formats they need to use for the deliverables. It actually goes both ways – I wonder how the clients would react if the receive the whole website back in Word too.

How to fix: in the very beginning, establish the process of what information needs to be delivered, in what formats, sizes and other possible parameters. As little room for improvisation as possible.

8. Client: “Oh, did I say it needs to be multi-language?”

Oh those “small details” that appear in the middle of the project. Actually, client in this case is not a bad person – they might not know that websites are not multi-language by default. It’s your job as a professional to raise this question upfront.

How to fix: have a list of questions prepared for all projects – like languages, payment methods, supported browsers and devices etc. Clients don’t know what they don’t know – you have to help them here.

9. Client: “I’m sorry I’ve been busy for the last couple weeks, here’s my feedback in 10 pages…”

Constant communication is the key to success. Again it goes both ways – developers also cannot disappear for weeks, otherwise the conflict is hard to avoid.

How to fix: establish the rules for communication upfront. Daily or weekly meetings or Skype calls, also showing the progress via live-demos or code version control systems like Github/BitBucket. Also, use project management software like Trello for feedback.

10. “RE [125]: Feedback”

Same topic from a different angle – don’t use email for feedback and for communication, it’s usually really hard to find information after a while in long chains of replies.

How to fix: start using project management software from the beginning. If needed, educate the client and send them some helpful links of video tutorials.

Phase 3. Testing and launch

Ok, we’re in the final stages – just a few fixes here and there and we could celebrate. Not so fast…

11. Client: “I asked my wife and she told me that this button needs to be orange”

Replace “wife” with any relative or a friend totally distant from IT or web-projects. Their opinion might be interesting, but usually shouldn’t force any actual changes to the project.

How to fix: politely explain to the client that all feedback is welcome but only people with competence can actually affect the project. Also, explain why the “orange button” shouldn’t be changed – what’s the rational reason behind the other color.

12. Client: “OK, let’s go live, here are my FTP details to GoDaddy”

I don’t want to sound too negative about GoDaddy, but let’s put it this way – it has not the best reputation among serious web-developers. Also, deployment via FTP is considered obsolete and even dangerous practice. But again – clients might not now either of those facts – they just have their hosting company account from ages ago.

How to fix: prepare the server and environment for deployment upfront, possibly even set up real domain URL with “Coming soon” page to make sure that you have the necessary technology stack. If the client doesn’t have the credentials ready, suggest a few alternatives yourselves, explain their differences in “client’s language”.

13. Client: “Ok, I finally showed the project to the CEO and he’s not very happy”

One of the worst things that can happen to any project is a new decision-maker appearing at the final stages. Especially if it’s someone important like CEO and you just cannot ignore their opinion.

How to fix: discuss all the decision makers upfront, also be clear about the process of approving the work, the “sign-off” needs to be understandable for both parts.

14. “I don’t know, it works on my machine”

This one is as old as the web, and may come from any person involved in the project – developers, testers, clients. Basically, it means “I don’t care, it’s not my problem”. Wrong. It’s everyone’s problem, actually.

How to fix: again, discuss upfront all the different environments for testing, and also you may use a tool that records people’s sessions, including browser and operating system data, so you will know for sure what is the environment of the bug.

15. “Backup? Umm, let me check if we have one…”

The project is launched and we have the first visitors or even customers, yay! Not so fast – you have to take care of the security and data backups, especially the database – the code is usually available on Github or similar repository.

How to fix: nothing special, just take care of automatic backups upfront – like nighly backup to some Amazon S3 server. Also, test the usage of the backup at least once, whether that SQL actually can be used and imported.

So, that’s it – I’ve chosen these 15 phrases which are deadly dangerous. Anything you would add to the list? Or comment on any of the mentioned ones?