An ecosystem for designing business value in your core domain.


Computools designs ecosystems that allow for building scalable and productive user-centered digital products.


Selecting approaches and a key development stack based on analytics. First of all, ready-made solutions are taken into account, both those available on the market and those in, in-house development. These allow Computools to develop in the best way, reduce the chance of error emerging, improve the quality of product requirements and the product itself, and obtain a basic coverage of non-functional and transitive requirements. In this case, the cost of ready-made solutions play an important role.

A. Selection of basic architectural patterns and tools:

  • monolithic application or micro service architecture
  • vertical and horizontal scaling schemes that impose a number of requirements for further development
  • basic patterns of module writing
  • physical and logical placing schemes for key modules
  • critical external integrations
  • critical caches and queues, types of used data stores, such as relational or document-oriented databases

At this stage, no final decisions are made since these aspects can be updated during the whole architecture forming stage.

B. Forming an application stack taking into account:

  • restrictions and ready-made solutions support
  • reliability of solutions based on vendor support and future expansion of platform capabilities
  • the speed with which the solution’s vendor closes security issues
  • cases of using open source solutions without vendor support issues. (Though, there are additional risks in that, they can be solved by Computools’ team).
  • threshold of entry and prevalence of the solution. Often it also influences the average cost of development.
  • the cost of the necessary infrastructure, which includes hosting and VPC prices, additional licence costs, etc
  • development speed and quality while using this stack
  • count of tools for development and debugging

C. Forming work processes with Version Control System (VCS, git by default), Continuous Integration (CI, jenkins by default), necessary tests and workflow. Usually by the minimal adapting of ready templates.

D. Forming the process and set of utilities for the continuous delivery (CD, the default it is Docker and Kubernetes). Usually by adapting the ready templates for a particular case.

E. Forming the main development guidelines.

F. Forming and detailing high-level components.


A. Development of detailed specification that covers all user stories. Specification sections can be grouped by specific scenarios depending on the industry and application type. The functional is described in detail but not redundantly; acceptance criteria and the restrictions imposed on them. Such as speed security and further are specified.

  • forming backlog from the raw user story/cases. Stories can be detailed as part of the initial specification, but final detailing develops as a part of sprint planning.
  • a fully described story contains:
  • a detailed description functional requirements non-functional requirements acceptance criteria a breakdown into task - describing, which needs to be done to implement the task with decomposition by type of work.
  • additional
  • an activity diagram from the BA perspective a process diagram from the BA perspective
  • the specification is being finalized during the entire project life cycle

B. Development of a prototype in parallel with specification.

C. Forming Definition of Done.


A. Forming the development process in accordance with the identified requirements and interests of stakeholders. The main frameworks are:

  • Scrum is used for the active development phase of medium and large projects, or small projects from where the client does not have clear 100% insight into. It is also used during the final phases of broad functionalities in ready-made projects
  • Kanban is used during the support and optimization phase of an already developed project
  • Waterfall is used for small projects (up to 2-3 months) or blocks of functionality in ready-made projects with 100% vision from the client and the team

B. Calculating the number of project teams in case a project needs more than 20 project participants.

C. Forming process configuration.

  • Discussing the necessary roles of the project participants. The list of roles and their main responsibilities are:
Product Owner
- forming of the high-level goals and objectives, providing the budget, management of project size and time, approving the task scope. This role is often performed on the client side.
Project Manager
- forming and control of the process, control of agreements, management of the budget provided by a Product Owner, team coordination, reporting to and supporting of the Product Owner, solving organizational issues and risk management.
Business Analytic
- detailing of the goals provided by the Product Owner, development of the requirements, project analysis, analysis of competitors' technical solutions, consult the Product Owner, development of project documentation, management of the project scope, is required to give explanations to the team.
System Architect
- development of system architecture, high-level decomposition, stack choice, ready-made solutions and basic tool choice, analysis of the system’s technical component, technical risk management, technical consulting for the Product Owner, Business Analyst and Team Lead.
UX Designer
- development of project user experience, user experience analysis, prototyping, arrangement of UX test plans, development of basic UI requirements.
UI Designer
- development of project design, development of style guide, development of the UI toolkit, page wireframe detailing, development of animations and adaptive views.
Team lead
- configuration of development processes, coordination of the development team, technical decomposition, task distribution, code review, solving of complex and difficult situations during development and development of key system modules.
Software Engineer
- estimation and implementation of development tasks, that includes; the writing of Unit and integration tests and working with documentation.
- configuration of used tools, configuration of all environment types (includes production), creation of CI and CD processes, support testing process (includes auto tests), platform work control and monitoring and configuration of third-party systems.
QA lead
- testing process configuration, verification of build quality before uploading to demo or production environments, testing plan development, QA team coordination, detection of bugs in design and specification, development of key testing documentation types, system security testing.
- manual testing, feature aspect testing, regression testing, system security testing, load testing, bug reports, development of test cases and checklists, improvement suggestions.
Auto QA
- auto, e2e, api and load test estimations and implementation.

D. Forming of work format:

  • Points of getting approvals from the client’s team.
  • The client's role in processes (it's usually the Product Owner) - The client is considered as a team member and a process participant by the team.
  • Product Owner involvement into meetings:
    a. intro meeting (optional) b. daily meeting (optional) c. meeting with Business Analyst d. planning - if the client cannot attend the meeting, the project manager agrees upon the scope e. retrospective (optional) f. demo
  • Reporting points. The more the Product Owner is involved in the project, there will be fewer mistakes caused by inconsistency. Written reports are given every day by default and meetings with the project manager are set up whenever it's possible.
  • Work format synchronisation with Business Analyst.
  • Demo formats and time synchronisation with Product Owner.
  • Configuration of the list and volume of necessary internal meetings.
  • Definition of Done' creation.

E. Configuration the technological processes and interactions between roles. It is based on the company's overall process which is optimized for the current project while taking into account the requirements of team size.

  • Configuration of work result handover format internally within the team:
    a. task flow b. task description c. bug reports d. design handover e. API docs formats f. etc
  • Developers' testing processes:
    a. unit tests planned coverage b. integration tests
  • Git flow - by default feature branch:
    a. branch flow - naming, releases etc. b. automation of code analysis c. code review d. pull request
  • QA flow - includes testing from the designer:
    a. smoke testing b. aspect testing c. designer review d. regression testing: manual autotest e. release candidate testing: manual autotest
  • CI/CD - deploys flow.



Access to expertise and Computools own key niche solutions provides saving time.


Computools LLC innovation management performance was valued by world experts in IMP³rove Academy.

ISO 9001:2015

Computools processes is certified according to international standards and has been refined by years of experience.

A Wide Range of Technology Stack

Computools’ multi technology experience allows select optimal technology for product development.


Computools values openness and transparency in all business processes thus you will always know what stage the development is.


Computools builds long-term relationships. This value forms the foundation of the company.


Main priority of the project team is your business goals, unique differentiators and challenges.


Low staff turnover by to geography and leadership in the region.


Let's talk about your project.
Use the form to drop us an e-mail.

Thank you for your message! Your request will be carefully researched by our experts. We will get in touch with you within one business day.