How Not to Lose Money and Time When Developing a Software Product?

Dmytro Sikorskyi, Owner, CEO, 14 September 2023

In this video, we will tell you how not to lose money and time when developing software products, namely, about the importance of preparing technical documentation and design before starting development, as well as about choosing the right team.

Design and Technical Documentation

First and foremost, my strongest advice is to never embark on development without having solid design and documentation in place. At the very least, ensure that all pages or screens are fully designed without any exceptions. Even better, invest a bit of time with designers to create an interactive prototype that mirrors the actual website or app. This way, you can click buttons, navigate between screens, and access various pop-ups as if it were the real deal. It’s a standard practice that many follow by default, but it significantly eases comprehension and enables even those without experience to spot any overlooked elements.

One more point. If you are making a website, you will need at least 2 versions of the design: for mobile devices and desktops, and it is better to make a separate version for tablets as well. The same applies to applications that are launched simultaneously on phones, tablets, and possibly even on desktops.

Also, you can share your design or prototype with individuals outside of the project, such as testers, to gather their unbiased opinions. These should be individuals not directly involved in the project, offering a fresh perspective.

Why is all of this so important? During the pre-development stage, making adjustments to the design is relatively easy. You can relocate a button, alter the navigation, or even introduce a new screen, taking only 10 minutes. However, once development is underway, those same changes are likely to take hours or even days, resulting in a significant difference in costs.

As for the documentation. This is quite a vast topic, to be sure. In essence, it follows a similar principle as design. You can easily and swiftly alter text within a document, but it becomes a lengthy and costly process to rework something that has already been programmed. Moreover, the more substantial and unexpected changes that are introduced, the more it impacts the overall code quality. And, as a consequence, the lower the code quality, the more time and money are required for product development.

Here’s why: When changes in requirements emerge during the development phase, there’s typically insufficient time and resources to implement them correctly. Instead, quick adaptations are made to align with the original intentions, and this cumulative effect can lead to complications.

For instance, consider a scenario where your application’s interface and content are initially in Ukrainian, and then, at some point, you realize the need for an English version. This seemingly simple shift requires alterations across multiple layers, including the database, admin panel, and more. This triggers a sequence of activities, from testing to error correction, which can take an entire month of work.

Here’s another example. Imagine you’re in the process of developing an order processing system. Now, consider what happens if the internet connection suddenly disappears? By default, you won’t be able to accept new orders or access existing ones. It’s one thing to enable offline viewing or delayed order creation, but quite another to manage edits to existing orders. This becomes complicated because different users may edit the same order when there’s no communication, and then these changes need to be somehow merged. Addressing such issues requires specialized architectural solutions. If you don’t plan for this from the start, it might be more efficient to start the order processing system from scratch later on.

Finally, if you lack a detailed description of the scope of work, it becomes unclear what exactly you’re agreeing to in the contract. In case something goes awry, even if another team takes over your project, they won’t be aware of the original plans and won’t be able to efficiently continue the work. Unfortunately, we’ve witnessed on numerous occasions how hours and days saved during the planning phase can later translate into months lost during development, ultimately increasing both the cost and time required by two or more times.

Team

Let’s talk about the team. Here’s my take: It’s best to steer clear of weak teams (even if their prices seem enticing). In our highly technical and complex field, experience plays a pivotal and all-encompassing role in the final outcome. If you choose to work with a subpar team, I firmly believe you’ll end up losing both time and money. Here’s why.

To draw a somewhat basic analogy, think of software development like building a house. It has its own “foundation”, “supporting walls”, “utilities”, and so forth. In a similar vein, each feature you add is like an extension to that foundation. Consequently, during the project’s initial stages, it’s incredibly vital to lay down the correct architectural groundwork with an eye on the future. Achieving this without ample years of experience (or, as previously mentioned, without proper documentation) is simply unfeasible.

Now, let’s consider this from another angle. As a customer, you might not be overly concerned about things like code quality as long as everything seems to be working smoothly. However, as time goes on and each new task becomes increasingly time-consuming and error-prone, the prospect of completely overhauling your product may eventually arise. It will be important, but it will be too late, and the worse the code is written, the sooner this moment will come.

Lastly, let’s discuss the implications of a low rate. Low rates often translate to lower wages for the people working on your project, which can, in turn, result in a lower level of professionalism. A less experienced professional tends to work at a slower pace, requiring more time to tackle tasks. Moreover, the relationship between experience and salary isn’t linear; it’s more of an exponential curve. So, what a skilled specialist can accomplish in a matter of days, a novice might struggle with for an entire month and ultimately deliver subpar results. Therefore, there’s no real economic sense in opting for lower rates either.

That wraps it up. I hope you found this information valuable. If you have any questions on this topic or need further assistance, please don’t hesitate to reach out. We’d be delighted to help.