itCraft

Pizza Day in Bydgoszcz. But… where’s the pizza? Last Friday, we got together at itCraft’s Bydgoszcz office for another Pizza Day. We organize these team get-togethers once a quarter. The name, however, seems to have taken on a life of its own, because this time, instead of pizza, we had… sushi and pancakes. Because really, how much pizza can you eat?! 😂 What matters most is that we got to meet in person again. Most of us work remotely on a daily basis, so occasions like this are a great excuse to swap chats and video calls for a shared table, good conversations and plenty of laughs. And as it turned out, we had even more reasons to celebrate. We also marked some work anniversaries – 5 and 10 years at itCraft. 🎉 So, to sum it up: sushi – check pancakes – check pizza – nope work anniversaries – check good vibes – absolutely And that’s probably what Pizza Day is really about. The name can stay. The menu can change. What matters most is getting people together. [Polski] Pizza Day w Bydgoszczy. Tylko… gdzie jest pizza? W miniony piątek spotkaliśmy się w bydgoskim biurze itCraft na kolejnym Pizza Day. Spotkania integracyjne organizujemy raz na kwartał. Nazwa jednak najwyraźniej żyje własnym życiem, bo tym razem zamiast pizzy były… sushi i naleśniki. No bo ile można jeść pizzę?! 😂 Najważniejsze jednak, że znów mogliśmy spotkać się na żywo. Na co dzień w większości pracujemy zdalnie, więc takie okazje są dobrym pretekstem, żeby na chwilę zamienić komunikatory na wspólny stół, rozmowę i trochę śmiechu. A że powodów do świętowania było więcej, przy okazji uczciliśmy też pracownicze jubileusze – 5 i 10 lat w itCraft. 🎉 Czyli podsumowując: sushi – było naleśniki – były pizza – nie było jubileusze – były dobra atmosfera – zdecydowanie była Właśnie o to chodzi w naszym Pizza Day. Nazwa może zostać. Menu może się zmieniać. Najważniejsze, żeby ludzie byli razem. #itCraft #PizzaDay #TeamitCraft #LifeAtitCraft #TeamCulture #EmployeeAnniversary #Bydgoszcz #RemoteWork #TeamBuilding

Meet the newest members of the itCraft team. 🐶🐱🏍️ They don’t have email addresses, they don’t join daily stand-ups, and they probably have no idea how Jira works. But they’re really good at one very important thing: getting us away from our computers. 😎 As part of our Alternative Intelligence Assistant contest, we collected photos of our non-digital specialists. We’ve got dog specialists in taking us for walks, cat consultants in enforcing breaks, plush experts in mood improvement, and even… bicycles and motorcycles, apparently the mobile departments of regeneration. Everyone has their own specialty. Some make sure a break is actually a break. Others remind us that fresh air exists. And some simply wait patiently for us to finish work. 😉 It’s Friday… and their shift is just getting started. For the next two days, they’re taking over. How do you take care of your wellbeing? Have a great weekend! ❤️ #itCraft #LifeAtitCraft #AlternativeIntelligence #ProgrammersDay [Polski] Poznajcie nowych członków zespołu itCraft. 🐶🐱🏍️ Nie mają maili, nie chodzą na daily i raczej nie ogarniają Jiry. Za to świetnie radzą sobie z jednym bardzo ważnym zadaniem: wyciąganiem nas od komputera. 😎 W ramach naszego konkursu na Asystenta Alternative Intelligence zebraliśmy zdjęcia naszych niecyfrowych specjalistów. Pojawili się m.in. psi specjaliści od spacerów, koci konsultanci od przerw, pluszowi eksperci od poprawy nastroju, a także… rowery i motocykle, czyli mobilne działy ds. regeneracji. Każdy ma swoją specjalizację. Jedni pilnują, żeby przerwa rzeczywiście była przerwą. Inni przypominają, że świeże powietrze istnieje. Jeszcze inni po prostu czekają, aż skończymy pracę. 😉 Jest piątek… ich zmiana właśnie się zaczyna. Przez najbliższe dwa dni to oni przejmują dowodzenie. A Wy jak dbacie o swój dobrostan?   Miłego weekendu! ❤️ #itCraft #LifeAtitCraft #AlternativeIntelligence #DzieńProgramisty

CRA: first requirements now apply The Cyber Resilience Act has now become a practical topic for manufacturers of products with digital elements. Since 11 September 2026, the first CRA requirements have applied to reporting actively exploited vulnerabilities and serious incidents affecting product security. And timing matters: 🔔 24 hours for an early warning 🔔 72 hours for a fuller notification This does not mean that every company developing software automatically becomes a “manufacturer” under the CRA. First, it is necessary to determine whether a specific product falls within the scope of the regulation and what role the organisation plays. The CRA covers much more than reporting. It also requires cybersecurity to be considered throughout product design and development, as well as vulnerability management, security updates, documentation and support periods. The main requirements will apply from 11 December 2027. It is therefore worth looking at your product and development processes now. At itCraft, we have been considering cybersecurity from the design stage for a long time. Security by Design does not start when a vulnerability appears. It should be part of the product from the beginning. [Polski] CRA: pierwsze obowiązki już obowiązują Cyber Resilience Act właśnie stał się praktycznym tematem dla producentów produktów cyfrowych. Od 11 września 2026 r. obowiązują pierwsze wymagania CRA dotyczące raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. I tutaj znaczenie ma czas: 🔔 24 godziny na wczesne ostrzeżenie 🔔 72 godziny na pełniejsze zgłoszenie Nie każda firma tworząca oprogramowanie automatycznie staje się „producentem” w rozumieniu CRA. Najpierw trzeba ustalić, czy konkretny produkt podlega regulacji i jaką rolę pełni organizacja. CRA obejmuje więcej niż samo raportowanie. Dotyczy także cyberbezpieczeństwa na etapie projektowania i rozwoju produktu, zarządzania podatnościami, aktualizacji bezpieczeństwa, dokumentacji i okresu wsparcia. Zasadnicza część wymagań zacznie być stosowana od 11 grudnia 2027 r. Warto więc już teraz przyjrzeć się własnemu produktowi i procesowi jego tworzenia. W itCraft od dawna uwzględniamy cyberbezpieczeństwo już na etapie projektowania. Security by Design nie zaczyna się wtedy, gdy pojawia się podatność. Powinno być częścią produktu od początku. #itCraft #CyberResilienceAct #CRA #Cybersecurity #SecurityByDesign #SoftwareDevelopment

Why does a good technology partner think about security before the first line of code is written? In a healthcare project, security doesn’t begin with testing a finished application. It starts much earlier, even during the first conversation about how the product should work. Imagine an app where a patient books an appointment, a doctor receives the information they need, and the system exchanges data with other services. Even at this stage, you need to define who should have access to specific data, how users will verify their identity, what patients can see, what should only be available to healthcare professionals, and which systems the product will connect with. These aren’t questions to leave until the end of development. In one of our projects, Mobil@Doktorn, developed for the Swedish market, security was part of the solution from the very beginning. The platform connected patients and doctors, supported home visits and processed sensitive data. It included, among other things, secure authentication using BankID and a carefully designed database. The same approach is important even when a product is not a medical device. That’s why at itCraft, security is part of the conversation about the product, not a stage added at the end. We start by understanding the product, its users, the data involved and how it flows through the system. Only then do we design the solution. Security in a good healthcare product should be part of the decisions made from the very beginning. [Polski] Dlaczego dobry partner myśli o bezpieczeństwie, zanim powstanie pierwsza linia kodu? W projekcie healthcare bezpieczeństwo nie zaczyna się od testów gotowej aplikacji. Dużo wcześniej, już podczas rozmowy o tym, jak produkt ma działać. Wyobraźmy sobie aplikację, w której pacjent umawia wizytę, lekarz otrzymuje potrzebne informacje, a system wymienia dane z innymi usługami. Już wtedy trzeba ustalić: kto ma dostęp do danych, jak użytkownicy potwierdzają swoją tożsamość, co widzi pacjent, co personel medyczny i z jakimi systemami produkt będzie się łączył. To nie są pytania na koniec developmentu. W projekcie Mobil@Doktorn, realizowanym na rynek szwedzki, bezpieczeństwo było częścią projektowania od początku. Platforma łączyła pacjentów i lekarzy, obsługiwała wizyty domowe i przetwarzała wrażliwe dane. Wykorzystano m.in. bezpieczne uwierzytelnianie z użyciem BankID. Dlatego w itCraft bezpieczeństwo jest częścią rozmowy o produkcie, a nie etapem dodawanym na końcu. Najpierw poznajemy produkt, użytkowników, dane i ich przepływy. Dopiero na tej podstawie projektujemy rozwiązanie. Bezpieczeństwo dobrego produktu healthcare powinno być obecne w decyzjach podejmowanych od samego początku #itcraft #healthcare #digitalhealth #medtech #medicalsoftware #softwaredevelopment #cybersecurity #datasecurity #ISO13485 #ISO27001

Who ensures compliance while you focus on developing your product? When a new medical product is being developed, conversations usually revolve around users, features, and the problems the product is meant to solve. That's natural. But it's also the right time to consider regulatory requirements, because many design decisions made early on will have an impact later in the product lifecycle. The manufacturer is responsible for the medical device and its compliance with applicable regulations. A technology partner's role is to take care of the technical side: the software development process, implementation of requirements, and technical solutions that support compliance. At itCraft, this starts with our Product Discovery workshops. We don't overwhelm our clients with standards and regulations. Instead, we help ensure that design and development decisions align with the requirements applicable to a given product. This is how we work on solutions for medical device manufacturers as well as digital products that support patients and healthcare professionals. In healthcare, compliance is a shared responsibility. The manufacturer is responsible for the product, while the technology partner ensures that the technical side is developed in line with industry best practices and applicable requirements. [Polski] Kto pilnuje zgodności, kiedy Ty rozwijasz produkt? Gdy powstaje nowy produkt medyczny, rozmowy najczęściej dotyczą użytkowników, funkcjonalności i problemów, które ma rozwiązać. To naturalne, ale już na tym etapie warto uwzględnić wymagania regulacyjne, bo wiele decyzji projektowych będzie miało znaczenie w kolejnych etapach rozwoju produktu. Producent odpowiada za swój wyrób i jego zgodność z obowiązującymi wymaganiami. Rolą partnera technologicznego jest zadbać o obszar techniczny proces wytwarzania oprogramowania, implementację wymagań i rozwiązania wspierające zgodność produktu. W itCraft robimy to od pierwszych warsztatów Product Discovery. Nie zasypujemy klientów nazwami norm. Dbamy o to, by decyzje projektowe wspierały wymagania, które mają zastosowanie do danego produktu. Tak pracujemy przy rozwiązaniach dla producentów urządzeń medycznych oraz cyfrowych produktach wspierających pacjentów i personel medyczny. W healthcare zgodność to efekt współpracy. Producent odpowiada za produkt, a partner technologiczny daje pewność, że obszar techniczny jest rozwijany zgodnie z dobrymi praktykami i obowiązującymi wymaganiami. #itcraft #healthcare #digitalhealth #medtech #softwaredevelopment #productdevelopment #medicalsoftware #MDR #ISO13485

Appointment booking, telemedicine, patient monitoring. Why don’t we start with features? Many projects start with a similar idea: “We want to build an app for patients.” It quickly becomes clear, however, that the same description can involve very different needs. Should the app allow patients to book appointments? Support online consultations? Or collect health data and present it to healthcare professionals? Each of these products has a different purpose, users, priorities and requirements. This includes user experience, data security, integrations and regulatory considerations. In the healthcare projects we deliver, the same approach rarely works for every case. Sometimes, secure data exchange between users and systems is key. In other projects, the entire architecture is built around integration with medical devices. That’s why we don’t start our initial conversations with a list of features. First, we want to understand the problem we are solving together. Only then do we define the required features, data, integrations, security measures, and any regulatory or certification requirements. This approach applies whether we are building an appointment booking system, a telemedicine platform or a more advanced digital health solution. Because in healthcare, good products don’t start with features. They start with the right questions. [Polski] Rejestracja wizyt, telemedycyna, monitoring pacjentów. Dlaczego nie zaczynamy od funkcji? Na początku wiele projektów brzmi podobnie: „Chcemy stworzyć aplikację dla pacjentów”. Szybko okazuje się jednak, że pod tym samym hasłem mogą kryć się zupełnie różne potrzeby. Czy aplikacja ma umożliwiać umawianie wizyt? Wspierać konsultacje online? A może zbierać dane o stanie zdrowia i prezentować je personelowi medycznemu? Każdy z tych produktów ma inny cel, użytkowników, priorytety i wymagania. Dotyczy to m.in. doświadczenia użytkownika, bezpieczeństwa danych, integracji czy kwestii regulacyjnych. W projektach healthcare, które realizujemy, rzadko sprawdza się ten sam schemat. Czasem kluczowe jest bezpieczne przekazywanie danych między użytkownikami i systemami. Innym razem cała architektura rozwiązania podporządkowana jest integracji z urządzeniami medycznymi. Dlatego podczas pierwszych rozmów nie zaczynamy od listy funkcji. Najpierw chcemy zrozumieć, jaki problem mamy wspólnie rozwiązać. Dopiero wtedy określamy potrzebne funkcje, dane, integracje, sposób zapewnienia bezpieczeństwa oraz ewentualne wymagania regulacyjne i certyfikacyjne. To podejście sprawdza się zarówno przy systemie rejestracji wizyt, platformie telemedycznej, jak i bardziej zaawansowanym rozwiązaniu digital health. Bo w healthcare dobre produkty nie zaczynają się od funkcji. Zaczynają się od właściwie postawionych pytań. #itCraft #HealthcareIT #DigitalHealth #HealthTech #HealthcareSoftware #Telemedicine #MedicalSoftware

„Will our app be classified as a medical device?” This is one of the questions we hear surprisingly often from our clients. And more often than not, the answer isn't as straightforward as they expect. Many people assume that if an app is developed for the healthcare sector, it automatically falls under the Medical Device Regulation (MDR). In reality, its classification isn't determined by who uses it, but by its intended purpose, the data it processes, and the impact it may have on patient health. If an app analyses medical data, generates recommendations, supports diagnosis or treatment, or contributes to clinical decision-making, it may be classified as a medical device. If it's designed for appointment scheduling, patient communication, healthcare administration, or other operational workflows, it will often fall outside the scope of MDR. That's why it's important to define the product's intended purpose early, while its features and requirements are still being shaped. It helps teams design the right solution from the outset and avoid costly changes later in the development process. At itCraft, we've been developing digital healthcare solutions for years in line with internationally recognized quality and security standards, backed by ISO 13485, ISO 27001, and ISO 9001 certifications. That's why regulatory requirements are part of every project from the very beginning. Because compliance starts at the design stage. [Polish] „Czy Nasza aplikacja będzie wyrobem medycznym?” Wśród Klientów to pytanie pojawia się zaskakująco często i równie często odpowiedź nie jest taka oczywista. W praktyce wiele osób zakłada, że skoro aplikacja powstaje dla branży healthcare, automatycznie podlega przepisom MDR. Tymczasem o jej kwalifikacji nie decyduje grupa użytkowników, ale cel w jakim została zaprojektowana i jakie dane przetwarza i w jaki sposób może wpływać na zdrowie pacjenta. Jeśli aplikacja analizuje dane medyczne, generuje rekomendację, wspiera diagnozę, leczenie lub decyzje kliniczne, może zostać uznana za wyrób medyczny. Jeśli służy np. do umawiania wizyt, komunikacji z pacjentem, zarządzania placówką lub obsługi procesów administracyjnych, często nie będzie podlegać tym regulacjom. Dlatego już na etapie definiowania funkcji i specyfikacji produktu warto określić jego zamierzone przeznaczenie. Pozwala to od początku zaprojektować rozwiązanie zgodnie z właściwymi wymaganiami i uniknąć kosztownych zmian. W itCraft od lat rozwijamy rozwiązania dla sektora healthcare zgodnie z wymaganiami jakości i bezpieczeństwa potwierdzonymi certyfikatami ISO 13485, ISO 27001 oraz ISO 9001. O regulacjach rozmawiamy od samego początku współpracy. Bo zgodność z przepisami zaczyna się na etapie projektowania. #Healthcare #DigitalHealth #MedTech #MedicalDevices #MDR #HealthTech #SoftwareDevelopment #itCraft

Great partnerships don't end with product delivery. Sometimes, they mean showing up where your client is. Our Head of Discovery & Growth, Rafał Ratajski, joined the RideCraft team at the Exhibition Milton Keynes 2026 Show to support the launch of the SaaS platform we've been building together. It was two intensive days of meeting visitors, generating valuable leads and, just as importantly, listening to the market. Conversations like these provide invaluable feedback. It helps us continuously improve the product and respond more effectively to real market needs. The best products are built close to their users. That's why we're proud to have been part of this process, supporting RideCraft not only during development, but also throughout the product launch. A big thank you to RideCraft and Grzegorz Wosicki for the trust and the invitation. We look forward to many more opportunities to build great products together. [Polish] Dobra współpraca nie kończy się na dostarczeniu produktu. Czasem oznacza też bycie tam, gdzie jest klient. Nasz Head of Discovery & Growth, Rafał Ratajski, dołączył do zespołu RideCraft podczas Exhibition Milton Keynes 2026 Show, wspierając premierę aplikacji SaaS, którą wspólnie rozwijamy. To były dwa intensywne dni rozmów z odwiedzającymi, zbierania wartościowych leadów i co równie ważne, słuchania rynku. Takie spotkania dostarczają bezcennego feedbacku, który pomaga lepiej rozwijać produkt i jeszcze trafniej odpowiadać na realne potrzeby rynku. Najlepsze produkty powstają blisko użytkowników. Dlatego cieszymy się, że mogliśmy być w samym centrum tego procesu i wspierać RideCraft również poza etapem developmentu. Dziękujemy RideCraft oraz Grzegorzowi Wosickiemu za zaufanie i zaproszenie. #itCraft #ProductDiscovery #SaaS #DigitalProducts #ClientPartnership #PHTM2026 #DispatchSystem https://lnkd.in/dJ6fhjUp

(Un)obvious Lessons #11 🧭 Topic: The most (un)obvious lesson of all We wanted to talk about the things you don’t see in a backlog. We set out looking for unobvious truths about IT, but the most important one turned out to be this:  ❗ The most important lessons are actually human ones. Technology was there in the background of every story, but the real drivers turned out to be:  • humility and courage: to admit we don’t have all the answers; • trust and patience: needed to build products that last for years; • empathy: without which real collaboration just doesn't happen. We discovered something else too: the biggest bottleneck in IT is rarely technology. Much more often, it’s the belief that we already know the right answer. True professionalism begins where the need to be right ends. That’s when we listen to users instead of our own egos, and test solutions instead of assuming we’ve already figured it all out. And that’s exactly when the best products are born. In a world of AI and increasingly complex systems, the most valuable skill remains the ability to listen, learn, and collaborate. That’s why we return to the quote from Lesson #0: 💬 “We learn the most when we stop pretending we know everything.” Thank you for following along with us! What about you? Is there a lesson your work has taught you that never quite made it into a backlog? Let us know in the comments! #UnobviousLessons #itCraft #SoftwareDevelopment #WorkCulture #Teamwork [Polish] Lekcje (nie)oczywiste #11 🧭 Temat: Najbardziej (nie)oczywista lekcja Chcieliśmy rozmawiać o tym, czego nie widać w backlogu. Szukaliśmy nieoczywistych prawd o IT, ale najważniejsza okazała się jedna: ❗ Najważniejsze lekcje są zaskakująco ludzkie. Technologia była w tle każdej historii, ale jej prawdziwymi bohaterami okazały się:  • pokora i odwaga - by przyznać, że nie zna się wszystkich odpowiedzi; • zaufanie i cierpliwość - potrzebne do budowania produktów na lata; • empatia - bez której nie ma prawdziwej współpracy. Odkryliśmy coś jeszcze: największym ograniczeniem w IT rzadko jest technologia. Znacznie częściej to przekonanie, że już znamy właściwą odpowiedź. Największy profesjonalizm zaczyna się tam, gdzie kończy się potrzeba udowadniania swojej racji. To wtedy słuchamy użytkowników zamiast własnego ego i testujemy rozwiązania zamiast zakładać, że już znamy odpowiedź. I to wtedy właśnie powstają najlepsze produkty. W świecie AI i coraz bardziej złożonych systemów najcenniejszą kompetencją wciąż pozostaje umiejętność słuchania, uczenia się i współpracy. Dlatego wracamy do cytatu z Lekcji #0: 💬„Najwięcej uczymy się wtedy, gdy przestajemy udawać, że wiemy wszystko.” Dziękujemy, że byliście z nami! A jakiej lekcji nauczyła Was praca, choć nikt nie wpisał jej do backlogu? Napiszcie w komentarzu! #LekcjeNieoczywiste #itCraft #SoftwareDevelopment #WorkCulture #Teamwork

We’ve just wrapped up another intensive Discovery workshop for a HealthTech project tailored for the Belgian medical market. Our goal was to align the vision for a system designed to bring genuine relief to independent community nurses in their daily routines. We started by tackling one of the biggest challenges in modern healthcare: the overwhelming administrative burden and bureaucracy. It’s an issue that drives burnout and strips professionals of the time they should be spending on what matters most, which is face-to-face patient care. During the workshops, we turned these challenges into concrete tech solutions, focusing on streamlining daily workflows and sharpening the product’s overall direction. As a result, we’ve built a solid foundation for the next phases and mapped out a clear roadmap. The final product will boost operational efficiency, cut down on paperwork, and give healthcare workers their time back. Now, we’re bringing that same energy into the UX/UI design phase, with development right around the corner. Because that’s when technology makes the most sense: when it blends into the background and lets people focus on what truly matters. Time to get to work! 🚀 Thank you, Thomas De Paep for your engagement and collaboration during the Discovery phase. We're now moving into the next stages of design and development. [Polish] Za nami kolejne intensywne warsztaty Discovery dla projektu z sektora HealthTech, projektowanym z myślą o belgijskim rynku medycznym. Naszym wspólnym celem było uporządkowanie wizji systemu, który ma realnie odciążyć niezależne pielęgniarki i pielęgniarzy środowiskowych w ich codziennej pracy. Punktem wyjścia było jedno z największych wyzwań współczesnej opieki zdrowotnej: rosnące obciążenie administracyjne i biurokracja, które wywołują wypalenie zawodowe i odbierają specjalistom czas na to, co najważniejsze - bezpośredni kontakt z pacjentem. Podczas warsztatów przełożyliśmy ten problem na konkretne rozwiązania technologiczne, koncentrując się na usprawnieniu codziennych procesów i dopracowaniu kierunku rozwoju całego produktu. W efekcie precyzyjnie zdefiniowaliśmy fundament pod kolejne etapy projektu i stworzyliśmy jasną mapę rozwoju produktu, który ma zwiększyć efektywność operacyjną, ograniczyć administracyjne obciążenie i oddać personelowi medycznemu czas na to, co w tej profesji najważniejsze. Teraz z tą samą energią przechodzimy do fazy projektowania UX/UI, a zaraz po niej – startujemy z developmentem. Bo właśnie wtedy technologia ma największy sens: gdy znika w tle i pozwala ludziom skupić się na tym, co naprawdę ważne. Czas działać! 🚀 Dziękujemy Thomas De Paep za zaangażowanie i współpracę podczas fazy Discovery. Przed nami kolejne etapy projektowania i developmentu. #itCraft #SoftwareHouse #HealthTech #ProductDiscovery #BusinessWorkshops #MobileApp #UXUI #DigitalHealth #PracaWRealu