15 things we would like to know before developing a startup

During the four years of work on the online consultant WebConsult, we have accumulated quite a lot of experience, and it turned out that initially we did not take into account many things that we had to redo - in the end it cost us a lot of time, money and nerves. This article, and possibly a series of articles, will be devoted to aspects that need to be thought out even before the start of development, so that future start-ups initially lay a competent foundation in their web applications. This article we really missed four years ago, when the creation of the system was just beginning, and we hope that it will help you not to repeat our basic mistakes. Many of the tips given will seem obvious to someone, but often the developers miss them, so we consider it necessary to remind you of simple things again.

1. Multilingual

When developing, we thought that the day when our project would become international would not come at all very soon. The goal was to start up in Russia first and see what happens, and if the project goes, then we can quickly translate everything into other languages. We were mistaken and as a result received a huge amount of texts sewn directly into the project templates and JS code, and in some places the logic of the application itself didn’t contribute much to localization.
We have now begun work on transferring all texts to lang-files, including those from javascript (thanks to the wonderful i18next library), but if we thought about it initially, then it would be much easier to do this. Of course, all the new features and interfaces, we are now immediately preparing for localization.

2. Time Zones

Do not forget that only in our country there are 9 time zones, so we recommend immediately enabling the user to select a time zone and apply it to all dates on the site, statistical samples, etc. Then it will be hard to remake.
')

3. Think about scalability

If your startup is successful, then sooner or later the moment will come when you will not have enough power of one server. As a rule, there are no problems with load distribution on the HTTP server: we set the balancer server and direct traffic to several identical HTTP servers. The situation with database scaling is much more interesting. Of course, there is replication, but, as practice has shown, it is extremely unreliable in the case of c MySQL. It is better to bring logically independent parts of the projects to different DB servers (sharding), but it is better to think about this before developing the application itself. For example, especially heavy modules can be put on a separate database server and load the main one. Even if you initially want to run everything on one server, then consider the possibility of easily transferring some modules to a separate server when the need arises.

4. Output everything to the API

If your application implies the availability of a public API in the future - think about it right away. When working on a module that theoretically should be available to third-party developers, immediately make the API methods for working with it. With the right application architecture, it is very easy to do this, it is much more difficult to do it later. We still do not have a full-fledged API just because we didn’t think about it initially - now we are working to correct this situation.

5. Avalanche requests - in Redis

The button of our online consultant is located on thousands of sites, and the number of button hits is estimated at tens of millions per day. Each button display generates a query to the database, which saves the visitor’s transition - this is necessary so that the consultants can see the client’s full path through the site during the conversation. At first, this data was recorded in MySQL, which turned out to be completely incorrect in the end. First, it was the most important source of load on the database. Secondly, mysql was extremely negative about such a furious number of simultaneous requests to change the table, and sometimes even short-term blocking of the database occurred - requests accumulated, and the entire application started to slow down terribly. Thirdly, the process of cleaning this data after the expiration of the statute of limitations was rather resource-intensive. We have experimented a lot with MySQL settings and achieved little. In the process of searching for alternatives, it was decided to switch to Redis , which writes data into memory in the “key”: “value” format, providing high read-write speed and the absence of blocking requests, and the data can be cleared by specifying time-to-live. Such model suited us perfectly.

Not to say that the transition was smooth: I had to dig deeper into the Redis settings, rewrite a bunch of scripts, survive several downtimes, but still we did it and as a result we reduced the load on the database almost twice. Again, if we thought about it in advance, everything would be much easier. Therefore, if you are planning similar “avalanche-like” requests, it is better to transfer them to Redis right away: someday you tell yourself thanks for that.

In addition to Redis, there are other similar products, but, unfortunately, we did not work with them.

6. Minimal user interaction and technical support

Reduce the number of operations that the user can not do on their own, without the participation of support. Examples of such operations are - transfer to another tariff, formation of a contract, invoicing, closing documents. Ideally those. support should help users to perform operations already available to them, and not to do these operations for them. By unloading support staff, you can get by with less staff and save money.

7. Avoid clutter in project files.

We are very sorry that we didn’t think well about the file structure of the project - so we had some confusion in the files of the system: somewhere because of elementary laziness, somewhere because we did not take everything into account. Slowly we bring order, but this is not a quick matter. Naturally, this does not affect the operation of the system, but it hinders the development process. And in general, when all the files are in place, it causes aesthetic pleasure. Just think about where your libraries will be located, how the static layout will be organized, and on what basis the project files will be distributed.

8. Use JavaScript Templates

Few developers know, but javascript can also use templates, which not only makes js code cleaner, but also makes it much easier to work with HTML code. For these purposes, there are a number of products: Handlebars , Swig , EJS , undercore.js . If you plan to develop RIA (Rich Internet Application), then we recommend to get acquainted with Backbone.JS , which will be an excellent framework for your JS-application.

9. Clean up unnecessary data as much as possible.

Your project should live according to the principle: if the data is outdated or the storage period is out, they should be deleted. The more data in the tables, the greater the load and the slower the system. As you develop, create cron-scripts that will delete unnecessary data - this applies not only to the records in the database, but also to user files. For example, a common mistake is to delete the record with the file from the database, but the file itself in the storage remains.

This also includes the case when the main record is deleted from the database, but the records associated with it in other tables are not deleted: thus, the integrity of the data is violated. MySQL can use triggers and foreign keys for this purpose.

10. Uniform design - in all

Try to ensure that your design is the same everywhere: it has the same overall style and style of individual elements - such as forms, buttons, scrollbars, tables, etc. When developing a design, create a kind of standard and do not back down from it. Firstly, this will greatly facilitate the layout, and secondly - it will be more convenient for your users if everything is unified; thirdly, it's just beautiful when everywhere, even in small things, the overall style is preserved.

11. Use LESS for styles.

LESS is a simple tool that turns ordinary CSS into dynamic and allows you to use nested rules, variables and functions. The CSS code becomes more visual, and the development process is greatly simplified. At the output, with the help of a special utility lessc, we compile the less-code and get the usual css-file. We can hardly imagine how we did without LESS before - be sure to try.

12. Logical pricing

Even if you have fixed rates, sometimes there are situations when the client requires an individual calculation of the cost for his needs. Very often some indicative prices are called, the origin of which is not clear. At first, we sinned by allowing users to dial only those functions that they needed. Accordingly, the cost of such tariffs was calculated approximately and varied from client to client. This created a lot of confusion within the company and then we decided that all prices should be calculated logically. We had to make individual tariffs less flexible: now people can choose not individual functions, but sets of functions — however, this way we got rid of the confusion and our prices became 100% transparent and understandable for both clients and employees.

13. Immediately think about how you will collect statistics.

If your application should have statistics on any data, we strongly recommend to think in advance about how it will be collected. After all, when it comes to statistics, it is important not only to obtain data from the database, but also to do it quickly. It is possible that for the convenience of sampling you will need to add additional keys or immediately collect the counted data somewhere.

14. Modify only those functions that will be useful to other customers.

The standard situation: a client comes to you, who in principle is satisfied with your product, but he needs to “modify” a little bit, otherwise he will refuse. Very tempting, especially at first, to succumb to the entreaties of the client and finish any opportunities specifically for him. But do not rush. First of all, think: will this feature be useful to other customers? If this is something narrowly targeted and necessary only to a specific client, then it is better to drop this business. Otherwise, constantly creating individual improvements, you drive yourself into a pit, from which there is almost no way out - your code becomes dirty, and when developing new features, you will have to check them for compatibility with a bunch of small individual improvements. This does not mean that you should not listen to your customers - we only recommend that you rely on the wishes of the majority and be wary of single ideas.

15. Think about those who join the development.

A simple rule when writing code - always ask yourself the question: can the new developer be able to figure it out? Do everything logically, beautifully and do not skimp on the comments. Often, projects start writing alone and do not think about it. However, if you ultimately count on a larger project, the day will definitely come when new programmers will join your team and they will have to delve into your code.