We develop correctly.
We develop alienably

If a client wants to cancel payment for any type of work, we certainly allow them to do so without complicated explanations. This is feedback for the quality of our work and customer satisfaction.

The client may ask for a refund even for work under already signed acts within 50 calendar days. We understand that some persons sign acts and others accept works. Moreover, even serious problems can be identified after the signed acts.

We keep the client's secrets and don`t hunt his employees. That's why we regularly sign NDAs with all our employees.

We require our clients not to hunt down our employees under any explanations, because this creates a bad precedent and forces us not to put the best people on the project.

We are trying to understand the client's true request and are not afraid to ask “5 why” questions, we do not accept answers for the sake of answers, and we do not encourage the “do as asked” strategy — we know that in custom development this leads to architectural problems that are difficult to fix.

Schemes should not contain terms that are unclear to business. To understand each other, you need to speak the same language.

First we design, then we do it.

We design software in a language that businesses understand to make the perfect naming.

The designed value is explained to at least one more experienced person before implementation (by standards — to a technical lead or an architect).

If we did a bad thing, we'll redo it for free, even if it works as intended.

We are committed to the KISS (Keep it Short and Simple) principle. The solutions must be elegant and beautiful. The criteria for ugly things are complex, unclear, and nonlinearly.

Simple is not easy. So if we see an ugly solution, we think about it until we find an elegant way to solve the problem.

We make software in business processes that ensure the simplicity of services and the ease of explaining their essence.

Creativity where there is no solution template, discipline in execution where there is one.

Focus on increasing the number of standard and already designed solutions, rather than on exclusive solutions.

If you don't agree with the standard, suggest changes. The changes should apply to the entire company.

As long as the standard is not changed, it is relevant. None of the typical patterns (standards) can be ignored.