Any questions?

Discovery phase

A few short words about the purpose of this phase

In this phase we work closely with the client to develop the project documentation (PRD)

A lot of clients come to us with only an idea for their project and ask us to give them estimates. Some clients have a general idea and description of their business needs. Very few already have more detailed requirements and some of the following: general and detailed descriptions of the project, its business logic and features, wireframes, workflows (i.e. UML diagrams), technical requirements, etc.

No matter what you’re planning to build, be it an innovative startup idea or a new functionality of your existing business process, our job is to research and find out what the best possible solution would be. At this time you’re the only person who has any idea of how your product should look like, how it should work and what your customers/users should get in the end. To be able to tell you what it really takes to meet your requirements and expectations, we both need to precisely understand the amount of work involved. The proven method is to achieve this through developing project documentation.

Project documentation (PRD) is first and foremost, your assurance of getting a quality product within the allotted time frame. It’s a detailed description of what you and your users will gain as a result, which takes into account all the technical details. Project documentation is a way to provide you with transparency in what we do, so you don’t have a feeling of being trapped in a “black box” while working with us.

The main thing is to be with the
client on one page. Only in this way
do expectations will coincide with
the result
What will be done exactly

Development of project documentation is a tedious process that requires a lot of attention. We go through this process with you, ask a lot of questions about every possible detail and document everything we discuss. As a result, we get a project documentation that includes the following:

1Created with Sketch. Project structure

  • Structure of the UI for of each and every page, popup and alert, all possible user actions and reaction of the UI on these actions, displayed content and content moderation.
  • Admin panel and descriptions of all CRUD (create, read, update, delete) operations, nomenclatures, payment documents, roles, user parameters, etc.
  • List of all possible notifications, i.e. sms, email, push-notifications.

2Created with Sketch. List of all main features, external services and APIs that will be used

For example, if you need your application to send emails, we need to know what kind of service we’ll be using for this. Do you know already if it will be MailChimp, Mandrill, SparkPost or maybe something else? Possibly you want your users to confirm their phone number, then we should know how this will be done. Via SMS or IVR call or both? If you want to allow your users to upload and share images, we need to think which service we’ll use to optimize them. There are so many more details that need to be discussed and evaluated.

3Created with Sketch. Business logic

Often this logic is not something you can see in the UI or admin panel. This is an engine that will drive your application and thus is crucial for understanding and agreeing on how certain things should function. If you’re building a Multi-Vendor Marketplace, we need to understand how the distribution of funds between a website owner and seller works, taking into account specifics of the payment system, logic of refunds, reserves and balances. If needed, we’ll build the WorkFlows (UML diagrams, use case diagrams, time charts, etc.)

4Created with Sketch. Detailed wireframes

Wireframes visualize your project structure. If your application needs to be responsive, we’ll create wireframes for both mobile and desktop versions. We’ll also take into account all technical aspects, such as the specifics of the chosen frontend framework and UX.

5Created with Sketch. Technologies

Once we have all of the above information, we’ll decide which technologies would be most suited for your business needs.

Only when we both see that the document is complete and you’ve approved it can we tell you the fixed price based on the developed project documentation.


In the event you’d like to be able to change things on the fly, project documentation is not the correct approach. It cannot be developed, and we cannot tell you the fixed price nor time frame as the amount of work cannot be accurately estimated.

No problem and no worries! We’re flexible and ready to act as a dedicated team, and make as many changes as you need. We’ll work on an hourly basis and you’ll be invoiced weekly for the amount of time we spend on your project.