В этом выпуске: архитектура масштабируемых систем, System Design, объект Temporal, security-релизы января, NestJS 11, Vitest 3, а также стратегии развития Angular в 2025 году.

Comparison of Type Systems in Front-end Languages: Algebraic data types

---

**It’s** almost impossible to believe that we’re already in our tenth year in the industry! In honor of the outstanding commitment by everyone on the team, we’re extremely excited to announce that we’ve been officially recognized by The Manifest as Russia’s most recommended e-commerce developer for 2021!

<Img imageName="theManifestAward" alt="theManifestAward" />

We’re known for the effort we put into our clients’ projects, but we also love celebrating our own milestones. To give you a clear understanding of how much this means to us, we’re going to share a bit more about our journey.

In 2012, our founder decided to form a top-notch team that’s absolutely passionate about creating custom solutions and web applications.

<Img imageName="tracker" alt="tracker" />

Throughout the years, we’ve been able to successfully complete 500+ massive projects for various clients around the world. We do full-cycle development with special emphasis on the front-end portion. We work with JS, React, Angular, Vue, Java, and Kotlin. Our work has earned us the attention of industry experts and the trust of countless esteemed clients.

<Img imageName="perfect" alt="perfect" />

Their amazing success is the reason why we’ve been officially named as one of the best by The Manifest!

For those who don’t know, The Manifest is a B2B news platform designed to help potential clients navigate through the ever-evolving IT, marketing, and business services spaces. In their inaugural recognition, CSSSR made it to the [top of the list](https://themanifest.com/ru/ecommerce-development/companies#most-reviewed) when it comes to Russia’s e-commerce industry!

This recognition means that we are one of the leading service providers and received the most recommendations and great reviews from clients!

Of course, all of this wouldn’t be possible without the loyal support of our clients. We dedicate this milestone to them. Thank you for inspiring our team and allowing us to continue doing what we love to do!

Accelerate your journey towards success! [Drop us a line](https://csssr.com/en/contacts) and let’s get to know more about each other. The entire CSSSR team is stoked to start working with you.

The Manifest names CSSSR as&nbsp;Russia&rsquo;s Most Recommended E-commerce Developer

Comparison of Type Systems in Front-end Languages

---

In the picture down below is Stonehenge, one of the most famous architectural monuments in the world!

<Img imageName='stonehenge' alt='Stonehenge photo' />

<Caption size='s'>
 © 2007 by thegarethwiscombe
</Caption>

It's hard to find anyone who hasn't heard of Stonehenge, yet nobody can say for sure what was the original purpose pursued by the ancient people who built it. In fact, the scientists would be grateful for any text or graphical description from the builders of this monument.

When it comes to “Stonehenges” in a codebase, it can be a great architectural solution that we use every day, building a whole system on top of it without really understanding why we or previous developers built it as they did. Perhaps, they had their reasons, but these are now completely irrelevant. We can't be sure.

However, a lack of understanding regarding the original reason behind implementing a specific element can lead to an occasional increase of complexity.

## The importance of documentation

While many developers truly enjoy making and working with projects that have good documentation, they still tend to feel reluctant to write it. This paradox of a situation exists despite us, developers, understanding the importance of documentation. Still, the difficulty of writing and supporting a detailed description of the code does bear its burden. But is there a way to make it easier? I think there is! Let me show you it in this article!

[<Img imageName='tweet-about-documentation' alt='A tweet about documentation' />](https://twitter.com/mit_csail/status/1405559612326105090?s=28)


## Main problems of documentation writing

The main problem and, perhaps, the root of the rest of the problems is the separation of code and documentation. When we write our code and documentation in different systems (e.g. GitHub and Confluence), we have two different versioning systems for code and documentation. But what does this mean? Well, it can lead to the growth of project support complexity. For instance, every single change in a source code should be manually synchronized with documentation, while every single change in the documentation is to be connected to the source code.

This complexity often stops people from writing documentation at all, they may ask, "Why should we spend our time trying to write documentation for a project in development status?", adding, "We'll write the documentation when we get the completed product". This is possible, but, unfortunately, in real life, a "completed" project is a dead project. All live projects are in continuous development status. Thus, the only way to have good documentation is to write it in parallel with development, making this process as easy as possible with minimal overhead.


Take for example this, at different times and in different places, developers tried to solve this. For instance, Racket language has its own way to keep source code and documentation as close as possible by using [Scribble](https://docs.racket-lang.org/scribble/), which allows us to integrate Racket code, including evaluating it inside the documentation:

```racket
#lang scribble/manual
@(require (for-label racket))
 
@title{My Library}
 
An example of the Racket code:
 
@racketblock[

(define (nobody-understands-me what)
 (list "When I think of all the"
 what
 "I've tried so hard to explain!"))
(nobody-understands-me "glorble snop")

]
```

In another example, if you're an Emacs enthusiast, you can use the awesome tool/language called [Org Mode](https://orgmode.org/), which allows one to write complex documents, evaluate source code of different programming languages, and use the [Literate Programming](https://en.wikipedia.org/wiki/Literate_programming) paradigm to keep all your source code within the documentation. Here's an example from its home page.

```org
#+title: Example Org File
#+author: TEC
#+date: 2020-10-27

* Revamp orgmode.org website

The /beauty/ of org *must* be shared.
[[https://upload.wikimedia.org/wikipedia/commons/b/bd/Share_Icon.svg]]
** DONE Make screenshots
 CLOSED: [2020-09-03 Thu 18:24]

** DONE Restyle Site CSS

Go through [[file:style.scss][stylesheet]]


** TODO Check CSS on main pages 

* Learn Org

Org makes easy things trivial and complex things practical.

You don't need to learn Org before using Org: read the quickstart
page and you should be good to go. If you need more, Org will be
here for you as well: dive into the manual and join the community!
 
** Feedback

#+include: "other/feedback.org*manual" :only-contents t
* Check CSS minification ratios

#+begin_src python
from pathlib import Path
cssRatios = []
for css_min in Path("resources/style").glob("*.min.css"):
 css = css_min.with_suffix('').with_suffix('.css')
 cssRatios.append([css.name,
 "{:.0f}% minified ({:4.1f} KiB)".format( 100 *
 css_min.stat().st_size / css.stat().st_size,
 css_min.stat().st_size / 1000)])
return cssRatios
#+end_src

#+RESULTS:
| index.css | 76% minified ( 1.4 KiB) |
| org-demo.css | 77% minified ( 2.8 KiB) |
| errors.css | 74% minified ( 4.9 KiB) |
| org.css | 75% minified (10.7 KiB) |
```

Org Mode is a great solution if your team is familiar with Org Mode and Emacs. Even Github supports Org Mode, and you can use `*.org` files instead of `*.md` ones.

On the other hand, another problem arising from the separation of code and documentation is the weak cohesion between code and documentation parts. For example, we can describe a feature in our system, but every single part of the description is about different parts in our source files. This issue leads us to an inability to update certain parts of documentation after changing files connected to the source code or editing specific parts of those source files. Vice versa, while reading documentation, it's difficult to quickly find related source code for a certain paragraph of documentation. Without solving this issue, the complexity of documentation support will grow increasingly with the growth of project size.

But you may disagree and say, "That’s not true.Our API documentation doesn't have problems like that!" and you'll be right! You don't have such problems with API documentation or your Storybook documentation because it's generated from source code or with huge involvement of your source code in it. It has strong cohesion with source code and uses the same version control system as your source code. The only way to make writing project documentation easier, is to use the same set of tools as for code writing.

You can still solve this issue with tools like Scribble or Org Mode, but you'll need to combine different parts of documentation manually, which can be hard in big projects.

## Documentation as code

Keeping documentation and code together allows to achieve better control of changes and to make support of documentation easier. But without proper tools, it can be awkward to work with documentation for anybody other than the developers. For example, we can use markdown files for writing documentation, but if we place them near related source files, it will be difficult for managers, analysts, QAs, and designers to find something in this documentation. On the other hand, if we place them into a separate directory with its structure, we will not solve the issue with weak cohesion. In addition, with markdown files, we can't automatically create references from `*.md` files to particular parts of a source file, or we can't automatically combine all `*.md` files about the whole feature but written in the perspective of different source files. Let's look at the following example:

```bash
.
└── src
 ├── api
 │ ├── auth.js
 │ ├── news.js
 │ └── offers.js
 ├── components
 │ ├── auth.js
 │ ├── header.js
 │ ├── news.js
 │ └── offers.js
 ├── index.js
 └── reducers
 ├── auth.js
 ├── news.js
 └── offers.js
```

The example shows a simple project. Let's imagine we want to write documentation for our `auth` feature. The whole feature is implemented in three different files, but by "auth's implementation", all source files, not only `api/auth.js` or `components/auth.js`. So, to achieve strong cohesion between code and documentation, we should somehow place different parts of an article about authentication in different files and generate a single article from these parts.

If we do that, and even better, we add links to source code from a generated article, we can solve both problems with weak cohesion and using different versioning tools. But it'll still be a little awkward to use because good documentation should allow you to search through it and edit it.

## The solution

I tried finding something which could solve all of these problems, but unfortunately, I hadn't found it. So I wrote my own tool called [Fundoc](https://github.com/CSSSR/fundoc) to achieve all described goals and even more. The tool can:

- Keep documentation and source code as close as possible.
- Use the same version control system for documentation as for code.
- Be language agnostic.
- Collect all documentation from different repositories in one particular place.
- Allow non-programmers to read and write documentation.

So what can Fundoc do? It can generate documentation in two formats: raw markdown files (maybe later I'll add Org Mode support) and [mdBook](https://github.com/rust-lang/mdBook). The main idea behind this tool is to be as straightforward and uncomplicated to use as possible while providing all of the required functionality like search through documentation, documentation editing without the necessity to know the structure of a project, using one version control system, and so on.

<Img imageName='fundoc-example' alt='An example that shows how Fundoc generates documentation from different files' />

But what do I use to keep the simplicity of a tool and the possibility to work with it for non-programmers? I use Github, that's it. Of course, in the future, it's possible to extend support of different services like GitLab, Bitbucket, or something like that. Let me explain how it works. Developers write documentation in source files or in markdown files marking every single documentation part with a simple marker that describes a result article title such as:

```javascript
// src/api/auth.js

/**
* @Article Authentication
*
* To get authenticated, you should use the `login` function, which returns auth-token to pass it with API requests that require authentication.
*/
const login = (username, password) => {
 // some code here
}

/**
* @Article Authentication
* 
* To log out, use the `logout` method. It will invalidate the auth-token and delete it from cookies.
*/
const logout = () => {
 // some code here
}
```

And some description for a UI-part:

```javascript
// src/components/header.js

const Header = props => {
 const { isUserAuthorized } = props
 
 /**
 * @Article Authentication
 *
 * Only authorized users can see their balance in the header
 */
 return (
 <div>
 ...
 {isUserAuthorized && <UserBalance />}
 ...
 </div>
 )
}
```

This rather simple example will be compiled into one markdown file:

```markdown
# Authentication

To get authenticated, you should use the `login` function, which returns auth-token to pass it with API requests which require authentication. [[~]](https://github.com/username/repository/blob/master/src/api/auth.js#L3-L7)

To log out, use the `logout` method. It will invalidate the auth-token and delete it from cookies. [[~]](https://github.com/username/repository/blob/master/src/api/auth.js#L12-L16)

Only authorized users can see their balance in the header. [[~]](https://github.com/username/repository/blob/master/src/components/header.js#L6-L10)
```

> To see more realistic documentation examples you can check out [documentation of Fundoc itself](https://csssr.github.io/fundoc/) or [another project](https://github.com/CSSSR/linters) that used Fundoc.

In the compiled markdown file, you can see references to the particular parts of the source code. It allows you to find the exact source of every single part of the documentation. It can be useful for non-programmers if they want to edit documentation. If you believe they should still work with git to push their changes, they actually should not. Here's the example of editing documentation in the repository of Fundoc:

![Process of documentation editing](/images/dont-resize/en/problems-with-documentation-writing/fundoc-gif/all.gif)

So on the gif, we can see that the only thing we need to edit our documentation is GitHub itself. Yes, it still requires an understanding of what GitHub is and the fundamental terms like "commit" and "branch". As practice shows, QAs, managers, designers, and analysts can handle it without any problems. At the same time, this way of working with documentation doesn't require knowing the file structure of a project from non-developers. It's definitely much easier than working with CLI-tools and dramatically easier than trying to synchronize Confluence and source code.

At the end of the article, I wanted to remind you that Fundoc now is in the beta state, and some APIs can change in the future. Otherwise, it already solves many problems and is used in different projects, so you can try to use it as well. If you have any questions or suggestions, feel free to send me them via Github issues or PRs. I'll be glad to make it better with your help!

It's hard to find anyone who hasn't heard of Stonehenge, yet nobody can say for sure what was the original purpose pursued by the ancient people who built it. In fact, the scientists would be grateful for any text or graphical description from the builders of this monument.

Problems with documentation writing

---

**In** this digital era, a website comprising various UI/UX elements and features can reveal the ocean of opportunities and become even more effective and engaging. UI/UX components and technologies not only make a website lookgreat but also secure the brand’s marketing goals.

In recent years, we have witnessed a dramatic shift in website development. The innovative and futuristic technologies of augmented (AR) and virtual reality (VR) are transforming the internet and are capable of changing the way websites address users’ demands. Today, both technologies are considered as the most important trends in the IT sector, and with the help of desktops, tablets and smartphones have become more accessible, allowing millions of people to experience AR/VR applications across numerous business verticals. According to Goldman Sachs estimates, the AR/VR is projected to grow into a $95 billion market by 2025.

<Img imageName='profit-chart' alt='Profit chart' withBigMargin />

Many web developers have started creating plugins to put AR/VR into action and make them work for the web. Some alternatives where AR/VR can add value include:

Creation of exclusive web content. The fast-growing availability of open-source libraries makes it easier to create exclusive AR/VR-based content for the web even for novice developers.

The expanded content options. Leveraging both technologies opens up new prospects for businesses, such as providing virtual tours that can take users to places they might not be able to enjoy in real life.

Playing to consumers’ emotions. This one is becoming a popular marketing tool that drives users’ attention and encourages them to engage and cooperate with the product before they decide to purchase it.

We have made an overview of each technology use case, including why they are helpful in building high-end websites/apps with high-end experience.

<Separator type="bg-repeat" imageName="peopleWithDogBg"/>

## AR for the Web

AR adds digital elements to the surrounding reality, which means that users can see the physical world around with a smartphone or web camera, but they would also see additional fabricated images and elements layered over the real objects. Thus, AR builds a sort of bridge between users and virtual reality allowing them to take up activities based on their current location. Multiple web applications based on AR have stepped in due to the creation of compatible solutions (React-360 among them) that let web developers upload panoramic images and videos to their websites. With the increasing availability of AR, the technology will be broadly used in mobile UIs, as web development turns more and more towards mobile.

Advertising and digital marketing will benefit most from the augmented reality since AR provides boundless opportunities to showcase products and their advantages to users. Marketers can build a simulated web (or mobile) environment stimulating customers to experience the product themselves and thus drive greater engagement.

There’s a perfect example. In 2017, Wayfair (online furniture retailer) launched an application that included AR software that shows how furniture looks in a customer’s home. The app debuted as a featured app on ASUS ZenFone AR and used Tango (Google’s AR technology), to let consumers see and manipulate virtual furniture and décor at full scale.

<Img imageName='wayfair-app' alt='Wayfair app in action'/>

Speaking from the technology side, we should say, that since a lot of AR development now goes on the web, this is where JavaScript would reign. JavaScript provides a set of features that allow web developers either to create a new AR application or add an AR view to an existing one.

Google’s also bringing AR technology to its Chrome browser. An immersive WebXR Device API first came to Chrome 79, and, according to Google Chromium blog, now it supports augmented reality and will arrive in the upcoming stable version of Chrome 81 which is in beta testing at the moment. Google also added support for the WebXR Hit Test API, an API for placing digital objects in a physical real-world view.

<Img imageName='digital-flowers' alt='Digital flowers in a physical real-world view' withBigMargin />

## VR for the Web

Virtual reality is also pushing the web development industry further. Unlike AR, VR often requires special equipment (like a headset) and can deliver a complete experience of immersion that disconnects users from the physical world. More specifically, they are immersed in a totally fabricated world, interacting with this environment as they would in real life.

Web development gets the best from VR. 3D-style web design looks great and impressive, besides, customers will enjoy observing a product staying at home. Such engagement can have a major impact on customer’s behavior and decision.

Other VR capabilities providing benefits to the website include:

Building virtual showrooms to highlight specific features of the product.

The ability to try the product considerably reducing shopping time.

VR technology can also be mobile just like AR. Mobile VR (Google’s Cardboard as the simplest example) works by pairing a smartphone with a portable VR device to generate the VR experience.

<Img imageName='vr-gameplay' alt='Man cooking on VR kitchen'/>

The most commonly used framework for building VR websites today is WebVR, which is an industry-standard application programming interface based on JavaScript, providing support for virtual reality devices in a web browser. WebVR mainly uses React 360, Three.js and A-Frame as key technologies providing access to the best VR experiences.

Developers at Mozilla, Chrome are making efforts to provide support for WebVR. Currently, it works in Nightly builds of Firefox and experimental builds of Chrome. As soon as regular builds are released to the public, users will be able to access AR/VR content with no added steps required. Simultaneously, tech giants like Facebook, Microsoft, and others maintain investments in the development of VR technologies.

## The Future of AR/VR for web development

At present, both AR and VR are still challenging for web developers. Obviously, to take more advantage of AR/VR, in the short term, developers will need to have a better understanding of their user audience demands by making use of big data and analytics. However, ultimately, these two technologies are believed to revolutionize the web development industry. The demand for high-quality content will increase: users will need on-the-go high-end tools that can visualize possible purchase scenarios.

As AR/VR will get more advanced over the next few years, they will provide fully personalized, improved and more accessible user experiences. This will give marketers more real-time data based on user preference to dynamically customize marketing and advertising instruments and techniques including messaging, timing and placement.

Finally, there will be time and enough space for the new kind of devices to step in: probably, AR glasses may come as a reasonable alternative to the smartphone cameras. One can remember Google stop selling its Google Glass in 2015 after reports of privacy concerns, however, this particular form of AR can come back since the phenomenon is slowly beginning to assert itself as an invaluable asset to web designers.

Augmented & Virtual Reality to Shape the Future of Web Development

---

**F**irst and foremost, you should know that there’s no one right way to build a website. What you use in the end all depends on your needs and business demands. Sometimes a basic HTML site is all you need, other times you may need to develop a completely bespoke site to appeal to your customer base, while standard CMS sites allow you to make basic updates easily.

To help you decide which web development strategy is best for you, let’s look at the advantages and disadvantages of each.

<ParagraphWithImage imageName="html">
## HTML

Description: HTML sites are best for the most basic types of sites. Static in nature, they offer a quick and cheap way to build an online presence that you can use to market your company. Development skills for this type of website are relatively simple, meaning you can hire a relatively junior developer to maintain the site as you grow. However, HTML really only works for smaller sites, and isn’t an effective tool for e-commerce. To get an idea of how much it would cost to build a basic HTML site, you can use this quick calculation tool.

Pros: cheap, quick to build, low level programming skills to update

Cons: static website that requires programming skills to update, can’t be used for e-commerce, difficult to use for complex sites.

Who it’s best for: companies looking for a basic online presence with company description and contact details.
</ParagraphWithImage>

<ParagraphWithImage imageName="cms">
## Standard CMS

Description: A Content Management System (CMS) website is quite simple to set up. There are standard site layouts that you can purchase and you can buy a design to fill it in. You can hire a company to do this for you, but they’ll charge quite a high premium to develop them for you. However, CMS sites can be good for standard e-commerce sites, and it can be useful to hire a developer to help you with this. You should also remember that because most e-commerce sites have some custom elements, CMS is usually best for MVPs, while you’d have to hire a developer to build your final product from scratch.

Another key advantage to CMS sites is that once you’ve set them up, you can change content relatively simply, although if you want to make major changes, you’ll need a custom site. Standard CMS can also be useful for blogs, because the content can be so easily updated

Pros: some adaptable content with no developer, can build MVPs for e-commerce, cheaper than custom sites

Cons: more expensive than HTML, no customization, often need to build new site from scratch as company grows, mostly only suitable for MVPs

Who it’s best for: companies building MVPs to be rebuilt once bigger investment is secured, basic e-commerce, blogs
</ParagraphWithImage>

<ParagraphWithImage imageName="custom-development">
## Custom Development

Description: custom web development is the most useful way of building a website if you want to build a long-term business through an internet presence — basically everyone these days. For some businesses, like a local car dealership, this may be too much, because you sell most of your cars in person. However, if you want to make sales over the internet, you need at least a CMS website.

One of the advantages of developing a custom site as opposed to a basic CMS design is that there are no limitations based on the standard layout. You can build whatever elements you want to help increase your sales and build elements that give your company a real unique selling point. You can also update parts of your website, like a standard CMS site.

Another major benefit of building your own custom website is that they can be easily scaled. It’s important to note that how well the site can scale is largely dependent on the quality of the code. Standard CMS sites or low-quality code custom sites can get buggy and have delays as users increase. If you’re building a site to handle a large load of clients, it’s best to find a skilled team of developers to do it for you.

However, skilled developers can be quite expensive, which is difficult for some newer and smaller businesses to handle. If you’re just starting out and don’t have much funding, it might be expensive for you to build the site you want from the beginning, but it will save you time and money down the road.

Pros: completely customizable, scalable, can update content, better presentation of unique selling points,

Cons: can be pricey, requires experienced professional team, major updates more complex

Who it’s best for: established companies looking to build an online store, aggregators, startups looking to build an online company, news sites
</ParagraphWithImage>

<Separator type="color-line" lineColor="#D3D3FF" imageTitle="peopleWithBasket" imageName="peopleWithBasket"/>

## Conclusion

If you’re looking to build a new website, you have several options to choose from, and the one that’s right for you depends on many factors. As you grow your business, you may decide to change what you originally built. Choosing the right model to start with can save you time and money and help you grow faster.

HTML, CMS or Custom Development: Which is Better?

---

**T**hose days when you could seriously argue whether it’s a bad or a good idea to bring outsourcers in your business are gone. Now the question is different: how to choose an outsourcing team so as to get maximum benefit and minimum risks. 
First of all, you should consider from where exactly this team will be working.

If you classify outsourcing by location, you can distinguish three main types:

- A team works together with yours in the same office. All communications — face to face, external and internal developers participate in meetings and brainstorms together.
- A team works from its own office. Communication within the team takes place offline, and interaction with your team are done through regular meetings and the Internet.
- A team is fully distributed, all interaction is remote.

Each type has its own peculiarities. At a contractor’s search stage, your key task is to correctly define the terms of interaction with the future outsourced team and select the most suitable way of working so that these features become advantages.

If one collects opinions about working with outsourced teams from different companies, he or she can learn that sometimes the same initial conditions may result in the opposite outcomes. Some say that a fully distributed outsourced team shows a higher result than a team working from an office. Others recall their experience with remote developers as a complete failure, but note the increase in productivity after inviting the outsourcers to work in their office. The easiest way is to blame the professionalism of the outsourced team for everything. But in fact the truth is that the environment and conditions play a significant role in how effectively a team can work. Let us look into what those conditions are and how to take them into account when choosing a contractor.

<ParagraphWithImage imageName="skydiving-people">
## Team Goals
The correctly defined goals are 90% of success. Make your mind what you would like to achieve outsourcing some job from your in-house IT department: to speed up on-going development, to launch a new one, or to ease the pressure on the supporting team of an already operating product.

In any case, it is important to remember that it will take time for a new team to adapt to your processes and get familiar with the context. The more “legacy” there is in the tasks they will have to perform, the longer this period will be. In critical situations, it can be greatly reduced by placing the developers in the epicenter of events right in the office. This is especially true for a pre-release stage products or those at support, i.e. in all cases when information exchange between yours and the outsourced team should be as fast as possible. However, if you are only planning to launch development, this option may bring no benefits, as new information will be distributed as it generated, but the office costs will certainly increase.
</ParagraphWithImage>

<ParagraphWithImage imageName="skydiving-man">
## Special Teams
If you need a team of HTML developers to quickly launch a batch of typical landings, you can find suitable candidates almost anywhere in the world. But if you’re looking for developers with deep expertise by choosing a team to be located in the office, you limit your choice. Professional distributed teams are able to recruit the best specialists from all over the world, which means you can engage in your project, for example, five signor-developers within one team.
</ParagraphWithImage>

## Company Procedures

You would like the outsourced team to follow your internal procedures. The following shall be taken into consideration:

- Level of control. If your management keeps a strict record of all your employees’ activities, and this is critical for you, the most convenient option would be an outsourced team working in your office. Alternatively, desktop monitoring systems for employees can be considered, but such solutions are often expensive and greatly reduce motivation.
- Well-tuned, clear and structured processes. The clearer the mechanisms within your team work, the less risk of losing time, data and information when working with outsourcers. In small teams, where processes are not yet regulated, outsourcers working close to their office colleagues will be able to handle tasks more efficiently.
- Documentation. Although a project coverage with up-to-date and comprehensive documentation is the generally recognized best practice, reality is not ideal. If your project lacks well-functioning documentation support — the farther the developers are from the team, the more painful their work will be.
- Main communication channels. Take note how your employees communicate. Nowadays, many companies use messengers and video communication inside the office — it is quick, convenient, saves the history of communication, and does not knock out of the “stream” the developers deeply immersed in the problem. If this is your story, then the connection with a distributed team will go seamless. And vice versa, teams that meet three times a day in a meeting room will hardly work smoothly with remote developers or a team from another office.

These points are a “quick test” of your in-house IT department’s readiness for expansion through outsourcing. In order to get the full picture you need to analyze a lot more factors and we’re ready to help with that. Email us and we will give you free advice on all the particulars of connecting the outsourcing team to your development.

One argument against outsourcing often heard from CTOs or team leaders is that “our processes are not adapted to include outsiders at all”. Unfortunately, sometimes this is really true.

The good news is that including the team “inside” your processes is not always necessary. If it has to work on the whole project or the selected particular parts, so you can organize the work in the way that the teams are synchronized only at key points. Experienced professional outsourced teams do not need to be controlled at every stage.

There’s a security issue worths mentioned separately. We can assume that distributed teams definitely lose out when it comes to working on projects that require a high level of data access control. But in reality, it’s a question of experience and the right tools: we’ve been working with banks and companies dealing with cybersecurity for many years and have learned to adjust to almost any requirements.

<ParagraphWithImage imageName="laptop-work">
## Project Completion
Any project comes to an end at some point and at that point one have to decide what to do with the people who no longer have assignments. Having an outsourced team is like an insurance against the necessity to fire or transfer employees to other departments. The costs of “shutting down” distributed teams or those in own office are lower — one doesn’t have to think about abandoned workplaces, passes cancellation and empty spaces. This also applies to putting work on hold: for your in-house developers such standstill is often too much to bear and it is definitely expensive for you.
</ParagraphWithImage>

## Costs

Often the choice of outsourcing development is a choice in favor of economy. In this light, distributed teams look the most advantageous: it is cheaper to have them, and therefore the cost of hiring them is much lower. However, recruiting a team with its own office also creates a lower financial burden than your office outstaffing.

So, to sum it up.

<Table color='purple' withBorders>
 <thead>
 <tr>
 <th />
 <th>Your office outstaffing</th>
 <th>Outsource in its own office</th>
 <th>Distributed team</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <th colspan="4" data-text="Aim">Aim</th>
 </tr>
 <tr>
 <th>Emergency help to your project</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Development support or upgrades with new functions</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Launch of new development</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Specialists Qualification">Specialists Qualification</th>
 </tr>
 <tr>
 <th>Regular specialists</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Unique specialists</th>
 <td>--</td>
 <td>-</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Processes">Processes</th>
 </tr>
 <tr>
 <th>Firm control</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Strict processes</th>
 <td>+</td>
 <td>+</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Documentations</th>
 <td>+</td>
 <td>++</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Personal communication</th>
 <td>++</td>
 <td>+</td>
 <td>-</td>
 </tr>
 <tr>
 <th>Communication via messengers</th>
 <td>+</td>
 <td>+</td>
 <td>++</td>
 </tr>
 <tr>
 <th>Security concerns</th>
 <td>+</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th colspan="4" data-text="Miscellaneous">Miscellaneous</th>
 </tr>
 <tr>
 <th>Project completion</th>
 <td>-</td>
 <td>+</td>
 <td>+</td>
 </tr>
 <tr>
 <th>Low cost</th>
 <td>--</td>
 <td>-</td>
 <td>++</td>
 </tr>
 </tbody>
</Table>

There are no one-size-fits-all solutions, but proper planning and risk assessment at the start of cooperation will help avoid many mistakes. Be honest with yourself and the team your hired — this will make your outsourcing experience the most productive.

Blog | CSSSR

Problems with documentation writing

HTML, CMS or Custom Development: Which is Better?

How Close Your Outsourced Team Should Be Located? Pros and Cons

Comparison of Type Systems in Front-end Languages: Algebraic data types

The Manifest names CSSSR as Russia’s Most Recommended E-commerce Developer

Comparison of Type Systems in Front-end Languages

Problems with documentation writing

Augmented & Virtual Reality to Shape the Future of Web Development

HTML, CMS or Custom Development: Which is Better?