Well, well, well… We’ve finally come to the end of this series on working with an offshore developer! If you didn’t know, I wrote three posts already about working with an offshore, and I covered my decision to go with an offshore development company, my project and the proposal process, and most recently, the development process itself. While you don’t have to go back and read those posts, they may help you if you decide to go offshore for your project.
This post is expected to give you some insight into what I did/didn’t like about outsourcing my development. Maybe you’re on the fence, or maybe you have no frame of reference - these are the boiled out ups and downs I experienced.
A LITTLE ABOUT ME
When I discussed the proposal, I mentioned what my project is so there’s some point of reference for weighing the complexity against. It seems right that I talk a little about myself so you can compare my abilities (personality, even?) to yours and see if these things would be good for you.
First off - I am not a technical person. I can’t code, I can’t program, I can’t do HTML or CSS (maybe a little), I can’t fish around in SSH or FTP and find the right file. Before this project I didn’t have a clue as to what a LAMP stack was, I never read API documentation or knew how to form a query. Frankly, a lot of this stuff is still a foreign language, but at least now I know what it is.
Second, before this project I never built a site, managed a technical project, did QA, spec’d and sourced a server, compared geo-location APIs, scoured Stack Overflow for insight into using PHP for email parsing. It’s not as if I was an experienced non-technical founder. I was just a dude with doodles and ideas.
Third, it’s just me folks. I was lucky enough to find a technical advisor only a week before I launched. Needless to say, a lot was done doing my own Googling and asking anyone I could for their input. (Just a side note - it’s tough to get people to answer questions about your project.)
Last but not least, I had a very specific idea of what I wanted to get done. I had features built in my head, processes that I could relate to other sites out on the web, and a strong sense of what needed to be done and what could be omitted. I truly believe that this last item is the one thing that is non-negotiable for any founder - especially those using offshore developers: You have to know what you want built, even if you don’t know how to do it. Without this you will be lost, you’ll flounder, you’ll flake, you’ll change your mind and you can very easily never finish.
WHAT I LIKED ABOUT WORKING WITH AN OFFSHORE
Price - Obviously this is something that’s unique to each project, but at least for my project, the price was an easy pill to swallow. (I’ll also point out that other companies might charge much more or have some minimum amount for a project they’ll take on.) Still, when compared to the cost of finding and hiring a local full-time developer, there simply is no comparison. A lot comes from the exchange rates and the cost of labor, I’m sure. Whatever the reason, the cost made this a very attractive option. I’ve heard of rates for offshore developers from $12/hour to $30/hour. In country, experienced developers can easily go up to $150/hour.
Also, I had a package price for my project. Instead of just one developer, I had a designer and developer. (They said I had 4 or 5 people working on the project, but I only received emails from two people.) The real benefit of the flat rate was my ability to budget the project in its entirety and then find funding with a definite cost in mind. If someone asked how much it would cost, I had a number. It’s a lot easier to sell then, “I don’t know.” The flat rate also at least felt like the company was interested in pushing the project towards completion as well. The sooner it was done, the sooner they were paid.
Constant review process - The colleague that introduced me to this company told me before I began that the review process would be time consuming - “Annoying,” he said. He was right. The review process, especially later in the development, became a daily chore. I’d have a list of things that were just built/modified/revised and I would have to go over each one, testing each to make sure it worked and then either confirm or suggest changes via email that day. The next day, they would return confirmation of the updates and new things that were done and I’d have to do the same thing over. For some people it can get tedious and annoying, but I personally found it enjoyable and exciting. I was able to see the site slowly come closer and closer to completion, and if there was something that needed revision I knew it could be addressed while that item was fresh in the dev. team’s mind. Seeing large elements go through a lot of revisions and updates and tweaks before working makes getting to that point even more rewarding.
It also allowed me to make small adjustments and fine tuning to items. Especially creative elements. If you’re a perfectionist, the review process is great. If you’re not, I’d suggest really paying attention to the details so nothing slips through the cracks.
Professional, courteous and straightforward - Just like a “normal” job, the development of the project had its share of frustrations and stress; especially when things aren’t going as planned. Still, the business relationship I had with the off shore remained professional through the ups and downs. Maybe it was the physical and temporal disconnection of our contact, maybe it was the nature of them being “hired” versus being a coworker, maybe it’s because I didn’t have to bend or even listen to their opinion of how to build the site - I don’t know. Whatever it was, the process was made that much easier and more enjoyable knowing emotions wouldn’t get it the way.
Recently on an IM chat, the team member I usually talk with actually started to send some chit-chat comments my way, and I’ll admit, I felt a little uncomfortable about it. I’m usually a very social person, but this rubbed me a little the wrong way. The good news is, I could simply ignore it and move on knowing I wouldn’t have to bump into him in the hall or whatever.
Provided development “structure” so that I had a firm timeline - In addition to the original timeline I received in the proposal, I received weekly status reports that outline where we stood in broad terms in the development process and when the other elements were due to be completed. Having a timeline for the development was a tremendous plus for me. I knew when I could expect certain milestones from them, and when I needed to provide key deliverables. Especially since I am not knowledgeable enough to estimate the time needed for a project such as this, having that schedule also made discussing the project with outside people much easier. The timeline also gave me something to look forward to, so that I could know what had been accomplished and whether certain elements were on track for meeting the timeline or not.
If you’re not technical, the reports are great for getting a “big picture” on the progress being made. I’d say for anyone outsourcing their work - offshore or not - you really should be keeping a project lifecycle management system up-to-date. (This is something I was lucky enough to flub for my first go.) The more complex the project, the easier it will be for something to slip through the cracks. I’m glad they had something in place. Still, though it’s good to be able to spot check what they think, you should be on top of it too. (And have something to check their report against.)
Some minor technical guidance - Even though the company/team didn’t provide guidance in the strict sense of the word, there were certain things that they brought to my attention that facilitated my ability to understand the project, what was being built and how, and what I could anticipate. By being constantly involved in the project, I was also aware of the software and languages being used for the site. This was a sort of “eyes-on” education, and I can now at least understand the different parts of the product enough to know what we use and what to expect.
The impetus to learn how web projects are developed - Probably the best part (other than the actual project being completed) is the opportunity to learn how a project is developed and having a concrete example in front of me to showcase it all. I never would have decided to look up Sendmail, see what that does and try understand what problems it might cause when used on a cloud server. I still don’t know how to configure it or anything more than say “We use send mail for our SMTP.” But at least I know that much more than I did before I started.
WHAT I DISLIKED ABOUT WORKING WITH AN OFFSHORE
Lack of input/feedback on the project or specific elements - As I’ve said from the beginning, working with an offshore developer often felt like I was simply a puppeteer for the broad strokes of the project. Sure, I didn’t detail every line of code. I didn’t tell them anything about the code, actually. Still, the layout, the navigation, the processes and functions, etc. were all up to me to decide. If there is some standard practice for any of these items, I don’t know what they are. Presumably they would have pointed out anything that simply could not work. But whether or not something is smart or preferable or the best option or lends itself to scalability, they haven’t told me.
It would have been nice to hear some ways to improve my ideas - and I would have been open to suggestion. But if you need to bounce ideas around, I don’t know an offshore is for you.
Time difference - The company I worked with is in India. There’s 10-hour time difference. This really comes into play when you have deadlines, when you need to schedule a conference call or IM chat, or if you have to be the middleman between the developers and a vendor. Questions take about 12 to 24 hours to get answered, at least. Live discussions are going to be really late at night or really early in the morning. And because it’s a different country, their holiday schedule is different from ours. It’s not like a co-worker in the same office that you can simply tap on the shoulder when you have a question.
(I will say, if you have a 9-to-5 job and live in the States, working with someone on the opposite side of the world at least lets you know they’re working “at night,” so I guess that could be a plus.)
Communication barrier - The team that I worked with was very intelligent and knowledgeable, and despite their being Indian, they spoke English very well. Still, there was a small communication barrier that was compounded by my lack of technical knowledge. Between a heavy foreign accent and some Internet jargon I have never heard, phone conversations were impossible for me. (I live in New York - I’ve heard foreign accents!) The simplest way to combat the barrier is to use IM chats and email for discussing the project. It’s a lot slower, and seems less “real,” but the important thing is to be sure you’re on the same page as the developers. I’m a phone person, so I wasn’t crazy about this. When it comes to explaining some issue that I’m unfamiliar with, I’d prefer to have a phone call not an IM chat.
Also, they sometimes would send a request to forward to a vendor - say, the server host - that would be in complete tech. jargon. There was no way for me to evaluate the request before sending it over, or reading the vendor’s response to see if they were on track. Basically, the communication barrier occasionally prevented my involvement except as a middle person relaying messages. Not fun.
Lack of serious technical guidance - Considering my lack of understanding of developing a web project, I was pretty much relegated to describing how it seemed to work from the perspective of the user. I couldn’t choose between Linux or Microsoft for our server, or PHP vs. RoR. I didn’t say we’ll use HTML or HTML5, or what would be JS or Flash. They chose all of that stuff without so much as asking if it was OK. I’m fine with it, because I did some research on my own, but it’s not as if they explained why they chose one course of action over another. Why they used a particular version of a PHP, or made the choice of that language over any other the others. If that’s important to you - if knowing why is so important - you need something more than just a developer. You need a technical consultant or an in-house developer or something like that. An offshore company won’t do that for you.
On the other hand, I suppose you could tell them which language to use. But for non-technical founders, I can’t imagine you would do that (or even think to do that). Though if you’re building a native mobile app, picking the OS pretty much determines the language, AFAIK.
Ambiguities during the proposal process - At one point a certain feature that I had specifically described in the proposal - the email publishing feature - was being prepared to start in the development process and during the discussion I was told that the feature as I described it - which I thought I had been describing identically since the very beginning - was not included in the original proposal. A Change of Work order was needed to “add” the “new” functionality, which of course meant I had to shell out more money. I went back and forth with the team and my original contact who worked with me on the proposal and it really came down to an ambiguity over the client-side versus server-side work. They had included the first and not the latter. Long story short, the more complex the element, the more careful you need to be in describing your expectations during the proposal. Not that it’ll make anything less expensive, just that it’ll be easier to predict your costs, timeline and workload down the road.
This sort of ties in with the “lack of technical guidance.” Had it been explained that I wasn’t describing the entirety of the function, or that their proposal only covered part of a functionality and not some other mandatory portion simply because I hadn’t specified its inclusion, I could have avoided that confusion and “increase” in the cost. Alas…
No developer-side “investigation” - One aspect of the project requires the use of two APIs, and though I had written in the proposal what I expected I didn’t realize it was incumbent upon me to source and provide those APIs for use. (In their defense, it’s in the contract.) Not only was I expected to source and provide the APIs, I needed to decide which APIs we would use, and how, and provide that direction to the developers. This also ties into some of the other “dislikes” I mentioned about a lack of technical direction and input, but on top of all that, sourcing these deliverables wound up with me having to explain why a particular API would work despite their opinion to the contrary. (The API we were discussing is from Foursquare, and I’m guessing they never worked with the API before.) It took a little over a week to get them to use the APIs in the manner I envisioned, and I know it’s simply because they didn’t do much investigation on their end. The element is really rather basic and takes cues from dozens of variations of the same system. On top of that, Foursquare built a great API that seems simple enough to use - even to a non-technical person.
The great unknown of what I’ll do when it’s done - Perhaps the hardest part of working with an offshore developer comes at the end: Not having a developer any more. Since I took the path of hiring an offshore - effectively conceding that my idea alone wouldn’t attract talent without being at least minimally executed - I left myself waiting until I actually have the product in hand before I can really start my search for a co-founder or CTO to take the reins on the tech side. Call it an MVP or a prototype or an Alpha product – it doesn’t matter. When this thing is live there will only be me to man the controls and make sure it doesn’t fall apart. Should there be any major hiccups, bugs, crashes, or what-have-you there simply won’t be someone there to get a handle on it and try to find a solution. Plan for this folks.
And that brings me to my final thought, which I also sorta said in my last post: The offshore developer is only going to get your product built, it’s up to you to make it successful. If you aren’t able to code or design a web project, you must bring more to the table than just an idea. Prove the concept resonates with customers, have a marketing strategy, find funding, acquire users/customers - hustle until this thing is successful. On top of that, your development cycle does just that - cycles. You will have future iterations and updates that need to be decided, conceptualized and developed. You will be building for the life of this web project. Period. If you’re the only founder working on this project, you simply have no other choice but to do it yourself or watch it whither away. In the end, offshore developers are tools - they are a set of tools that build websites, even if you don’t know how they work.
So then, the real question isn’t whether or not you should use an offshore developer for your project. The question is: Do you have what it takes to see this thing through the build, the QA, the ups and downs, the launch the growth and off into a successful future beyond the initial development?
It’s gut check time.
