Create a minimal technical specification

Before designing a project, it is important to draw up a specification document in order to put in black and white the client's expectations and the technical means implemented for its completion, in order to protect both the service provider and the client.

It is worth remembering that a specification document is essential in the eyes of the law, even in the case of an agile methodology.

To carry out such a project, the specification document is divided into two parts: the functional specification and the technical specification.

The first will contain the formalization of the client's expectations (project description, features, mockups, etc.), while the second will contain all the technical specifics of the future project.

It is on this technical specification that I will focus today, listing the main information that absolutely must appear in it.

Feel free to add any information that seems necessary to you in order to successfully carry out this project.

The platforms

Where will this project be available? On the web? On desktop? On a mobile application? On a public or private store?

All this information is of prime importance because it will determine the languages and technologies to be used. A simple project may be deployed on a single platform, while others may be deployed across multiple platforms; the choice of technology to adopt will then have a major impact in terms of the project's profitability.

Version compatibility

Once the platforms have been determined, it is also necessary to add a safeguard on the minimum versions to be supported.

This must be discussed with the client, based in particular on the typologies of expected users (country, ecosystem, age, quality of life, etc.).

Beware, very old version compatibility may impose unexpected technical challenges that could multiply the timelines!

Screen sizes

Just like the platform versions, supported screen sizes are important to define.

Today most applications (web, mobile, or desktop) are "responsive," but the screen sizes of devices range from the wrist watch to the 8K screen.

The ideal is therefore to specify a minimum size to support (4 inches for example), a maximum size beyond which the interface will display but will not be optimized.

It is also possible to specify a minimum screen format, as well as orientation!

Reference format

Mobile-first, Tablet-first, or Desktop-first — it is not fashion that defines the reference format set up in the project, but the study of future users, their usage, and their expectations of the application.

Typically, an administration panel (back-office) will rarely be designed in mobile-first.

Connectivity

Does the application require a lot of bandwidth? Or, on the contrary, does it need to be able to continue functioning in "offline" mode?

How does connection recovery work, and what would the minimum connectivity be for proper use of the project?

User load

Knowing the nominal and maximum user load of a project makes it possible to make architectural decisions, software design, and server sizing accordingly.

The goal is not to try to guess a precise figure, but to have an order of magnitude, for example:

If the project aims to be made available to the company's employees, the number of users will grow along with the company itself. Whereas if the project reaches the general public, it will be necessary to anticipate load surges linked to the communication behind the project.

Code hosting

Where will the application run, on what type of server? Shared? Dedicated? VPS? Cloud? With which host and in which part of the world?

Are there any legal constraints or client requests that have guided these choices?

Versioning

Is the code saved with a versioning tool? If so, which tool (Git, Mercurial, SVN, etc.) and with which providers are the backup servers hosted (GitHub, GitLab, self-hosted, etc.).

Responsibility

It is good practice to disclaim one's own responsibility in the event of an incident within the hosting company, and to state that any restoration of service task due to a hosting provider failure will be subject to billing.

Domain name and registrar

With which registrar will the domain names be registered, as well as their uses (distinguishing the main domain names from those that will be redirected).

Data hosting

In addition to the elements indicated in the previous section, which should be reiterated for the data, it is essential to specify the backup strategy or strategies implemented in the event of an incident.

You can also state that any client request that violates GDPR will be refused for legal reasons.

The planned architecture

The ideal is to present a macro diagram of the ecosystem through which the data will flow, containing the various servers, terminals, and software clients present.

Database, web server, file server, CDN, web application, native application — everything must be included.

Don't forget to mention that depending on the project's needs, this information may evolve.

Software technologies

To conclude, you can list all the languages, technologies, and frameworks that will be used during the design, and possibly justify these choices, particularly to help future maintainers of the project understand the technological stakes at launch.