Everything written here is my personal experience and opinion, any criticism and additions are welcome.We are often approached by people who are far from IT, usually trying to figure out how to transfer the usual real processes and operations to the digital world. We are always happy to see such enthusiasts, idea generators and optimizers who take risks to try to automate routine operations, reduce costs and more.
At first glance, all the implementation of ideas fits perfectly into a compact mobile application, a website, a simple monolith with familiar CRUD operations. It seems that you can easily raise jHipster for the backend, write the front on a ready-made template (Angular, React, VueJS – whichever is more convenient for you), that it won’t take much time, and in general the project is simple, which can be done “back left foot”.
However, as always, the devil is in the details. When planning the development process, each of the stages, each of the components and elements is detailed, the interaction between them is described, the integration of external services, designs and user movement routes (the so-called User Flow) are drawn. The difference in estimates of development time / cost before planning and after differs significantly (usually at least 2-3).
An interesting trend can be traced – the higher the level of developers, the more expensive and longer it will take to create a software product. Why it is more expensive – here, perhaps, it is clear, the qualifications of programmers, designers, etc. Why long? – because developers with experience will think over a much wider range of possible failure scenarios, plan each step in much more detail, create a product that will work for years without the need to make changes, and if it is necessary to improve or add new functionality, this will happen quickly, with a focus on the domain , rather than rewriting a significant part of the code base.
Although there are situations when laymen indicate inflated prices. With my own eyes I observed situations when functionality was sold to the customer, the amount clearly exceeds the effort expended, performed poorly, and then the functionality was “cut out” from the project for a fee.\
So how can a person who is not related to IT order a quality software product? Where to apply? – I have formed a short list of rules, following which will reduce the risk of cooperation with an unqualified or irresponsible performer (applies to both organizations and freelancers, single developers):
1. Do not order software from close friends or relatives – in this case it is extremely difficult (due to moral and other points) to indicate the exact price that will motivate you to work.
2. Check previous work, portfolio – how many of the indicated projects are “still alive”, are there similar in theme to yours, etc.
3. Ask for plans for 1-3 months (companies that value quality still have enough orders, so they will be loaded with a high probability)
4. Order a detailed paid TS – only paid services can be held liable, re-read the TS, check how detailed it is, correctly understood your idea, follow how the TS was written, communicated with you on incomprehensible moments, or simply did not include it in the TS that they did not understand, took the initiative and added some of their ideas?
5. Ask to evaluate the project in case
1. Rapid development.
2. quality design.
3. optimal ratio quality / speed.
6. Ask for a Sample Test Plan
7. Take Your Time – It’s rare to build a product in a short amount of time.
8. Break creation into several isolated steps
1. Testing – checking your hypothesis, working out each necessary functionality, interaction between modules, services, integration – at this stage, you can determine the restrictions that will be imposed on individual parts and the project as a whole, it is possible to redo the concept and even abandon further development, if it is obvious that the contractor does not “pull” the required quality.
2. Working – link all tested hypotheses, proven functions and integrations into a single system and release the product.
9. Go into the details of the development, so that in a week or two it doesn’t turn out that the performer understood the task and how it performed at least a little closer to what you expect.
I hope that short tips will save you from frustration in the process of developing a software product.