When people think of outsourcing their software development, many people assume it is a cut and dry process which involves providing a team some instruction as to what they want built and letting the development firm take it from there. In reality, building an application involves a lot more involvement and attention from the side of the product owner, and the nuances of how to engage in an outsourcing firm are discovered after they are already called upon to do the work. This article’s purpose is to help clearly define the main two styles of engagement - outsourcing and outstaffing - and how they are best suited for a given client.
A Rose by Any Other Name….
Unfortunately, the first thing you might run into in searching for a development partner is the complete lack of standardized naming conventions across the spectrum of outsourcing firms on the market. Dedicated teams, custom software development, stand-alone developers, engineers on demand - there are about as many names for engagement models as there are outsourcing firms on the market, but for the most part, the two main categories boil down to outstaffing and outsourcing.
Outstaffing - Augmenting a Technical Team
The more simple model, outstaffing, is essentially a way to hire extra manpower to boost your existing technical team and provide extra hands on deck to improve the velocity and bandwidth of your application’s development. In this case, you are looking for a specific engineer, or several, who fit a particular niche in terms of experience, technical background, cultural fit, and of course are provided at the right price and are available soon!
To complicate matters, most outsourcing firms offer outstaffing services, and rarely does a company actually call itself an “outstaffing business.” Despite this slight confusion, it’s fairly easy to recognize the model when you start communicating with a firm - if they offer engineers instead of solutions, it means they are attuned to the outstaffing model. Here in Ukraine, outstaffing is considered to be the “low-hanging fruit” of the business sphere, as it’s far easier to screen and provide qualified engineers than it is to architect, lead, and put into production an entire application from scratch!
Still, a lot goes into making sure that the engineers an outsourcing firm employs will be up to scratch when it comes to assigning them to a commercial client. At Binary, we’ve dedicated an entire Academy to the process, and for a given outstaffing vacancy we often review over a hundred candidates to find the perfect match. Good development firms go beyond simply matchmaking available developers to open projects - they also invest in the further training and development of the engineers themselves to ensure they are competitive on the market and up to taking on the most challenging tasks a client may have to offer.
The crucial difference, however, is in where the management of the development process itself lies - in general, outstaffing engagements assume a technical lead on the product owner’s side, who has processes and methods in place, and who has a clear vision for what the product should be. Although it does occur occasionally that an outsourcing firm “takes command” of a project and the product owner’s technical team adapts to the outside firm’s processes, it’s quite rare.
Instead, the product owner’s CTO or Team Lead recognizes the need for extra development resources and builds a profile of what sort of engineers they are looking for, and the outsourcing firm tries to provide engineers that fit that profile. The outstaffed engineers are expected to adapt and conform to the existing processes on the client-side - using their sprint schedule, management/communication tools, and receiving direction from the client.
Depending on the relationship, the outstaffed engineers can also be subject matter experts and provide advice/direction on a particular technology or functionality that they are more familiar with, but in the end, they receive their orders from the client’s technical team and are directed accordingly.
In all frankness - outstaffing is by far the better position to be in for both the product owner and the outsourcing firm, as it assumes competent technical leadership on the product owner’s side and the main problem is simply a lack of manpower to get the development cycle finished. However, if there is no internal technical direction or engineers present and no plans to find any, then one must consider the alternative - outstaffing.
Outsourcing - Total Development Management
Traditional outsourcing models involve a development firm handling the entire end-to-end development cycle by themselves, with minimum management from the product owner in the process. There are a few nuances and misconceptions to address right off the bat with this model:
Minimum management does not mean minimum engagement. A product owner’s input and communication are still required for the development’s success, especially in the case of an agile development approach which feeds off the end users’ input to provide feedback and help steer the future course of an application’s development. Often we get contacted by clients who have an idea for an application and perhaps have detailed specs for the platform - but assume that once they hand those specs over and get a detailed, accurate estimate (which in itself is a bit of a fallacy - as I’ve written about before), they can simply send over some money and walk away for a few months while the application is created.
This is obviously not a sound strategy for building a successful platform, as even the best and most experienced engineers will have questions regarding the nature of the business they are building an app for and will want to clarify the product owner’s vision before spending hours of time and thousands of dollars on their interpretation of what the app should be. This is why we insist on having close, direct communication with product owners and also encourage having two-way communication access between all of the engineers on a team and the product owner, to ensure everyone is on the same page and to address questions quickly so that development time is used optimally.
Product owners will always have a better grasp of the business realm of an app versus the engineers building it. Often we will get requests to simply “build an app like X” where the product owner expects us to do the market research and make decisions based on a business realm we are completely unfamiliar with. Even in cases where we are familiar with the business realm of a given application, it still ultimately lies in the hands of the product owner to give a clear indication of what exactly they want to be built.
The best engineers in the world do not mind readers - and unless a given engineer has managed the business side of a similar application before (a very rare trait indeed), they will never have more pertinent knowledge of what the platform should provide to its users than what the product owner would have.
That is not to say that a good engineer can’t provide great suggestions in terms of UI/UX, options to scale the platform, features which can be added, and risks to be considered during the development process. Binary Studio in particular seeks out engineers that have a high degree of ownership and treat the collaboration with a product owner as actual team members - they are invested in the actual success of the platform. However, even our most seasoned developers would be hard-pressed to say which features a particular niche user base may or may not require, and what would provide more revenue through a given app - that’s on the product owner to decide.
Proper planning is essential. We receive the entire spectrum of requests for proposals (RFP’s) and tech scope documents from hopeful product owners looking to get some insight on how long and costly a development cycle may take. These materials range anywhere from random scribbles on a napkin (not kidding) to 80-page detailed technical documents with user stories, wireframes, and clear bullet-point lists of what features should go into the platform and how they should be prioritized. I can tell you with certainty that we prefer the latter, and that they are a good indicator of the short-to-mid-term success of a given platform.
By providing an outsourcing firm a clear idea of what you want to build from the start, you’re going to have several advantages -
- Any initial estimates are going to be more precise.
- You will reduce the amount of back and forth from developers who are new to the project - this applies to when the project starts as well as engineers who are onboarded later, who can refer to the documentation you prepared in the beginning to get an idea of what the platform is about.
- You will also demonstrate your commitment to the project’s success, and outsourcing firms are going to be more willing to work with you, provide deals, and make firm commitments on the project. This may sound unnecessary, but in the current market, there is an actual competition to consider as good dev firms may have a backlog several months out to consider. The more promising a project looks, i.e. the more likely the application will be a success, the higher on the “queue” you might find yourself when working with a top-tier dev firm.
With these things in mind - providing a clear vision of what you want to be built will yield much more positive results for all parties as opposed to leaving things entirely up to the discretion of the development firm.
Outsourcing firms always prefer starting from scratch vs. taking over a project, and not because it’s “more money if they write it from scratch.” Product owners often complain that when engaging a new development firm on an existing, the first question from the outsourcing side is whether they can abandon the old code in favor of writing everything anew. It’s assumed that this is because it means more revenue for the development firm (starting from scratch = longer development cycle = more money) - but that is surprisingly not the reason in most cases.
Planning an application from scratch is a lot more predictable than trying to figure out how to take an existing platform and bring it into production. Consider the following points:
- If the existing platform has no clearly written technical documentation, it will take significant time (usually several hours) of research and digging in to figure out the inner workings of the platform. This must be done in order to provide any sort of estimate, as the difference between building on top of an application that uses best practices vs. spaghetti code is the difference between building a house on foundation or quicksand.
- If the platform is indeed composed of spaghetti code, the new development firm will be in the awkward situation of having to explain why the client should throw away all their previous work because no amount of refactoring/rebuilding is going to completely fix the fundamental problems on such a project, and there will always be stability, scalability, and general issues to go deal with. Such projects, by the way, are a nightmare for the developers to work with - and as there is no shortage of other projects on the market for them to work on, so it will be hard to maintain a standing development team on such a legacy platform for long.
- Inevitably, an existing project will utilize technology, framework, integration, or tool that the new outsourcing firm will be unfamiliar with, and will require extra time to get acquainted with versus using whatever tools they already know if they were to build it from scratch.
- There is often not a clear vision of what is left to do in a half-finished project. Often the previous developers are unavailable to discuss how and why things were implemented in a certain way, and the general air of confusion and uncertainty makes estimating and preparing for such development cycles a very risky endeavor.
Therefore, it is recommended in these situations where a handover to a new development firm is expected to provide ample documentation, guidance, and communication with the previous developers to allow as smooth a transition as possible and to be always wary that a complete rewrite may indeed be the preferred option for all parties. When in doubt, a product owner can present the case to a 3rd party consultant (who has nothing to gain in convincing the product owner to throw out the legacy code) and make a decision based on their input.
Final Thoughts on Outsourcing
While it is clear that outsourcing an entire application is a much more involved process than simply finding outstaffing resources to augment an existing team, it does not mean it's not a reasonable course of action for a business to consider. Indeed, in many cases, it is a far more practical solution to rely on a development firm’s established processes and technical management to develop a software solution than it is to build a dedicated in-house technical team from the ground up.
Just be prepared to conduct due diligence and invest the proper amount of time and resources into your application’s planning stages and development, and you can be confident that the platform will be, at least on a technical level, built in a proper and timely fashion.
