This discussion came during a meeting with a client, as a freelance web developer. As expected, a client will judge the strength/capability of a web development company by asking the all-famous question: How big is your team?
Nothing wrong with that, because I used to hire external web developer companies or freelance web developer as part of my employment company and I asked the exact same question before. Surely that must be a good indicator of how good they are, right? Most times, yes, I do agree with that. But this article is about those times when this thinking just won’t stand.
Example 1:
I have worked as part of such a “team” before. I wouldn’t call it a team exactly. It was just a group of us programmers put together, and as the sales guy clinch up new sales, the project will be pushed to one of us, not caring how many we already are handling. So, me being just an employee, I have to clear all these jobs before I can go home. So, despite my best intentions, I had to cut some corners, knowing full well, that that action is going to come back as a bug next time. But next-time issues are issues for another day, right? I need to show something today so that I can go home, right? I might not even be employed here when next-time comes, right?
So, that’s the type of working style I HAD to follow. Even though it’s not something I’m proud of to admit now.
So, in summary: it was more of a patch-based, short-term development, rather than looking at the long-term stability and objective of that project or even caring about the company behind the business or how this will affect their business.
Example 2:
When sh@t happens, then what? In other words, when issues arise or things go wrong, the client will call the helpline which they might have been given. Typically a ticket help desk system, and not a phone number to call immediately. There was one time, when a sign-up section was “just not working”. Client submitted the helpdesk ticket. The ticket handler had to find out who was the programmer for that project. And much later, found out that he was not in the company anymore!
(Digress: Yes, programmers do leave companies and even the industry. Why? Why many people do not want to work as programmers? )
Moving on … guess where that sh@t landed on. Yes, on yours truly, that is myself!
Now, I had to bring myself up to speed with what that programmer had done, his working style, do some trial and errors, and eventually fix the issue. Phew! But that was 3 days gone. Not least because I’m a slow guy. Because issue happened on an evening, and no way, I was coming back to work there and then, right? I only started when working hours started. And of course, please don’t imagine I had the whole day to fix THIS single issue. I already had my own overwhelming pending works of my own. So, I had to find in-between time to fix this issue. 3 days is actually very good enough. So by the time client had his issue fixed, it was 3 days later.
Now, fast-forward to current time. I am a full-time freelance web developer and programmer. I’m running my business as a one-man show. My full time job is to develop systems as well as support my clients. When asked, I say that officially, I will fix any arising issues by 48 hours. But typically, 95% of the time, issue is fixed within 15 minutes.
This is what typically happens, with an example:
- Client notices that the app is not sending invoice to the client after the technician closes the on-site job on his app.
- Client doesn’t use a helpdesk ticket system to get me, no! He uses what he knows best. Either he calls me or whatsapp me or direct-email me, according to his preference, and relates the issue.
- I listen, understand, ask questions, if necessary, and hang up.
- I get down to issue immediately. Code was done by me, and NOBODY else, not my employee, not my team member. So, I know why this could have happen, almost immediately. And just as immediately, I can rectify it.
- And I then whatsapp-reply to my Client “Issue fixed, pls check”, and he’s happy. I’m happy. Business resumes as normal for him. And for me.
Now, how can I do that, as a one-man-show web developer, when large teams can’t do that, you might wonder?
It’s not exactly that difficult to comprehend. If you’ve worked both in small and large companies, you know how things work, even for a simple task of applying leave.
Small company: “Boss, can I take leave this Tuesday?”. “Er, have you settled the ABC company account?” “Yes.” “Ok, leave granted”
Big company: you go through some system with multiple layers and approvals. Remember telling your girlfriend/wife that your leave is still pending approval?
That’s just for leaves. Just imagine project issues and complex-level issues, and you know how delayed and complex things can get.
My job, since I started full-time as a freelance web developer in Singapore, is to handle client’s web development projects, as well as future issues. So, all issues are handled by me, myself and I, who was also the actual developer of the system. Who best to fix an issue but the web developer himself. That is one reason fixes can be fast (and furious, if you will consider the client’s emotion if such things are delayed). And eventually, the client is happy.
Furthermore, do you know what is the best way to avoid programming bugs? It is to develop clean codes at the development stage itself! Very simple. If I think short-term, then I won’t care about clean codes. But because I’m the guy who must settle future issues as well, I ensure that almost no-one will call me with issues in the future after the project goes live. This is good for me, and definitely good for my clients. So, again a win-win situation.
Anyway, this blog is to explain in detail to anyone who thinks that SIZE DOES MATTER when it comes to web development companies. As far as I’m concerned, from my 24 years of experience, it doesn’t.
About the Author
Anees Khan is a freelance web developer for the past 24 years, and is running Getcha Solutions to help companies get the latest tech for their business needs, requirements and operational workflows. And yes, he is a one-man-show!
