Below is a common scenario in the world of custom software development.
A Client applies with a software development Supplier to create a custom software product. This Client is a non-technical person, very busy and can’t dedicate much time to the management of the product development. The Supplier ensures the Client that everything will be done successfully, so the Client trusts and relies totally on the technical competence of the Supplier.
Time passes by.
The supplier shows delivery packages to the Client from time to time. The Client tests them, all looks good and the functionality that the Supplier mentioned works.
Some more time passes by.
The Client finances the development and the Supplier confirms that all is well, but the software is not ready for launching yet.
Some more months pass by, but the situation doesn’t change much in general. The Client then becomes worried and decides to get an objective overview of the state of the software development. The Client then involves an independent tech consultant to carry out an evaluation of the existing software.
The independent tech consultant then brings to light that the functionality that was reported as complete has plenty of bugs and the approach to creating it was not optimal. The solution is hardly scalable and the programmers did not follow the core principles of software engineering.
The result is that the Client has wasted money and time, cannot trust the current Supplier and cannot continue development in this way.
Because of the software’s poor quality, it does not make sense to develop it further or to fix the existing bugs, as it will cost more than to develop it from scratch. In addition, there is no option to launch it soon.
To avoid this kind of a situation you should follow these principles.
Trust but verify.
It is fine to be a non tech person, but at the same time, it is better to add a set of basic software engineering requirements for your future product in the agreement. You can find this information easily on the internet. Simply gather the most common search results for ‘Best software development practices’, ‘Coding conventions’ or ‘Bad coding practices’.
As another option you can request this set of rules from an independent consultant.
Business logic above all.
Any software product is not a main goal but a business tool. Even if it isn’t ideal from a technical point of view, it should still fulfill its main business mission.
That is why it’s crucial to describe the whole logic (which is better in relational schemas) and make sure that your tech team understands exactly what you want (ask them summarise your requirements and evaluate their understanding).
Important: you should keep track of all requirements and descriptions of your software’s logic in emails or live documents, or via a task management system
There should be a plan.
For a non tech person the best plan is a clear and simple set of steps that are easy to understand. It is important that every step in the plan should have a uniquely defined indicator of its completion.
For example an unclear completion indication would look something like this:
- Functioning System of push notifications.
while a clear completion indicator would look something like this:
- Functioning System of push notifications, i.e. every user (when he is logged in on iOS & Android devices) on the platform will receive notifications on his device about new added activities for a news (articles) list for each category separately. In a settings menu there will be the possibility to turn notifications on/off for each category separately or for all categories at once. If a user clicks on a notification it will automatically redirect him to that particular article’s screen.
Require reports and risk alerts.
Implement a system of reports, which allows progress tracking and evaluates the readiness of the plan.
There is a simple rule - if work time was spent on something, there should be visible progress.
It is better if reports correspond to an appropriate plan (daily, weekly, monthly).
Important: agree with your tech team that it is their responsibility to check and give you notice of any risk (possible development time increases, possible additional expenses for 3rd party services and basically about anything that may impact cost, timing and quality of the solution).
Regular communication and feedback.
It is crucial to have meetings at least once a week for at least an hour. Remember that you are the person who cares most about your project.
Ensure possession of intellectual rights and access to the code.
Quite often a Supplier develops a software product using their resources (laptops, servers, cloud, git repo).
It is important to remember that every paid part of the software product should be the Client’s intellectual property (if it was not stated otherwise in the agreement).
At the same time it is better for you to have an archived copy of each version of the product. In the case of any force-majeure this will make it possible to continue any activities with the software quickly.
Of course real situations could be way more complicated and require more detailed work with each of the above principles. However if you follow them, you will have a greater chance of successfully developing your software product with less risks, even if you are not a tech person.
Please share if liked and let me know if you have any questions. Thank you!
COO, YSBM Group
Request free consultation