,

What should startups consider when outsourcing engineering work?


Outsourced software projects can go off the rails if you don’t plan properly. Project A’s CTO, Stephan Schulze, has some tips

By Merlin Carter

Perhaps your startup is growing too fast, and you can’t keep up. Maybe you’re trying to throw together an MVP on the cheap. Whatever your situation, you’ve probably considered outsourcing, right?

The thing is, outsourced software engineering projects can go off the rails if you don’t plan properly. We know both sides of the story because we outsource our developers too. So who better to ask about outsourcing than Project A’s own CTO, Stephan Schulze?

You can read or listen to our conversation below:


Have you come across any [startups] that have used outsourced labor at the beginning? And was it a red flag… when making an investment decision?

Merlin: Hi, Stefan… today I want to talk about outsourcing. Outsourcing is a very hot topic in the startup industry because especially if you’re very small and maybe you don’t even have a technical co-founder.

You need to get some kind of technical resource quickly to get your idea out…but a lot of founders I’ve noticed are concerned about getting funding if they use outsourced labor too early or rely exclusively on it.

And so I was wondering, you’ve done a lot of due diligence, at least on the technical side. And you’ve assessed some startups. Have you come across any that have used outsourced labor at the beginning? And was it a red flag, or was it a concern when making an investment decision?

“We can’t invest in a company that doesn’t have… the IP of the product that they want to build.”

Stephan: Yeah, I can share a concrete example. So we did due diligence with a company that was providing a product for a B2B use case. And we found out during the due diligence process that the whole software stack, the whole application, and also the infrastructure, and all that, was built by a Hungarian agency. And this can indeed be a red flag, to be very honest.

And this is for multiple reasons:

The first reason is… there’s a 100% dependency on that agency. Even if agencies are mostly willing to stay longer with their customers, this can be a risk. And this is because the main knowledge about the product, the internals… about the operations and all of that stuff… this is not in the startup we want to invest in, but it’s located in an external company that we don’t have any access to… that we don’t know… that is not really part of the due diligence.

I think the third part… and it’s also something that, especially non-technical founders, often underestimate and sometimes also do wrong… is the question about IP (Intellectual Property).

So if your product is developed by an external company and you… by mistake, just didn’t have a good look at the contracts that you’re signing… It can happen that all the intellectual property of your product and the whole product itself… is on the agency side. And that’s definitely a red flag. We can’t invest in a company that doesn’t have a tech asset or the IP of the product that they want to build.

So this can be a problem. Everything is solvable. So it’s a thing to discuss, but these are definitely potential red flags.


What do you think about… getting outsourced labor to build a prototype or an MVP?

Merlin: Hmm… but what do you think about the… perhaps more limited use case… of getting outsourced labor to build a prototype or an MVP, just to test… to see if you have product-market fit?

Because we recently had this discussion about MVPs. And building them as minimally as possible with less cost as possible. So that would be an ideal use case, wouldn’t it? Because you probably wouldn’t run into the intellectual property issue… because you’re going to be perhaps throwing it away. If you realize you have product-market fit.

So would you say that what was a good limited use case for outsourced labor?

“…the main question that I would ask is…does it make sense to continue to build the product further with that agency?”

Stephan: It can be for sure because I think one of the advantages is definitely that it’s mostly cheap… for a proof of concept anyways… for an MVP… to a certain point, yes.

I think the main question that I would ask is, does it make sense to continue to build the product further with that agency?

This is, I think, the main point… because, as we discussed in our previous session, there is a certain point when you say…OK, now you’ve found that product-market fit… and one of the problems that you then have is… you are starting to become more and more dependent on an agency.

Because your company wants to grow…maybe you already have business angels. They didn’t do a deeper look, but they also want to have their returns, they’re pushing you forward… and you’re suddenly in a situation where you can’t say, “look, I need to insource that product that the agency created for me… because now I’m going to do it by myself”.

And this is what I see [as] critical. I think there are ways around to mitigate that… in terms of trying to build the MVP really as a throwaway product and then take that into account… “Okay, now we understand what the need is”.

Or maybe even the MVP product is nothing that requires software engineering or anything else… it could also be that you have a couple of tools… a low-code or no-code platform… that you just use to click something together… and that also proves product-market fit.

And then you’re starting to build the real product by getting external support. That could be an option, right? You can still use the agency, but then you know what they build and how to insource it… and you know it from the beginning, or you hire some software engineers by yourself who can help you build the product in the proper way.

But anyway, I think whenever you work with an external party, I think this is the biggest thing. Make sure that you own the IP. This is just the most important thing. If you create a company and work with an external party, make sure you own the IP.


How do you make sure you own the IP?

Merlin: But if you’re a CTO and not a lawyer, how do you make sure you own the IP?

Do you do, are you familiar enough with contract clauses to make sure you’re not getting tricked, or what have you?

Stephan: Yeah, I think the main point is if you start such a relationship, then you… when you are not able to be sure about that specific clause in the contract by yourself, ask a lawyer.

So ask someone to validate that you are the owner of whatever the agency is creating. And maybe the second [piece of] advice in that regard as well… my recommendation would also be to start to use your tooling from the very early beginning on.

So this can mean something like a project management tool. This could also mean that you own the AWS account, the GCP account, or the Azure account where the application is running. The agency is more the party that’s contributing to that. And also using your GitHub or GitLab for source code control… compared to… they just do everything in their set up because they promise it’s faster, it’s cheaper. In the very end, it will not be faster and cheaper because, at one point, you need to migrate that. And that becomes very expensive then.


What are the [other] things that you need to keep an eye out for?

Merlin: Yeah, that’s interesting. I was going to ask, assuming that you’ve made the decision. Okay. We do need some outsource labor for some things… what are the things that you need to keep an eye out for?

And so that’s one thing on the list already… is account access and tooling. In fact, I remember you talking about… a conflict or tension between a startup and an agency because the agency controlled all of the accounts and the developers couldn’t get access, or it was an elaborate process to apply for an account.

So you would avoid that by negotiating that right at the beginning with the agency and saying… “we need to own the tooling”.

“…if they are hesitant in… providing you the ownership of the toolset… I would be very careful to build a relationship based on that…”

Stephan: Yup. But I would not even negotiate, but this would be a requirement to work with that company… because if they are hesitant in terms of providing you the ownership of the toolset… the infrastructure, and all of the stack… I would be very careful to build a relationship based on that… especially if you are interested in a long-term collaboration.


Shouldn’t people go for the cheapest option, or are there other concerns?

Merlin: Yeah, that’s true. And also, I remember there was a discussion about nearshoring and offshoring, and I guess nearshoring means within the European Union, if you’re a European startup and offshoring is for countries that are further afield, like India or Vietnam or wherever else, what would help people would make that decision?

Shouldn’t people go for the cheapest option, or are there other concerns?

Stephan: Yeah, I think it heavily depends on what you want to build and what kind of quality to expect. At least from experience… I can say it’s way easier to manage people and develop a product in collaboration… when you’re in a very similar time zone, where maybe have a difference of three hours… I think that should be the maximum timezone difference because then you can always jump on a quick chat or call to just align on a couple of things. This becomes way harder if there is a 12-hour timezone difference.

I think from a quality perspective… if you outsource development or software engineering, you must be very close anyways to make sure that you get what you want… because a lot of information is going to be lost in translation…always, right?

That’s why you create tickets and all of that stuff to minimize that, but there will still be a loss. If you’re not very close to that, you’ll maybe end up with something that is not exactly what you wanted.

I think there are these famous cartoons out there, what the customer wanted, right? With the tree and the ring being hung on the tree and at the end, the customer (or the product manager, maybe) really wanted something simple.

The image that Stephan referred to (Source: Coding Horror)

But what he or she got was chaos… and this can happen easily if you’re not really close to the development team in such specific cases. And maybe also to add on that… I think what you should also be aware of is… there can also be cultural differences, right? So culture in Europe is different from the culture in Asia or India, or the US.

So I would also be careful of that, or take care of that… so that you are… that you have a clear expectation management and that there is a fit in terms of “okay, we understand each other really”… and not just that the other party is always saying “yes”, but didn’t really understand… or just understands one-third of what you are actually saying.


I know one example of a product manager who went to Pune in India. Have you ever done [something like] that yourself?

Merlin: That’s interesting you mentioned that because I’ve read about a couple of cases where the tech leads or the CTO… they went to the location where the outsourced team was and spent three months there and built up a rapport, a relationship with the people… got to know them a little bit and their personalities, and it made it a lot easier when they returned.

I know one example of a product manager who went to Pune in India, and she spent a couple of months there and did activities after work with the team. And so there was a real team dynamic, and I think it built a bit more of a sense of responsibility. Have you ever done that yourself?

“treat them as your development team.”

Stephan: Yeah. So I haven’t done it by myself because I was always working with the portfolio companies, but I know that this happens.

So one of our private equity companies or investments is working with a company located in Romania. I know the tech lead… the head of software engineering, was there multiple times a year, even per quarter… I think, on a two-monthly basis. So one month they came to Berlin the other months, the team, and it’s not just heads of engineering, but also others went there… to just build that relationship.

I think you also touched on one very important point when you gave the example of that product manager, where somebody’s going to the location where your development team sits: you should treat them as your development team.

It should not be that… these are some people out there somewhere, but it should be the way to say, “these are my team members… I care about them as I care about my other team members. They are just sitting in a different location, and yeah, by accident… they are on a different payroll, but at the very end, I’m also paying for them… so I should really treat them like… being part of the team… with team events, maybe some kind of perks, like a nice t-shirt right… or “ happy birthday” cards or whatever.

So whatever you do internally, you should also do with your external team to really create that collaboration and relationship because everything else will just… frustrate both sides at the very end. And this…by the way… is often underestimated in terms of effort and costs and so and so forth!

Because you could say, “Hey, these guys are just… they cost like €300 a day. That’s super cheap. Let’s do that!” But if you would like to do it, then you need to add these costs for flights, hotels, like onboarding, and all of that stuff. And this then [adds] up.


Would you do one-on-ones with outsourced developers?

Merlin: Exactly. I was just curious, would you do one-on-ones with outsourced developers as well? Like your own?

Stephan: Absolutely. Yes, absolutely. Yes, definitely. I saw the best results always with people who are mixed together… so that you create hybrid teams where some people are from your own company or employed by yourself… because this way… you have multiple advantages… on the one hand, you are able to shape and create culture… because you bring two different companies together… right? But you still own the team in a way that… you have your own people.

And the second part to not underestimate is… what are these people doing? …what product are they building? You should not estimate the point of… if an external team is building a product for you… they own all of the knowledge of that product. So they know about the internals, they know about how it works and what problems it has, and so on. And if at one point they leave, you’re really screwed because then you have that black box… it’s running, but nobody even knows…where maybe the source code is… someone looked at that… and good luck with fixing or developing that further!

That can really be an issue, then.


We send our developers out to our portfolio companies… we try to avoid those problems

Merlin: That reminds me of the fact that we are also in the outsourcing business, so we can see things from both sides. So we send our developers out to our portfolio companies. They work on projects. Technically, they are outsourced developers. And we try to avoid those problems with decent handovers and documentation…

Stephan: But also… sorry to interrupt you… but I also think by enforcing that we are not working alone… we are always embedded in a team.

This is, I think, the main point, all of this knowledge transfer and documentation and all of that stuff… that’s way easier to be done when you have somebody who you’re working with… because then knowledge is not just built up in a single person or a single team… but in the portfolio company in our case.

And this is the most important thing.


What are the experiences in the portfolio? Is it consistent, or is it hit-and-miss sometimes?

Merlin: Yeah. You anticipated my next question because I was thinking of the way we work, and… we can’t force our portfolio companies to treat our developers in a certain way or … incorporate them in the way that we want to.

But do we have some kind of charter or kind of info pack? Where we say, “this is how we would like you to work with us, please follow these guidelines”. And do they follow the guidelines? What are the experiences in the portfolio? Is it consistent, or is it hit-and-miss sometimes?

“…I personally did the mistake to not enforce our team being embedded into the other teams”

Stephan: So we don’t have a written charter or anything like that.

I mean, we are …if you see the Project A portfolio… I very much see it as a Project A family. This is what we are. So we are in close and regular contact with our counterparts on the portfolio side anyway… so… we also have that… very short way of communication, the possibility to do that.

If you speak about potential support, then we already align on… what should be the scope? What should that look like? And there… just speaking for my colleagues and me… you bring that part in of… “okay, what kind of team is it personally? …is this person going to work in? How do we organize that?”

And I personally made the mistake of not enforcing our team being embedded into the other teams, and to be very honest, that wasn’t a very pleasant experience for all sides.

We had the situation that we have a team independent of the other teams, not being embedded, not being able to access all the necessary information and so on… and this didn’t [go] really well. But having these short ways of communication… this way, I’ve been able to solve it. Right. And now we are in that mixed and hybrid setup, but I know… for myself, never ever, we’re going to do something like that [again].


If you want to expand your team, you need to treat them like a team

Merlin: Yeah… I think that’s a very common problem that people from outsourced companies or teams get treated like invaders or outsiders and are given the worst tasks… or cleanup tasks that no one else wants to do. And it’s the wrong way to go about it. If you want to expand your team, you need to treat them like a team.

Stephan: Exactly. And this, by the way, means also that you should run them through [your] normal recruiting process, right? Because I would always do like normal tech interviews… then get to know the team, and so on… with every outsourced person that I’m going to work with. Because I must make sure… that if I embed them into my teams… this is going to work.


You want to make sure that it’s a cultural fit

Merlin: That’s a good point because I remember hearing some personalities don’t get on with others. And so you want to make sure that it’s a cultural fit… that quiet people work with quiet people… or extroverted people work with extroverted people. And if the outsourcing company is just picking people who they want to use and you don’t get any say in that…then you often end up in these kinds of conflicts or bad team experiences, right?

“…it’s also very important to manage the relationship, like on a business side, in a very close way…”

Stephan: Exactly, I mean, that’s the second part. There’s one part to working with these external partners having one-on-ones… make them part of the all-hands… whatever you do. But on the other side, it’s also very important to manage the relationship, like on a business side, in a very close way… to have your dedicated contact person… to be in regular contact with that person on the agency side, for example, to also understand whether there are any problems that maybe are not visible to you, but maybe affect the team. So it’s a full-time job at the very end… it’s like full team management


If you want to have an outsourced team that’s low touch and not integrated… maybe an MVP or a prototype would be a good use case

Merlin: But if I could summarize the lessons learned, it would be:

If you want to have an outsourced team that’s low touch and not integrated, or that you just want to give them a job and do it and hand it back… then maybe an MVP or a prototype would be a good use case for that.

But if you’re going to have an outsourced team that’s really working with your in-house people and really getting deep into the product, then you really want to have the most thorough onboarding process possible.

“…if you do a project approach…this is maybe something that you can hand over to an external agency…If you are doing product development…please don’t do that with just an external team…”

Stephan: Yeah. And maybe we can also put it that way: if you do a project approach… so having a fixed goal, start and end date, this is maybe something that you can hand over to an external agency. Still, make sure that you monitor them closely so that you get the quality you expect.

If you are doing product development… so iterations.. with just steps following each other… then please don’t do that with just an external team, make that part of your team because it’s your product.


Merlin: Gotcha. Excellent. Thank you very much for that. And if anyone listening has further questions… because it’s a very multi-multifaceted theme, feel free to fire away, but for the time being, thank you very much, Stefan.

Stephan: Thanks a lot. It was a pleasure talking to you, Merlin.