Pros & Cons of bringing web development in-house?

October 9, 2009 11:33 AM

Pros & Cons of bringing web development in-house?

Hi all -
I manage a mid-size e-commerce website. We currently work with an agency to build and maintain our site. We are considering hiring a dev (C# / .NET, SQL) and taking over development... or at least much of it (still may go out of house for UX, front-end dev).

Anyone have any advice, experiences, warnings, etc they can share?

Have you gone down this road? How did it go? What should we watch out for?

thanks in advance!

posted by MeatLightning to work & money (9 answers total)

I think you already have the most important insight: do the 'easy' stuff yourselves, but keep the agency for the innovative stuff. What exactly falls in each group is yours to decide.
posted by oxit at 11:43 AM on October 9, 2009 [1 favorite]

I run a web development firm (of the sort that would be maintaining your site presently).

You don't mention what it is your company is doing with the site. There are a lot of considerations here: what platform is the site built on, (not what languages; what ecommerce solution? Is it custom-built? How is the quality of the code?) do you have a brick-and-mortar presence at all, or are you solely online? What other core competencies do you have?

Companies often choose to go external with things like this because simply hiring a dev or two will not a website make. Qualifying your hire is an intense process and if you're not experienced at programming and code reviewing and you don't know what to look for, you can quickly spend money on an ineffectual individual and not realize they're not a good match.

Further, you'll need to (likely) manage them more than you do the firm you work with.

A lot of this will hinge on the frequency and nature of your changes. If you're requiring custom functionality added to the site on a regular basis, and the costs are too dramatic with the agency, it *might* make sense to find a developer who can work with their code, build what you need, and stay motivated. If you're doing simple changes relatively infrequently, you also need to ask if you'll have the workload to keep a dev busy.

Further, you'll need to consider that an agency typically has pooled resources, and a knowledge base of at least several different individuals. Your guy is your guy. If he doesn't know the answer or have the exposure, you'll be woefully dependent on him to be able to figure it out, where it's typically more likely someone in the firm would be able to handle the issue that comes up.

Naturally, I'm biased in this regard, but I believe that many companies don't have any place in attempting to manage their own in-house development resources. This depends largely on your core competencies—who would your dev report to? who would ensure the quality of his work? how much money do you think you'd save? (How much are you spending on an agency a year vs. a typical dev salary + benefits + taxes?) Do you have a long wish list of additional features that you could have someone work through if they got through all the "basic" maintenance stuff the agency is handling for you?

If you have an immense product backlog, but couldn't afford to have the agency work through everything on that list, then you might benefit. But you'll need to make sure you hire a qualified candidate, and that the source code they'll be working in is in good condition. (Or that they're prepared and capable if it isn't.)

Finally, work with the firm to transition to in-house. Keep them around for support and help with the transition, but explain that your relationship is changing. Don't burn the bridge, in other words.

Good luck!
posted by disillusioned at 11:45 AM on October 9, 2009 [1 favorite]

So here's the thing if what you are doing is e-commerce then it seems like your long term goal would be to bring much of this in-house. I mean your core product is your website having resources on hand to manage day-to-day operations is likely cost-effective in the long run.

I worry a little about the efficacy and efficiency of bringing in a single developer. There are a lot of things that can go wrong here. Bad testing, ugly unmaintainable code, little oversight etc. If your single dev can't figure something out you will be left hanging a bit (or still hiring the outside firm to support your in-house development). Who takes over when/if this person decides to leave suddenly (or gets sick?)

I'd be a lot more comfortable if you were looking at bringing in a team of 2-3 people to maintain your site. This adds a ton of oversight to the process and gives you additional resources that can be counted on. You may want to wait until you're closer to being able to build an internal team then now when you can only really hire one.

BTW, and I live in SF/Silicon Valley so this may be much easier here, If I was hiring one person I wouldn't find it acceptable to bring in a single developer who can't do front-end work HTML/CSS/JS work as well as backend work (I wouldn't expect a person to also be able to do UX work as well - though I have met some guys who can).
posted by bitdamaged at 12:13 PM on October 9, 2009 [1 favorite]

There are many pros, not the least of which are control and speed of response.

The main cons are financial: you're talking about employing a very expensive person who will quickly become pretty irreplaceable. In-house is almost always more expensive, though it seldom looks that way at first.

If three devs from your contracted firm quit or move to Brazil, you probably don't even notice. What if your One Person Who Does It All leaves?

So plan for that.
posted by rokusan at 12:20 PM on October 9, 2009 [2 favorites]

Something to watch out for when you bring someone in-house: you're not writing checks per amount of work done anymore, and there will be people (who may or may not be actual stakeholders in the product) who decide this means they can just start instructing the developer to do stuff. This can be a huge problem with C-level executives, but it can also be just internal users complaining that X is "broken" because it doesn't do what they want it to do. People use the product to try to claim territory, to outplay their internal competitors, to prove that they are king poop of the shitpile.

Make sure, if you do this, that you continue to treat the work like you have been: scopes, signoffs, change orders, single point of final approval, the whole thing. This is the equivalent of me telling you your company should floss - you know you should, but things got busy, and then the cat knocked the floss in the trash can, keep forgetting to buy more...and then your developer will quit and go work for an agency.
posted by Lyn Never at 2:00 PM on October 9, 2009 [3 favorites]

My advice would be to decide what business you are in. Are you in the e-commerce business or the web development business? Whatever the honest answer is -- do that.

(And yes, the answer can be "both" -- but usually it isn't.)
posted by spilon at 2:52 PM on October 9, 2009 [1 favorite]

I'm on the front-end of things, but the problems I had working in-house was that there were a lot of tiny "Ooh ooh ooh, can we do this and this and this?!" and "Oh you know how to X so you must know how to Y! Show me something by the end of the day! Oh man guess what everybody, June knows how to Y!" On top of a ton of over-the-shoulder staring and micro-managing.

Everything Lyn said is spot on. As soon as I realized that I was wearing more hats than I had agreed to -- fancy, pretty hats that normally made an exceptional amount more than I was -- I ducked out.

Working on the same general project can be both rewarding or a bore, depending on how much freedom you give your employee(s). The thing I like about working at an agency is that I work on so many different things at the same time. On top of that, I'm not too much of a people-person so having a Project Manager and Creative Director/other devs and designers around to spot for me really eases the whole process for everyone involved, as well as keeps everything organized and gives me people to go to when I need some direction and inspiration.

Some people do just fine in an environment where they're the lone ranger (I have nothing but admiration for that kind and hope that you can find someone like that if this is the route you choose), so this might not be applicable at all -- but it's something to think about.
posted by june made him a gemini at 2:58 PM on October 9, 2009 [1 favorite]

bitdamaged, I work at a web startup in SF doing UX and frontend dev work. But to say that you wouldn't hire a backend guy who couldn't also handle the frontend work is a little extreme. The backend guys at my company are all well respected in their respective backend specialties, but they didn't want to deal with the frontend work even if they theoretically could. So they hired someone who was actually good at it (me). I'm sure they could struggle through the work that I do, but why would you pay a pro backend engineer to waste his and his employer's time and money on that stuff?

Do you really only hire people who are pros at certain backend stuff AND pros at XHTML/CSS/JS? Are you sure that they are actually really good at both, or just good at one and semi-competent in the other?

That being said, I agree with spilon that you should probably figure out if web development is a part of your overall business strategy or if it's an opportunistic thing.
posted by mallow005 at 6:49 PM on October 9, 2009 [2 favorites]

Great info - lots to think about - thanks a bunch!
posted by MeatLightning at 12:48 PM on October 12, 2009