altRecipe blog articles

Essential Things to Consider Before Starting Your App Development Project

We had a fruitful talk with our marketing director and co-founder, Herman Tiutiunyk, about the workflow, communication between client and company, and the development process from creating a technical task to project approval. Let's dive into his useful advice for anybody who is thinking about a development project!


How often do we receive inquiries without a clear technical task?

Inquiries without exact technical specifications happen quite frequently. In most cases, the client assumes that a set of screenshots they pull from the internet and a text description of a workflow that requires simplification is already a technical task and is enough to start engineering. For example, employees came to the workplace with 12 tools to work with, and reports need to be collected from each tool. And from a client's standpoint, the technical specification is to consolidate all those processes into one place.

Usually, there is no clear statement of work. Most clients come to us with a formalized description of the idea or with some kind of references with abstractions of what they want to receive.
Does altRecipe develop applications and software if a potential client has only an idea and a budget?

In about half of the cases, this happens. People come to us with an idea or a problem, which practically means the same thing to us. We examine the problem and develop an idea: how to solve the problem or neutralize or minimize the damage it causes. There are two paths in such cases.

First, together with the designer and business analyst or project manager, the client develops an accurate model of the desired result. For example, an online store, but with a distinctive feature. The client does not fully understand how this distinctive feature will work in the end. Therefore, everything leads to a common denominator through collaborative strategic sessions, and the idea is formalized. Then, based on the concept, several iterations of the technical specification are created, everything is visualized, when the client approves the option, development begins.

The second option means the idea is related to an already existing business. In this case, we are talking about process automation or internal optimization. We are often dealing with integrations: a business uses 10 services, but each service exists separately. The task is to bring data together, use data from three different services, send it to the fifth, etc. In such cases, the client initially orders and pays to develop a detailed technical specification, which describes the procedural maps (how this thing will work), technical task, and the project’s functional task.

Usually, we create basic technical tasks for free because it solves two problems at once. The first problem is that the client has already received something from us with a real value. The second is that it allows us to speak the same language. Suppose cooperation is not formalized, and data is not recorded on paper. In that case, the problem of discrepancies in the interpretation of the same sentences, words, and functions in the project will arise regularly.

Most often, idea-based projects are paid in stages. The concept can change greatly in the process, even if the client perceives that all the needs are solid and formalized. Accordingly, there is a specific big idea that is broken down into stages. Towards the end of the first stage, we begin to agree on the consequent. The client then has the results of the first and second stages, we can plan the third, fourth, etc. It could turn out that a project that was born from a small site grows into a large product ecosystem, which brings profit to the customer. We would have been working on this project for six months.

An example is buddhi, which began with the abstract idea of ​​helping cancer patients, their relatives, and friends. A core function of the project is to help cancer patients to cope. Users moderate wish lists created for the relatives and friends of the patients so that they can support. Relatively speaking, a person who cannot walk wouldn't be presented with a horse ride. As a result, we implemented the primary idea plus:
  • a library;
  • a simplified format of a mass blog within a resource where you can share what happens to you with recommendations of doctors;
  • a forum with the community for communication and support;
  • and a feature that helps to find a companion to help a person cope.

The project continues to evolve because it is an idea that is continually changing and growing. Two new features are under development: social support tool and wellness marketplace.


What advice would you give to clients who decided they want to develop an application?

  • What questions do you need to answer before contacting a developer company?

The first thing I would advise is to understand why this application is needed. A pervasive idea among potential clients: is to make an application because their competitors have one. Or because their friend said it is necessary, or because everyone has it, but they don’t. It is crucial to understand how the developed application, site, site-system will be used in business and why it is needed. The next question is who will use it? How it will make their life easier/how it will help.

From this point of view, everything is easier — we study visual references, choose a design that we like, and ways to implement features. For example, a client may refer to features in the following manner “I like how registration is implemented on Medium”. We as an outsourcing company have an understanding of how it should look and work. In some cases, clients are technically competent enough (due to the specifics of their business) to say that we need integration to transfer data from one app to another. In some cases, the client does not understand what integration is and how it works. We use analogies as a solution to misunderstandings. For example, when I log in through Office 365 in this service, it knows my name and the last documents I worked with. Accordingly, we already know what kind of integration they are talking about.

A crucial point is a belief in the idea and the willingness to work. In some cases, an abstract idea is given to an IT company and it inevitably brings numerous questions which are thrown back at the client and the result is an awkward silence. In this case, the service company is obliged to protect itself and provide the project estimate that is substantially higher than the one where the technical task is provided.

For example, if you come to an IT company with a request to develop a marketplace, the price tag might be $50,000-100,000. But the client may just want to make a website to sell their products and list products of other companies. This is an ordinary online store, the cost of which does exceeds the $50,000-100,000 cheque. It is much lower. But a raw idea and lack of answers on functionality guarantee an inflated price tag. Such a misunderstanding can lead to a result that does not satisfy both parties.



Do you have a lot of experience working with people who do not understand anything about software development?

Yes, of course. Most of our clients have a limited understanding of the development process. They tend to perceive it as “ First things first, something is drawn and designed. Then something is developed, then they get the final product and enjoy their life.” In reality, the development process is much more complicated. Technology can affect the staging, and the requirements for the team are determined by both technology and the stage of the development.

Very often, it is difficult for a client who is not familiar with development to understand why we cannot change something on the service right now. We have to explain that for the service to work correctly and updates can be rolled out without damage to what we already have, a special system was integrated into the project. Gradually, in all stages of work, all the code undergoes automatic testing, after which it is uploaded to the server. Therefore, after we finish work, we need to wait up to an hour. This no longer depends on us. This is necessary for the project to be safe for users and the client.

99% of our clients do not know about such pitfalls. The exception is another IT company that came to us because their project goes beyond their competencies or the technologies they work with.

To eliminate problems in the process from the very beginning, there are several setup sessions, meetings with clients. We explain the process of work, give reasons for all decisions, and explain the process in plain simple language.

In any case, the client has a project manager. He is continuously in touch, will answer any questions, and explain any decisions. We give the client just enough knowledge about the development itself to understand what is happening, at what stage the project is, what will happen at a further distance, and a little more so that they won't be nervous about the project.
Depending on the degree of client involvement in the work, he can see the development as a kanban board, as a weekly demo, or not be involved at all, except for the start and finish stages. The kanban board shows progress through tasks. The weekly demo format shows the results of the weeks’ work and provides information on technical progress. If we work with the weekly demo format the client can see a business impact and we regularly discuss the plans for the next week.

The last case is characterized by minimal client involvement. They choose to receive the final product on the agreed dates or earlier, without a demo or regular contacts. This often happens in very bureaucratic companies, where the workload on the person in charge of the project within the company is very high. In such cases, communication with the client takes place at the stage of agreeing on the details of the project, developing the technical specifications, and the design stage. We agree on the deadlines after the client provides all the data and accesses, and they leave to go about their business. They have no desire/motivation/time to get more involved. They can check on how things are going two or three times a month. Usually, the answer options are everything is ok, we are moving according to the plan, or there were unforeseen difficulties, but we solved them, everything is going smoothly.

Closer to the delivery of the project, they begin to get involved, request some materials, and become more engaged. Such cases are rare, but they have happened in our practice. People come, pay money, sign an agreement, issue a technical assignment, which they have drawn up independently or with us, appear on the days of the project's delivery, accept and test it, and happily ride off into the sunset. This format works perfectly for them.

But most often we work with regular demos and calls between demos to synchronize, understand the order of the next tasks and their priority. If we are talking about projects that are related to the existing business, there are nuances. In the process of working on a project, most often the client needs to change something. For example, some priorities have changed, or a new direction has been launched and they ask to make adjustments to the priority or the format of implementation. We meet clients halfway and make changes by agreement of the parties.


It seems that technical specification is one of the most important points, is it?

It is not the rule of thumb but, the technical specification is important, it helps to avoid many problems and ensures that expectations do not diverge from reality. The existence of a technical specification tied to the strict contract, which does not allow changes in the process, has a downside. It assumes that the product will be exactly as described in the document. Therefore, problems may arise.

For example, we have compiled a technical specification for a certain product that contains 10 functions. In most cases, all ten of them aren't related. They are connected in pairs or in the format of some kind of web. And changes in one of the functions always entail changes in the work of others. Not necessarily, but more often than not, changing one thing, affects the rest of them.
For the customer, agreeing with the developers that the work will be carried out strictly according to the technical specification, it is important to understand that at the moment of changing something in the process of work, there is a possibility of getting an additional cost and invoice.

Because the volume of work will grow, additional changes will be made. Clients are very often afraid of this. They assume that there is a technical specification, which means everything is in order. In their minds, the change may relate to 10 lines of TS (Technical specification), which means it will not particularly affect the work. Therefore, if we feel that the client is not sure of the stability of at least 75% of the functionality, we suggest working in stages.

In this case, technical specification is a document that consists of intermediate technical specifications. We have a task for the first stage, after which we prepare for the second, and at the end of the second — for the third. It is possible to prepare the technical specification several stages ahead, but then we agree on the possibility of making changes. As a result, we are on the same page with a client, and we are confident in the output results. Such a technique severely limits the possibility of problems arising down the road.


We have a general full description of the project from a to z, but there is no detailed technical description. It is formed in the process of working with a backlog of two to three weeks. The client sees what was done, what are the plans, and sees the section “Ideas for the future”. Once in a certain period, a sprint of tasks is formed, we are engaged in development. The client receives the complete technical assignment for the entire project towards the end of the work. From the very beginning, he has a functional description of the entire project and a fully formed idea, but without technical nuances — descriptions of interactions with every possible button, such as clicks, effects, and functions.


Do we work according to someone else's technical specification, and which option is easier?

Yes, of course, we are working with other companies' technical specifications. If additional questions arise, we ask and amend the terms of reference that were brought to us. It turns out the following version of the technical specification. In most cases, if the technical specification is correctly set up, it is a near-standardized document that you can bring to any IT company and they can work with it. There are cases when the technical specification is written for specific technology and we cannot work with it.

For example, technical specifications are made by a development company, for themselves, and they write in Java. The clients got a detailed, cool structured term of reference — a great document, but for Java. And, the company's internal specialists insisted that Java is not suitable, their ecosystem needs Node.js. Thus, 60% of the content of TS has to be thrown away, since it describes options for interaction between systems that are not suitable for Node.js. We turn this technical specification into a functional task, and based on it, we write a TS from scratch. But this is a rather rare situation.

Most often, the terms of reference that will be drawn up to the customer from the majority of IT companies do not contain information that is strictly tied to some kind of technology. These are usually abstractions that are broadly applicable to different technology stacks. For example, we will use a microservice architecture, then there is a list of services, argumentation, a detailed description of each (what happens inside, what functions and formats of interaction with other services). Such a technical task does not require special amendments. We will work with it and make edits needed for internal use. We will independently break down the TS into tasks, format it, detail it in some places, and remove the detailing in some places. This will give the company's CTO the opportunity to look at the problem from a new angle and compare the proposed solutions.

This is just the first interview in a series of conversations with the altRecipe team. There will be insights from our developers, hot takes from the lead designer, and predictions from the CEO. Stay tuned and share your application and project ideas. As Herman promised in an interview, we do the initial TS for free.