New components should be thought through and useful from a business perspective. Unnecessary functions should disappear and periodic reviews should be maintained to ensure that Kyma is still on the right track.

• Strive to have central, core concepts. For example, labels for event providers. Every concept must have an owner.
• New product design is not only based on a feel for the industry, but requires extensive research. Product decisions are based on a specific business need using real qualitative and quantitative data received from user testing, and feedback.
• Don't keep unused features. Based on proper data analytics, identify unused features and evaluate whether you can deprecate them.
• Perform frequent roadmap reviews and adjustments so as not to fall behind. Don't get stuck in implementations that do not make sense.
• Every entity must have a defined lifecycle. From the very beginning, there must be a design. For example, the proper removal of data for inactive, or trial and demo users.
• Documentation is important at every production level, both detailed and more general.

How we run? Fast, simple, efficient.

• Create more with less. Resource and component efficiency is crucial. Minimize impact on the infrastructure by keeping resource consumption to the minimum when you work toward any goal.
• Delivering features is easy, but keep in mind the recommended limits on memory usage (not more than 64MB), startup time (not more then 3 seconds), and resource consumption. For example, consider the size of the logs you produce.
• When choosing technology, consider the cost of the onboarding process, the size of the community behind it, and the adoption rate.
• Have a fast and reliable deployment pipeline.
• The whole Kyma cluster must be easy to deploy and easy to remove afterwards. This gives you a good way to handle and test the presentation environment. For example, this lets you test upgrades to the whole environment.
• Use logical over physical separation. For example, leverage Kubernetes namespaces to separate environments.

To increase the comfort of the programmer's work, quick configuration of any component is required.

• Think not only about low operation costs, but also about quick setup in any environment, even a local environment. Remember that you must be able to run every component out of the box on Minikube.
• Build and use native Kubernetes functionality. For example, leverage your solutions with Kubernetes CustomResources.

Architecture of the whole Kyma should be flexible enough not to cause bottle necks. So don't depend on projects which creates more problems than they fix.

• Avoid technical dependencies on non-Kyma teams. Also keep a clear separation of concerns, and never split functionalities across teams. Scale teams based on current team members. For example, the setup of the Gopher and Gorilla teams.
• Strive for event-oriented architecture. Achieve full independence to make it simple to exchange components.
• Make clear the separation between the technical and commercial aspects. Whatever we do, we should not depend on external commercial implementations. For example, do not depend on external marketplace implementations; we should write our own.
• Avoid components that make the whole solution dependent on them.

Kyma focuses on quality. Analytics, logs, tests are a priority for every component as well as integration between them.

• Focus on integration first to avoid hiccups later. You don't want to wake up in the middle of the night to acknowledge your component is down because your integration point failed.
• Have unified, easy, and built-in monitoring.
• Analytics must be sewn into any tool that we provide, whether API, UI, or CLI. Meter everything to easily understand what is happening in Kyma.
• Have fast and easy access to logs and metrics, to react to incidents and not waste time troubleshooting.
• Create automated tests of the entire functionality, not just including components, but also integrations.
• Security and data privacy built-in by design

The product must be, not only easy to use, but also consistent and of good quality. Build tools and solutions with the understanding that they should be available for everybody in the same way.

• Treat CLI as a first-level citizen.
• Whatever tools you build for yourself should also be available for our customers and Kyma users.
• Be transparent with customers and Kyma users by exposing SLA fulfillments, not only from the data point of view, but also applying the measurement rules.
• Every solution exposed to customers and Kyma users should be usable in no more than three steps.
• The UX should keep customers and Kyma users focused on the tasks they want to perform.
• Build tools and solutions with the understanding that they should be available for everybody in the same way, with no exceptions or internal hacks.
• Batteries included. Customers and Kyma users should have everything enabled by default so they can use our features out of the box. Customers and Kyma users should not only get some basic roles, but also sample applications, lambdas, and anything that will help them learn from the very beginning.
• Basic things, like SSL certificates and JWSK, should be available out of the box.
• Quality matters. The product must be, not only easy to use, but also consistent and of good quality. Validate every part of the product that faces the customer against standards and guidelines, in the most automated way possible.