We set the price by multiplying the hourly rate on the number of hours we spent on the project. We state the number of hours in our weekly reports. A client can plan the budget by the following canvas: there are 5 working days in a week, so 5 days with 8 work hours in each would make 40 hours per week.

We base our work on the principles that our employees live by. The main principles are:

1. Responsibility -- that’s not a punishment (like a fee) or a self-punishment (negative emotions, for example). Responsibility means actions, something that will be happening at some point of time.
2. Collaboration means setting adequate expectations. If a person does not say something or prefers to keep quiet, that’s not collaboration.
3. Trust is the backbone of everything we do. The lack of trust results in too much energy spent on something else rather than on the actual task. But we stand for completing the tasks. No trust means there is no reason to work together.
4. Any work has to be paid for. Both sides are free to choose whether they want to continue collaboration or no.

So how exactly do you share the responsibility for a new product between the client and the team?

We are deeply convinced that any deviation in sharing the responsibility for the project will eventually lead to the problems. SO we came up with a set of certain rules that help us avoid this issue:

1. We don’t work by a fixed price model (here is why), but prefer to monitor the budget. Here is how it works:
   1. In the beginning, we outline the project goal and the expected results. As well we negotiate the Full Flow.
   2. Plan and perform either a 1-week or 2-week sprints. We insist that the client is present at our weekly demos or reads our Visual Changelogs.
   3. As soon as we come up with the 50%, 75%, 90% and 100% of the budget, we re-estimate the rest of the work (or backlog) and, together with the client, prioritize the tasks for the rest of the budget.
   4. Such an approach allows us to meet both the project requirements and the budget but, at the same time, we can always implement certain changes or eliminate certain project parts.
2. We request a client to have a specialist who can reply to our queries within 1 day and can independently make decisions about the project.
3. Guarantees. What kind of guarantees can we give? We can guarantee that our engineers will dedicate a stated number of hours to the project. But we cannot guarantee that the final product will 100% match your expectations (though we’d love to).
4. It’s highly recommended that the client also has certain responsibilities related to the product. It can be a product exhibition, a meeting with top executives, the release date -- anything that can serve as a deadline and help understand the goal of the project.

Full Flow implies the whole process of using the app by the user, from beginning to the end, reaching the final goal.It can be extremely easy - like registering and sending a query - or complex. For example, an HR app can include a few user roles and a variety of corresponding processes: a recruiter registers a company and creates a job opening, a candidate responds to the opening, a recruiter sees the response and reacts.

This is a document of a presentation and it contains detailed description of the changes that we implemented in a week. Visual Changelog is our own innovation that we came up with in order for the client to better understand the workflow and all the processes.

This report states the number of hours spent on the project and the spent budget.

At the project beginning, after we negotiated on all work terms and signed the contract, we request the client to pay a deposit due for 2 working weeks.

After that, we invoice the client every two weeks with NET15 paying conditions.

These conditions can be changed upon the request.

The team composition depends on the project requirements and is always negotiated with the client.

The team usually has:

1. Developes(2 and more)
2. Project manager
3. Quality assurance

Depending on the project, we can also add the following people to a team:

1. UI designer
2. Video operator
3. Marketing specialist
4. Maths specialists
5. Other specialists depending on the project needs

The software engineers tend to be rather expensive guys who have difficulties with immediate switching between the different tasks. In order for the project to go in the right direction, meet the budget, regularly hold the meetings and create a Visual Changelog, we need a manager. By having a manager on a team, we basically decrease the project spendings in times so we firmly believe that a manager is a must-have for any project, even the smallest one.

There are many technologies for preparing the estimation of a software product. These technologies differ by the labour inputs balance for estimation preparation and its accuracy.

Here are the main factors we consider when performing an estimation:

1. Ready and approved (A) technical task is not perceived as something permanent. Moreover, we firmly believe that everything will change at least once during the work process;
2. If some parts of the project are not under our responsibility then the risks grow significantly. In such cases we are not ready to take responsibility for the end result;
3. The minimal amount of time for the development of any MVP is 6 weeks. We never got less than that during 4 years of our work;
4. The temporary spendings on management make up at least 30% from the development cost. Any smaller percentages increase the risks;
5. Estimation is not a promise nor a guarantee. It has only one goal which is to inform the client about the project.
6. The main method of estimation that we use is the decomposing of tasks till the depth of 8 hours. That means, we decompose the tasks in such a way that the biggest task takes 8 hours. After decomposing, we compare the project with the available estimations and real working hours and make any adjustments, if needed. The main advantage of such an approach is that everything is done fast and in an efficient manner. As for the disadvantages, it’s not very precise. We sacrifice precision for speed, as mentioned above;

This is what the project cost consists of:

1. ALL temporary spendings of the project team members, such as time for the development, testing, work with documentation, writing tests, debugging, negotiation on design, holding meetings, etc.
2. Spendings that are specific for the project -- specific calculations, video cameras, programmed robots and so on.
3. Spendings on project infrastructure -- specialized software, Hosting for landscape, licencies for digital products, various sorts of insurances, etc.

The basic spendings include the code hosting, work stations, monitors,development environments.

Estimation is our forecast that we base on the existing experience, information and client’s expectations.

But during the work process, all of these components tend to change.

We cannot see the future, therefore, we cannot 100% estimate how long a certain project will take.

We can increase the forecast accuracy but that would mean additional spendings on collecting the data for the forecast and such spendings do not usually make much sense. The main rule is: no estimation is a 100% rule to follow, neither it is a guarantee for a certain number of working hours.

When making technical decisions, we go by speed and cost of development. That means:

1. We prefer to integrate/adapt the existing solutions instead of creating one from scratch.
   1. We actively use and reuse the templates,
   2. We eliminate frequent mechanical operations like server administration (by using cloud instead,
   3. We actively use containers to combine the solutions with different tech stacks and not be limited in one solution only,
2. We research the time and cost for integrating each solution and consider this experience when making new technical decisions in the future
3. Decrease the support cost by
   1. Using serverless, docker, immutable server concept
   2. Using functional approach for software development (even for non-functional languages)
4. Actively use readymade solutions.

Before getting down to writing code, we do a bit of groundwork that includes:

1. Preparing the initial documentation
2. Preparing the initial infrastructure

The initial documentation includes:

1. Description of a project (in words)
2. The entity diagram — ER UML diagram
3. Project vocabulary — verbal definition of the entity and its examples.
4. Project roadmap — budget, goals, deadlines
5. Wireframes — mockups for the app.

The client must review and sign all the documents. Without them, we won’t start our work on the project.

The preparation of initial infrastructure includes:

1. 2 landscapes— test and production
2. Source code repositories
3. Computational project infrastructure (cloud accounts, etc.)