Developing MVPs in Symbiosis: How to Bring an In-House Team and Outsourcers Together

Hi! My name is Elvira, and I’m a project manager at Purrweb — a studio that develops MVPs for startups and businesses. We often create products in symbiosis with our clients, for example, if they need help with analytics, frontend, or mobile app design.

Outsourced services often save the day when there is insufficient time for in-house development or a client needs unique expertise. But, at the beginning, some clients fear that teams won’t get along. And what if the project doesn’t develop as it should? Conflicts, faults, or night bug fixing — such scenarios can scare the heck out of anyone.

Let me reassure you, it’s not always the case. And these things never happen in projects with a well-organized management system. In this article, I will give you a step-by-step guide that will help you bring in-house and outsourced teams together. Read, learn, and use it as you like.

Step 1. Introduce teams and present your work plan to them

Sometimes, it happens that, in the beginning, teams see each other as competitors. But, from my experience, I see that it happens because of the lack of communication. In the introduction stage, it’s important to explain to the in-house team that you don’t want to replace them — every team will just be responsible for its own tasks. It’s important to show the outsourced team that no one will teach them how to work or question their expertise.

⭐ Lifehack: the more all the project participants communicate, the faster competition melts away. On average, teams grow accustomed to each other over two weeks if you properly introduce them to each other and provide an environment for future communication.

This is how you properly introduce in-house and outsourced teams to each other 👇🏻

✔️ Organize a common meeting — before the work starts, introduce the teams to each other. Organize a kick-off meeting. There, you should discuss the global task pool and determine the criteria for the development final result. So, since the initial call, every project participant will know who is responsible for each task.

✔️ Map out the first steps inside the teams — every team will have its own tasks to form the general result. During the next meetings, you can correlate internal plans and map out control points for the project.

Case from practice. Once, we worked on an app for vending machines — Vendify smart fridges with ready-made food. We had to make a design and frontend architecture to help the frontend communicate with the client’s hardware and backend. We made a team of one project manager, a UI/UX designer, and two frontend developers.

First, we prepared a UI concept: a dark theme that would match fridges. Also, we attached photos of the actual products from Vendify machines. To finalize this stage, we introduced our designer to the client, although we try not to bother creative employees with calls. This solution helped us quickly get corrections approved and move on.

The stack (the toolset) was selected by the clients themselves. They used Ruby on Rails for the backend, whereas we worked with React Native. We wrote the backends and frontends at the same time and discussed the workflow and important solutions via Slack and calls. As a result, we met the deadline and finalized the MVP in six weeks.

Look at the Vendify app we finally got 👇🏻

Step 2. Set the deadline, decide on the responsible employees, and calculate the KPI

The global agreements on the projects must be common. Of course, every team has its own internal indicators, but you must set common deadlines too. This way, the in-house and outsourced teams can meet at a specific point and finalize the project.

To synchronize by dates and intermediate results, I recommend you create a couple of charts and use them to discuss everything 👇🏻

• • General project chat with the client — there, you’ll decide on the main agreements. However, there shouldn’t be much information regarding the workflow, or it will turn into a mess.
  • Specific chat for developers — it will ensure contact between the guys who work with the code, for example, when one team writes the backend, and the other — the frontend.

For a good result, you need to ensure communication transparency and avoid interacting via private messages. Otherwise, the other team won’t understand how development is evolving or if the task will be completed on time. For example, once, a team lead made new agreements, and I didn’t know. Don’t do this.

⭐ Lifehack: To properly determine your project agreements, prepare a contract with endpoints. Endpoints are a list of API points or a description of the ways teams can interact. Here, it’s important to decide who will send information and which format they will use for that. Also, you need to agree on who will receive it and how they will do it.

A contract with endpoints will help not to stall development. With it, the frontend and the backend can work simultaneously. In other cases, the frontend will have to wait for the backend to see what it gives and how it does this in real-time. With a contract, everything is going to be clear.

Case from practice. We had to adapt a CRM of Koblik Group, an agricultural machinery manufacturer, for a mobile version. Our system analyst was responsible for the flow. He had to find out what features the company’s managers needed for work in the fields. He communicated with the client and determined their needs. Without extra features, the client’s CRM shrank down to three sections: Calendar, Partners, and Interests.

We started development with project design. It was a complicated process — the client’s developers were busy with internal tasks. But daily communications via chats, calls, and healthy mutual aid helped avoid flaws and speed up the work. As a result, we made a clear API contract. There, we described what data the app supported, what requests would be sent to the server, and what responses could be expected. Thanks to this contract, the development took only two months.

See the result of our cooperation with Koblik Group 👇🏻

Step 3. Give all the participants access to any project-related information

Task trackers, storage, and files with important project information must be open to everyone. This way, it’s possible to provide access immediately as something new appears. In this case, teams will have no lags in their work, and all the participants will be able to find the necessary data quickly.

The project must also have a common board in any task tracker, like Jira or Clickup. Even if it will be inconvenient for some teams, everyone will share the common vision of the project and have the opportunity to check against the global goals. Also, the common board will help project participants feel they are part of a bigger team, not just isolated groups.

⭐ Lifehack: Don’t keep a task tracker just for the sake of it. If it’s inconvenient for your team to work on a common board, decide who will use it and for what purposes. For example, you can make a few levels, where you will note tasks for different development stages.

Step 4. Organize communication and educate teams on your product

It’s interesting that some people are still nervous about calls or find them unnecessary. You should discuss not only intermediate results but also some unclear moments.

⭐ Lifehack: If you don’t understand your colleague after 5-10 messages, call them. This saves time for all the project participants. Messages are tricky — you can spend an entire day texting each other and still get the wrong idea about your situation.

To meet deadlines for sprints and control points, we implement project design and risk management. The idea is that it’s better to estimate possible issues and risks before your project starts. Think of your bypasses beforehand instead of searching for a solution when one of the teams is on fire.

Case from practice. A client trusted us to make the Broex crypto wallet app. To start development, we had to quickly puzzle out the crypto world. The client came to us with a ready-made web version of their product, but they couldn’t handle the mobile app. Our task was to release a cross-platform app to immediately get it to the App Store and Google Play. Moreover, we had to use the backend which was not written by us.

To work with blockchain and cryptocurrencies, you need to be more than just good at developing apps. Dig deeper. You must understand how they buy, exchange, transfer, and withdraw cryptocurrencies. Don’t forget about rounding, calculating balances, and commission fees. As a matter of fact, we had to study the topic as thoroughly as we could, otherwise, we would be able neither to work with the client’s backend nor to ensure a convenient and safe flow for users.

Look how we managed to make Broex 👇🏻

Step 5. Gather together to see intermediate results

Traditionally, we divide the product workflow into sprints. One sprint is one development stage. To synchronize during a sprint and discuss its results, we constantly socialize in various formats.

Here are all the important meetings and discussions 👇🏻

✔️ Daily it’s a daily meeting that helps synchronize inside a team. If your project involves in-house and outsourced teams, you don’t have to organize dailies for everybody. But a 15-minute daily with your team is a must-have.

✔️ Sync is a text daily. You don’t have to conduct them every day. But if you think your project lacks clarity, you’re welcome to use this format.

✔️ Weekly is a weekly meeting where you discuss all the questions. As a rule, we invite both teams to these meetings. This way, we stay in contact with each other (and reality).

✔️ Retro is a meeting where we review the sprint results. Here, we can and should reflect. The goal is to understand what’s cool and what needs more effort.

⭐ Lifehack: Speak if something is wrong. Talk about it at syncs, in development chats, or during dailies.

Step 6 (if a client needs this). Prepare the project for passing it on to the in-house team

Sometimes, after cooperation, a client passes the project to their in-house team. It should be neither a tragedy for the outsourced team nor a source of stress for the in-house team.

Here, we’ll use a case from practice to tell you how to let your project go 👇🏻

Case from practice. We developed an MVP for remote renovations in the UAE. The Settler app helps control this complex process from all over the world.

The user can watch the renovation stages: what’s finished, what’s yet in progress, and what’s to be done. Also, we added expense tracking to the flow: the project budget, checks, and bills. We managed to save over $12,000 of the client’s budget, but, later, they still decided to develop the project with their own team.

To make the transition of Settler to the in-house team as flawless as possible, we created a universal plan. Here it is 👇🏻

✔️ Collect documents. We prepared documents with access information for all the services and listed non-priority bugs in a separate file. Also, we checked the acceptance criteria and left the test case results to the client.

✔️ Update the UI kit. We included all the styles, options, and states. We also created a Figma file with all the screens and developed a user-friendly navigation for various scenarios and roles.

✔️ Make a file with all the plans and ideas we had discussed with our client. There was a product manager on the client’s side. We made a document for him in which we described all entities in the admin panel, roles, and basic flows. Also, we advised on team selection.

✔️ Have calls to discuss our internal project processes and hold an onboarding session. We explained the code structure and the tools we used to the new employees. Then, we answered their questions and passed on the code.

✔️ Make a general chat with developers. This made the new team’s work easier in the early stages and helped deal with difficulties.

Here is the Settler design flow 👇🏻

Summary: how to organize the in-house-outsource cooperation

✅ Conduct a kick-off meeting for all the project participants. Distribute roles and discuss global goals.

✅ Create a few chats: the first one — to note general agreements, and the second one — to discuss the development flow. Interact only in these chats, not in the private messages.

✅ Make a common project board and open access to all the participants. Don’t forget about access to specific storage and files.

✅ Meet your team during dailies to map out plans for the day. Once in one or two weeks, meet your client to monitor the control points.

✅ Speak if something is not by the plan. Talk to your colleagues during calls and in chats.

✅ If you plan to pass your project to the in-house team, ask your contractor for project documents and conduct an onboarding session for your team together.

If you want to learn more about cooperation with outsourced teams, visit our blog!