Make a Request

The way we work

From a lead to the product launch

In this article, we will describe in detail all the stages of project work and answer the most frequently asked questions from customers.

Approximate preliminary estimate

After the request to calculate the project cost, our manager gets in touch within 24 hours to clarify the details. It is at this stage when we start collecting business requirements. If necessary, we offer a phonecall at your convenience. The more details we have, the more accurate the estimate is. Our first quote usually provides an approximate price and timing – from… to…

Why do we ask to give details on the budget and expected project deadlines?

We often ask clients to specify budget and time limits. We do this not to bill you as much as possible, but to suggest more budget-friendly options for architectural solutions, to exclude some features (to create an MVP), or to realize that you and we are a good match.

Why is the preliminary estimate different from the final one?

There are several ways to estimate projects. At the preliminary stage, we often use expert judgement. In this case, we sometimes do not know all the functionality details, necessary integration with the database, API, etc. It happens that in the process of further discussion, the customer wants more features, which may result in a change of the architectural solution and its complication .

Quote example

Budget approval and the estimate

When we are sure that the estimate meets the client’s budget and timeline, we work at the calculations. The project manager gathers all the software requirements, now diving even deeper into the customer’s business processes, conducting several interviews with the client, his employees, the target audience. The result of the manager’s research work is registered in user-stories, project requirements specification, sketches. All these are also approved by the customer.

User-stories example

Then a team comes together to discuss and think through the architectural solution and the final estimate. We make a three-point estimate: optimistic, pessimistic and realistic.

The optimistic estimate is the number of hours required for development and implementation, assuming everything goes well, e.g. the database API is well-documented and can be easily used in the project. A pessimistic estimate is for the situation if everything goes wrong, e.g., the API is under- or un-documented in some places. A realistic estimate is the most realistic estimate, the developer’s opinion with the most likely risks taken into account.

It is in the accuracy of a realistic estimate the developer and project manager demonstrate their expertise: how they find out what the team’s main concerns are and how sensibly they assess the situation based on their own and the team’s experience. Then, based on the three-point estimate and the risk register, the project manager makes an estimate and gives to the customer.

Contract, architecture and design

Once the estimate is approved, we conclude a contract for development. Usually, we work with a 30% prepayment of the project cost. The project work always starts with design development and approval. If the project is extensive, we can enter into a design agreement and prepare a development estimate after the approval/acceptance of the final design.


Example of a hierarchical structure of the project works (it helps to break down the project into component parts)

Project handover, bug fixing and support

People often ask us why the testing item in the estimate is so expensive. We’ll explain. Testing is to be done throughout the whole project, starting from the first weeks, because the sooner the bug is identified and fixed, the cheaper it is to fix it.

Why can’t developers code without bugs? Aren’t they skilled enough?
– Any code always needs to be tested under a lot of different conditions. For instance, when a new feature is added, a previously implemented feature may not work as intended. To do this, the QA engineer constantly checks many different usage scenarios for each functional block. Yes, the developer could do it himself, but then who would do the new features in the meantime? Besides, their time is more expensive than that of a QA-engineer.

We practice manual testing and auto-tests writing for large long-term projects. Before the project handover, regression testing is performed – testing of the whole project from the very beginning.

Some bugs may be detected only by a large number of users, so that users or customers may sometimes detect some defects after the product launch. That is why we provide 1 month of free technical support for development. In addition, we offer paid extended support services, where we monitor the performance and operability of the product, prevent incidents related to the product operation and restore it in case of system failure.

We constantly monitor and improve the quality of our managers and teams to make the development process as transparent and clear as possible for the customer and comfortable for the team. Our openness is appreciated by our clients.