Manifesto
Software is not delivered.
It is kept alive.
Why LIVING SOFTWARES exists, and what the company refuses to do.
The lifeline It weakens, then stops: software delivered, paid for, then abandoned. That is what LIVING SOFTWARES refuses.
01 · Twelve principles
A philosophy before a style.
Living Software, our philosophy: designing software that evolves with its users. It is not limited to a visual language; it shows in the finished product, in its architecture, its behaviour, its performance, its design, its accessibility, its security and its ability to evolve.
- 01
Utility before spectacle.
The value of software begins with the problem it solves. A spectacular interface that does not help the user is a failure. Spectacle is justified when it brings real value; otherwise, good software is discreet, fast and functional.
- 02
Experience is part of the product.
The journey, the micro-interactions, the speed, the response to every gesture and the consistency are not decoration: they are part of the product. A beautiful page does not make up for a poor journey.
- 03
Motion has a purpose.
An animation informs, guides, confirms an action or makes a transition understandable. It must neither slow things down nor distract. And anyone who reduces animations on their device must find an accessible alternative.
- 04
Performance is a feature.
A page that loads quickly and an application that responds quickly are, by nature, more pleasant to use. An interface can be rich and fast, if the images, the code and the loading are well designed.
- 05
AI only when it matters.
AI is used when it brings a real advantage. Conventional automation, a business rule or a simple sequence can do better: a process that can remain deterministic remains so.
- 06
Design and engineering are one conversation.
Designers and engineers design together, instead of passing the work from one department to the next. The final experience is not achieved at the cost of a fragile architecture.
- 07
Security is designed in.
Security is not a last-minute addition. It is built in from the start: in the architecture, the data, the access rights and the releases to production. Each access is limited to what is strictly necessary.
- 08
Africa is not a constraint to hide.
Slow or unstable connections, modest devices, the cost of data, payment methods: these realities are part of the design instead of being ignored. Optimising for Africa does not mean building inferior software, but software that is robust in more conditions.
- 09
International quality, local intelligence.
A product must be able to meet international standards while remaining suited to its local users. The ambition: to build international-grade software from Africa, without ignoring local realities.
- 10
Software evolves.
It must be possible to maintain, observe, improve and extend a product without it losing its coherence. Delivery is not the end of it: it marks the start of a phase of operation and improvement.
- 11
Respect attention.
We do not reproduce addictive mechanics to inflate engagement. The aim is to make the product better to use, not to capture attention artificially.
- 12
Build what matters.
Technology serves a clear intention: commercial, operational, social, educational, cultural or creative. To build not just software, but experiences, systems and products that can live, evolve and matter.
02 · What we refuse
Technology follows the need.
It is chosen according to the need, the context and the constraints, never because it is in fashion. 3D, motion, AI or the cloud are means; the end remains the experience and the problem solved.
- Spectacle is not an obligation; relevance is.
- AI is not an obligation; good automation is.
- 3D is not an obligation; a clear and memorable experience is.
- The front end is not always the priority; the quality of the whole system is.
In imagery too No artificial gradients everywhere, no generic robots, no glowing brains, no vague slogans, no animations without intention. Sophistication comes from composition, motion, typography, precision and the quality of execution.
03 · Ten questions
Before building.
Before a feature, a website or a product, the team must be able to answer a few simple questions.
- 01 What real problem are we solving?
- 02 For whom?
- 03 Why this solution rather than a simpler one?
- 04 Is AI really necessary?
- 05 Does the animation or the 3D improve the experience?
- 06 How does the product behave on a slow connection?
- 07 What happens when something fails?
- 08 How do we secure the data?
- 09 How are we going to test quality?
- 10 How will the software be maintained in 1, 3 or 5 years?
The conviction
Software should not merely be functional.
It should be designed to understand its context, support its users, evolve with them and remain pleasant to use over time.