Introduction

Starting the development process can seem difficult for most clients. This is true whether you are building a project from scratch or rebuilding an existing one.

Some time ago, our team created a checklist of what you need to be prepared before starting custom development. Today, we will share a real-life example from one of our previous clients to review the situation not only in theory but also from a practical perspective.

My name is Anhelina, and today I will be interviewing the CEO of our team, Pavel, who knows all the project details from A to Z. We will share our experience and explore the process in greater depth.

Some general information

A: Who was the client (industry, company size, geography)?

P: The client is a German mediator company operating between car dealers and insurance companies. The company has between 50 and 99 employees. It is responsible for all actions, including document exchange, payments, communication, and other tasks required to get insurance payments and repair vehicles after traffic accidents.

A: Was the product built for internal use or for external users?

P: Both. Initially, the platform was intended for internal users. However, during development, it was expanded to accommodate external users as well.

A: At what stage did the client come to us (idea only / existing system/prototype)?

P: The client came to us when they wanted to replace their old system with something new, modern, and more effective. They specifically did not show us their previous platform, so that we would not be guided by it during the development of the new system. As a result, we had to develop everything from scratch. We began by collecting information and gathering requirements based on their responses about the business and its features.

A: Why did they decide to go with custom development instead of a ready-made solution?

P: There is no ready-made solution that meets the business’s needs. The business model is working only in a single country. Other countries may have their own requirements, so a universal, ready-made solution does not exist at present. Some SaaS CRMs can cover part of the required functionality, but the lack of customisation and flexibility makes such systems ineffective. Additionally, there was a requirement for a fully custom-coded platform, ensuring that our client is the only owner of the source code, with no third parties involved. The system is independent of any external resources, runs on its own local servers, and is self-sufficient.

Defining the existing problems and needs of the business.

A: What issues in their current workflow caused the most problems?

P: They were using an old system. A big part of the process was handled manually. More than 50% of all document exchanges were conducted manually, using emails, paper, and standard mail services. As a result, the process was untracked, inefficient, and slow, making it time-consuming to send or receive paper documents. This also led to many issues that were difficult to track as well.

A: What business goals were tied to the project (reducing manual work, improving customer experience, scaling operations, etc.), and were they prioritised?  

P: All the goals you mentioned were relevant: reducing manual work, improving customer experience, and scaling operations. Additionally, greater control over all operations and enhanced security were important objectives. The system also needed to provide access for external users, allowing them to log in with role-limited access and upload required documents instead of sending paper versions by post. All these goals were prioritised and considered important. The system went live only after the development of these critical components was completed. For example, the platform’s analytics component is still in progress because it is a lower priority, so the client decided to postpone it and start using the platform without this feature.

A: Who was involved in identifying these problems and goals (management, team, stakeholders)?

P: On their side, there were two people responsible for coordinating work with our team. They provided all necessary details and gathered information, including requests and requirements from everyone in the business infrastructure, from clerks to top managers and decision makers.

A: Did the understanding of the problem change during Discovery? (for example, the client had their own idea of the system, but during research, we found additional problems and suggested improvements to make it better)

P: There was no formal discovery phase, as this is an already operating business, and there was no need to conduct this phase or investigate the market. However, before the project began, we worked on the project specification document, which naturally changed during the process. We suggested improvements and proposed various options for the future implementation of specific features.

A: What made this product different from the previous system?

P: It is difficult to say. The reason is that we never saw the previous system. This was their decision to ensure we did not copy or base the vision of the new system on the old one. We described a new system from scratch, based solely on business needs and requirements.

We had no idea how their old system operated or what problems and limitations it had.

The aim was not to copy or rebuild the old system, but to create something totally new, with a completely different approach and working logic. We achieved this successfully.

How to adapt project development to your budget and timeframes 

A: Did the client have a clear budget range from the start? How realistic were their expectations?

P: Yes, the client had a certain budget. However, we did not know the exact amount. We provided an estimate based on the project specification and the features list. The client was happy to begin, and we got off the ground”. As development progressed, we suggested various options for how to improve different parts of the system. Similar requests also came from the client and their future users.

It is impossible to plan 100% of the system. Inevitably, there will be changes during development, as only when people start using the system do they realise what could be done differently or better, what they want to add additionally, and what was missed during planning. This is a normal, ongoing process.

As a result, the budget increased by at least 50%. The client was happy to pay more, as they received more – a better tool than was described in the initial plan. We continue to refine the system.

A: Did we discuss MVP vs full-featured product?

P: Mostly no. As it is an established business, they know what they need from the outset. However, they already plan to start another project soon, which is related to this one but will operate as a separate platform and provide additional features and options for future users.

A: What risks were considered early (deadlines, holidays, dependencies)?

P: Yes, of course. We always assess risks before starting. This project is quite large, and there was a risk of missing the deadline. That is why we constantly monitor the development process and speed all the time. As you may know, the speed depends on the number of developers working on the project. At one point, three full-time developers were simultaneously building the ground of the platform. Later, we reduced the team to two developers, and currently have one full-time developer.

But it is not always possible to add more developers. As the saying goes, nine women cannot give birth in one month:)

So, adding a second developer does not mean a 50% increase in speed and productivity. Usually, it is about 30%. A third developer typically adds about 25% more. It is also impossible to add more than one developer at the very beginning, as the core must be coded first.

When the core is ready (usually after about 2–3 weeks of full-time development by a single developer), it is possible to add two or three more developers, as they can then work independently on different parts. It is similar to building a house: once the foundation (groundwork) is complete, one person can build the west wall, another can work on the east wall, and a third can prepare concrete for all. The same principle applies here. We can add more people only when the work can be divided.

A: Were there any scope or timeline estimation adjustments during the work?

P: Yes, of course. We continuously re-estimate changes, prepare estimation documents, track time, and allocate additional budget as needed. We discuss priorities for each task, focusing on the most important first.

Wireframes and UI/UX preparation

A: Did the client come with wireframes/sketches, or did our team create them from scratch? 

P: We used a ready-made dashboard template for the system’s first version, the Alpha version. It was customised slightly, with changes to colours, fonts, and the addition of logos. In parallel, our designer worked on a fully custom platform design, which we implemented in the second system version, the Beta version. The first stable version was released with a fully custom design.

A: How did they affect the project’s clarity? 

P: They had a significant impact. All design changes were made in cooperation with the client, based on their wishes and suggestions.

A: Was UI/UX designed from scratch or based on templates? Did we have any design challenges?

P: As mentioned previously, we used a ready-made template for the Alpha version. During development, our team’s designer created a custom UI/UX design. The stable version was released with a fully custom design.

A: How involved was the client in design approval?

P: The client had permanent access to the design files. We used the Figma online design service, allowing them to observe every design change daily and provide comments.

Software Requirements Specification

A: Did the client understand the importance of SRS initially?

P: Yes, absolutely. The first stage of development was to prepare this document. It was impossible to proceed without documenting all the details and compiling them into a single SRS document.

A: Who was involved in preparing the SRS, and what were the most complex parts to document?

P: Both parties were involved. We have a business analyst whose role is to prepare SRS documents for projects. He developed the SRS together with the client. The client’s role was to review progress, answer questions, provide comments, and approve completed sections.

A: How did SRS affect project understanding and development? For whom was the specification the most useful?

P: It is fundamental. It is impossible to plan the development of such a large platform without an SRS, timeline, and estimated feature list.

As project documentation includes mockups and wireframes, it provides a better understanding of the system through visualisation and description. It is always better to see something once than to read about it ten times. Therefore, it was useful for both parties – very useful and very important.

A: Did the document help you to avoid misunderstandings later?

P: For sure. Not all misunderstandings were avoided. Of course, some misunderstandings occurred, which is actually beneficial, as it allows us to see how we address such issues in cooperation with the client. This is very important during the specification phase. It provides clarity on how to act and handle such matters later, during development. In large projects, it will happen for sure, so it is valuable to gain this experience together with the client during SRS development.

Summurising

A: Did early preparation help minimize risks? What could have gone wrong without this preparation?

P: It absolutely did – by 200%. Without proper preparation, the risks would have been much greater. Anything could have gone wrong, from wasted time and focusing on unimportant parts to skipping important aspects and creating incorrect expectations due to failed or impossible estimates.

A: Did any hidden constraints appear later?

P: I did not understand this question. Could you give me an example of hidden constraints during development? As I understand it, these could be, for example, budget limitations if we were not informed of the budget at the outset, or time constraints. But this type of project requires openness from all parties. The more accurate information we receive from the client, the more predictable the results will be. If the client hides the deadline from us and simply says, “just code as you go,” and then, a week before completion, informs us that the deadline is in a week, this creates a bad experience and an unexpected situation. We always try to avoid this by asking as many questions as possible to clarify all details.

A: How did development start after project preparation?

P: According to the plan. We finished preparations, provided an estimate and timeline, planned deliverables, and a start date. As a result, development began on the planned date.

A: What feedback did the client give?

P: Great job done! The client is very happy and will launch the platform on 1 January 2026. We continue to polish the system, and the client is preparing documents for the next phase.

A: What would you highlight as the most critical preparation step?

P: The most critical step was gathering requirements and clarifying requests. The most complex aspect was delving deeply into their business processes to understand precisely how everything must function. Mistakes still occurred, but communication is key to successful development.

A: What advice would you give future clients?

P: If you want to sleep well and do not want to worry about deadlines or budget, you need to invest in documentation development. Clear, written instructions and ongoing communication form the basis for planning the entire development process. 

Prepare an SRS before starting development – you will save a lot of time and money later.

All the best,

Pavel Moroz, CEO and co-founder, TuneLAB web development team

We hope you find the article interesting and useful. In summary, projects may differ, but if you know what you need, trust the process, and have a reliable team, the result will be excellent. Always contact us for a free consultation if you are unsure whether you are doing everything correctly or have any questions.