Developing an app in 2026: what standards should we really be looking for?

I recently gave a talk on the new standards of development in 2026 at Village By CA, Vallée de Seine, Rouen. I addressed the topic of AI in the developer toolbox, presenting how I feel the developers of the new world should work to answer a growing demand.

The AI mess in the industry

Most product failures don’t come from bad ideas or bad code. They come from something far simpler: building things we don’t actually understand.

In 2026, an application is no longer just a piece of software. It’s a system of interconnected processes transforming inputs into outputs, often combining deterministic logic with probabilistic components powered by AI. This shift has introduced new complexity, but not new responsibility.

The problem is not the technology, it’s the illusion of control. Teams rely on tools, providers, or AI systems without truly understanding how they work. Ego, fear of change, and financial pressure only add noise to an already uncertain landscape.

If you don’t understand how it’s built, you don’t control what you ship.

UX standards are not optional

Standards already exist. We just don’t always follow them.

UX has evolved from simple authentication flows to complete, structured experiences: onboarding, payment, navigation, accessibility. In 2026, users expect clarity within seconds, seamless interactions, and full control over their data.

AI does not replace these fundamentals. It adds confusion when misused. There is a clear difference between using AI as a tool to improve UX, and designing products where AI is part of the experience itself.

Without strong foundations, adding AI only amplifies poor design decisions.

Product, code, and architecture: clarity over hype

A recurring issue in modern projects is the confusion between adopting new technologies and adopting better ways of building.

A product needs a clear scope. Not just what it does, but also what it does not do. Prioritization matters. A reduced but coherent V1 is more valuable than an over-engineered, unfinished system.

From a technical perspective, choices should be driven by constraints: ecosystem maturity, hiring cost, long-term maintenance, and integration complexity. This is even more critical with AI, where token costs, external dependencies, and security constraints quickly accumulate.

Security and infrastructure: control has a cost

Security is not a feature added at the end. It’s a baseline.

Protecting sensitive data, managing access properly, limiting exposure, and planning incident response are fundamental practices. With AI systems, additional risks emerge: prompt injection, data leakage, uncontrolled interactions with external models.

Infrastructure decisions follow the same logic. Cloud, VPS, or on-premise are not just technical choices, they are trade-offs between cost, control, and risk. The key question remains the same: who sets it up, and who is responsible for running it?

Observability, ownership, and delivery

You cannot manage what you cannot observe.

Modern systems require structured logs, metrics, and alerting to understand what is happening in real time. Without this, decision-making becomes guesswork.

Ownership is equally critical. Access to infrastructure, services, and data must be clearly defined and controlled. Being responsible for a product means being able to act on it at any moment.

Delivery should follow clear standards: continuous integration, frequent releases, controlled deployments, and the ability to rollback quickly. “Shipping fast” is not about chaos, it is about reducing batch size and increasing control.

Reversibility and long-term thinking

AI accelerates development, but it doesn’t remove the need for structure.

Where rebuilding a poorly designed system used to take months, it can now be done faster. But this only works if the foundations are solid. Otherwise, you are simply accelerating failure.

Conclusion

Standards exist. They evolve with technologies, products, and teams, but they remain essential.

Not understanding what you build, and not verifying how it works, is one of the most expensive mistakes in modern software development.

Asking questions, challenging decisions, and seeking clarity are not optional. They are what allow you to stay in control.