PlayOff is a cutting-edge sports facility management and booking platform designed to streamline the process of reserving sports facilities and organizing group trainings. It addresses the critical needs of facility owners and regular users by offering a seamless web and mobile application experience, allowing real-time visibility of schedule changes, and facilitating easy booking or cancellation of slots. Aimed at enhancing the operational efficiency of sports venues, PlayOff eliminates the need for specialized installation, making it accessible anywhere, anytimeThis user-friendly solution not only simplifies the management tasks for owners by providing insightful analytics and reservation overviews but also empowers users to manage their bookings and participate in group activities with ease. Through PlayOff, we bridge the gap between sports facilities and enthusiasts, ensuring a more organized and enjoyable sports engagement.

Working on projects for creating mobile, desktop and web applications based onclient demands, while maintaining good architecture, state management and nice userexperience.In order to do that Bloc patter was used as it integrates nicely with Flutter frameworkand enables reactive programming. Built applications communicated with a REST APIin order to collect required data, also some cashing was needed for which local storagewas used. It was very important for all applications to be responsive, work and displaywell for all screen sizes. During development, solutions for navigation, different userinteractions, forms, importing and exporting excel documents, google maps, picturesand many others were implemented.

Working on a project for UDR for 5G network telecommunication. Work was done in a team of many people preforming different tasks at a given time. My role had couple of different tasks, one of them was creating a set of applications for different incoming requests( GET, PUT, PATCH...) for many different sets of data. Furthermore, every application needed to be tested, testing was done in RIDE Robot framework, for every test case in every application. Test cases were determined by looking at possible outcomes of sending a particular request to an application. For example, normal working flow, server errors, timeouts, not finding any data, also data sets had a schema with some regex patterns that had to be followed, so bad requests were also possible. These status codes are wide knows and range from 100 to 500+. Also, these applications ran on machines on servers that ran linux OS, so some linux commands were used while configuring applications on machines.