datarockets founders, Pavel and Dmitry, worked for leading outsourcing companies in the industry before they started their own company that develops web and mobile applications of any complexity. They observed the ecosystems that lacked transparency, were indifferent towards the success of clients’ projects, and there was a certain unwillingness to invest in the personal growth of the engineering teams. This compelled them to build a place for like-minded people where they can integrate with clients as a single team, based on a transparent development process.

To further understand datarockets’ vision, GoodFirms has interviewed datarockets CEO, Pavel as part of their interview series. The following information is an extract from that conversation.

Introduce your company and give a brief about your role within the company

datarockets is an experienced team of product developers with offices in Toronto, Canada, and Minsk, Belarus.

We know how to build successful web & mobile applications and do our best to share that experience with our clients. I believe we have a very special approach when building relationships with our customers, which results in productive partnerships that last for years.

At datarockets, we use Holacracy to distribute roles between people, so my roles are constantly evolving. In short, I have the pleasure to:

• Define the future of the company by researching new business opportunities
• Give product strategy advice to our customers
• Share our knowledge writing articles about startups and product development

What was the idea behind starting this organization?

The idea behind starting datarockets was to create an intellectual hub where engineers come to learn product development skills from one hand, and clients come to create products for their businesses and startups from another hand.
Together with Dmitry Zhlobo (the CTO and co-founder at datarockets), we had been working for leading outsourcing companies in the industry and seen their processes from the inside. We didn’t like many things, such as:

• the lack of transparency. Typical outsourcing companies were trying to “build a fence” between their developers and clients with the help of project managers.
• indifferent attitude towards the success of their projects. Our managers were more concerned about clients paying their bills rather than our ideas on how to improve things around.
• unwillingness to invest in the personal growth of their engineering teams. We were working in a typical corporate culture embracing overtimes and trying to squeeze as much as possible from their employees.

We couldn’t find a place for ourselves, and that’s why we started datarockets. We were lucky to find 25 more like-minded individuals who joined our team and now:

• We integrate closely with our clients and work with them as a single team using an extremely transparent development process
• We communicate a lot and share our ideas on how to make things faster/better.
• Our company organizes tech conferences across Europe, and our engineers perform there as speakers.

What is your company’s business model–in house team or third party vendors/ outsourcing?

Our business model is called “Dedicated Team”. We don’t outsource and prefer to rely on our own resources.
Working as dedicated teams means a close integration into our clients’ businesses and their teams. We bring our communication and development processes, automate routine work, and exchange best practices. This way, we create a productive environment where we grow together with our customers.

How is your business model beneficial from a value addition perspective to the clients compared to other companies’ models?

Apart from actual coding, we bring our ideas to the table. Writing high-quality code is what we do by default, but there are many good engineers out there, and we go the extra mile to stand out. We contribute to our projects by sharing our culture, bringing our processes, and providing our ideas on how to make things faster/better.

Our major strength is transparency and simplicity. datarockets’ clients don’t worry about the technical part of their products anymore – we handle that. We set up clear work and communication processes, so our clients can see what we discuss, how we make decisions, and what issues we experience in real-time. Our team lets our customers focus on what really matters to them: overall product strategy, finances, and marketing.

We try to automate as much routine work as possible. Our engineers don’t really enjoy the work that can be done by robots/scripts, and that always turns out to be very beneficial for our customers.

What industries do you generally cater to? Are your customers repetitive?

We don’t stick to a specific industry. Our team consists of people who are fond of complex architectures, like to resolve complex problems and create something really useful. We never stop learning. The best way to use all this knowledge and learn more is to take different kinds of projects.

For the last 6 years, we have been building products for the following industries:

• FinTech
• Ride Sharing
• Entertainment
• Social Media
• Social Network
• Real Estate
• Human Resources
• SaaS
• Marketing
• Healthcare
• IoT

Almost all of our clients come back to us with new projects and refer their business partners/friends to us.

Mention the objectives or the parameters critical in determining the time frame of developing software and applications.

To provide as accurate as possible estimate, we need to know as much as possible. Usually, before we give an estimate, we try to determine:

1. Functional business requirements. What kind of features we need to build and how they help the users.
2. Technical business requirements. For example, if we need Internet Explorer browser support, it can add some extra work.
3. Product strategy. Before taking on a project, we need to believe in the idea behind it as well as its strategy. We need to know why exactly we build a certain feature to share our insights and suggest improvements.
4. Marketing strategy. Nowadays, marketing matters even more than development, and we need to ensure that our prospective clients are aware of that. We need to know their marketing strategy to suggest our own ideas and share relevant experience.
5. Budget. Depending on the budget, we can offer alternative technology stack or suggest our vision on the scope of work/priorities.
6. Legacy Code. If a project is not from scratch, we need to perform an initial code review to assess its current state and provide estimates based on what has been done already.

How much effort in terms of time goes into developing the front end and back end of a web application?

It really depends. In our portfolio, we have some API-only projects that didn’t involve any frontend and at the same time, some frontend-only projects without any backend.
Our estimation process is collaborative and transparent. Our prospective clients see how much time we plan to spend on each feature/change and free to share their questions/concerns during the process.

What are the key parameters to be considered before selecting the right framework for developing software?

1. Common use cases. Every framework/technology is aimed to resolve a particular class of tasks, and you need to be aware of that. For example, it’s possible to develop a simple website & blog with C++, but with Wordpress, it’s gonna be 1000 times faster.
2. Technical limitations. Each framework has its own limits and they need to match your technical business requirements. Otherwise, at some point, you will need to switch to another framework, which can be extremely expensive.
3. Flexibility. At some point, you may need to make a strategic pivot and be sure your current framework can handle that.
4. Ecosystem. When using a popular framework with a highly developed ecosystem, you almost always can find an open source library that does exactly what you need. For example, the Ruby ecosystem has thousands of open-source libraries that you can plug & play. That significantly cuts down the total cost and timeline.
5. License. Not every framework is free, and some of them are authorized to be used in certain conditions.
6. Community. Your development team should be able to find the necessary information fairly easy. Moreover, there should be a community behind the framework which is able to answer questions, fix bugs, and patch security breaches as they get discovered.

Which languages & frameworks do you prefer to use in development of web and mobile applications?

For the backend we prefer to use:

• Ruby / Rails
• Javascript / Node.js

For the frontend, it’s usually JavaScript:

• React.js
• Vue.js.

Talking about mobile apps, we use:

• React Native
• Kotlin/Java
• Swift

There are 2 reasons why we use these technologies:

1. They fit our needs the best. The technologies listed above give enough flexibility and at the same time, speed up web/mobile app development.
2. Our team has the most experience with them and enjoy using those languages/frameworks.

What kind of payment structure do you follow to bill your clients?

We bill for our time only. When a project needs to be done in a certain budget and time, we usually apply the FFF approach (Fixed Price, Fixed Time, Flexible Scope). What we do in this case:

• Break down the scope of work into User Stories and sort them based on their priorities
• Work on the User Stories iteratively based on their priority.
• Release new functionality as soon as it’s ready, sometimes we make multiple releases per week.

This way, at any time, we have a working version of the product. When we get closer to the deadline, we can stop and skip some minor features, but deliver the most crucial functionality under the budget.

We don’t like fixing the overall project/milestone cost for the following reasons:

• Providing estimates on fixed price projects development teams have to lie. If they provide positive estimates – their companies inevitably lose money. If negative – they kind of lie to their clients.
• After a fixed price project is signed, the client has no flexibility as the scope of work is fixed for that price. Requesting even a minor feature turns into the bureaucracy hell when project managers need to re-assess the scope of work, get updated estimates from the team, and re-sign the budget agreement. We strongly believe that it’s a waste of everyone’s time.
• There is not enough freedom for teams working on fixed price projects. Engineers don’t have time to suggest their ideas, improve processes, and automate routine work. Such atmosphere embraces poor productivity, low-quality code, and reluctant attitude to the project in general.

Do you take in projects which meet your basic budget requirement? If yes, what is the minimum requirement?

In practice, the minimum budget we can work with is $20k. The reason is that we don’t build simple websites that can be done with CMS like Wordpress, we take on the projects that require custom solutions. Having a budget less than $20k is pretty challenging to kick off something like that, even an MVP.

What is the price range (min and max) of the projects that you catered to in 2018?

$30k - $220k
I have to note here that we always build long-term relationships with our clients. The medium project duration with us is approximately 12 months. Our clients work with us for years; for some of them, we become their exclusive software development partners.

datarockets’ product vision, transparency with clients, and strong development culture have resulted in a high place amongst the top software development companies in Canada and Belarus.