ItCraft, Aleje Jerozolimskie 181B, Warsaw (2026)

29/05/2026

(Un)obvious Lessons #9 👥

Topic: People First

Many think software development is primarily about technology, tools, and processes.

Krzysztof quickly learned that the real magic happens when you remember that everything revolves around people.

“Software development is a highly technical profession, and it’s easy to forget that. At itCraft, keeping people in mind, both within the team and in client relationships, makes challenges possible to overcome. There’s no problem that can’t be solved if you focus on people.” says Krzysztof.

What does working with people teach you?

🔹 Relationships matter: even the most complex challenges can be solved when everyone is in sync
🔹 Empathy pays off: understanding the team and the client transforms the final outcome
🔹 Collaboration beats individual effort: technology alone cannot carry a project

At itCraft, we know that technology runs the system, but people drive it.

And for you?
What’s more important when working on a project: the technology or the human relationships? 👇

Lekcje (nie)oczywiste #9 👥

Temat: Ludzie przede wszystkim

Wiele osób myśli, że software development to przede wszystkim technologie, narzędzia i procesy.

Krzysztof szybko przekonał się, że prawdziwa magia dzieje się wtedy, gdy pamiętasz, że wszystko kręci się wokół ludzi.

„Software development to bardzo techniczna profesja i łatwo o tym zapomnieć. W itCraft pamiętanie o ludziach zarówno w zespole, jak i w kontakcie z klientem sprawia, że wyzwania stają się możliwe do pokonania. Nie ma problemu, którego nie dałoby się rozwiązać, jeśli skupisz się na ludziach.” – mówi Krzysztof.

Czego uczy praca z ludźmi?

🔹 Relacje mają znaczenie - nawet najbardziej skomplikowane wyzwania można rozwiązać, gdy wszyscy są zgrani.
🔹 Empatia się opłaca - zrozumienie zespołu i klienta zmienia efekt końcowy.
🔹 Współpraca bije indywidualne wysiłki – sama technologia nie udźwignie projektu.

W itCraft wiemy, że technologia napędza system, ale to ludzie go prowadzą.

A dla Ciebie?
Co jest ważniejsze w pracy nad projektem: technologia czy relacje z ludźmi? 👇

25/05/2026

We’ve just wrapped up two intensive days of on-site workshops in Lübeck with one of our international partners.

The trip delivered exactly what we came for: final alignment on the vision for a system designed to configure and calibrate specialised industrial equipment.

Instead of another round of emails, we sat down with the client’s experts and worked through everything together. Over two days, we broke down complex mathematical algorithms, mapped user flows, and translated them into the foundations of an intuitive application.

One of the most valuable parts of the visit was seeing the devices in their real working environment, which gave us an understanding that even the most detailed documentation could never fully provide.

It’s during meetings like these that the connection between technical precision, business context, and everyday user needs becomes especially clear, and why working side by side with the people who use these systems matters so much.

We’re heading back with a refined vision for the next stages, a fresh perspective, and a clear plan for what comes next. It was a great few days that gave us exactly the clarity we needed, and now it’s time to turn those insights into code as we move into intensive work on the backend architecture and web application.

Time to build 🚀

[Polish]

Za nami dwa intensywne dni warsztatów on-site w Lubece z jednym z naszych międzynarodowych partnerów.

Wyjazd przyniósł dokładnie to, po co tam pojechaliśmy: ostateczne dopracowanie wizji systemu do konfiguracji i kalibracji specjalistycznego sprzętu przemysłowego.

Zamiast wymiany maili, usiedliśmy z ekspertami klienta przy jednym stole. Przez dwa dni rozbijaliśmy na czynniki pierwsze skomplikowane algorytmy matematyczne i mapowaliśmy ścieżki użytkowników, żeby przełożyć je na intuicyjną aplikację.

Jednym z momentów, które dały nam najwięcej perspektywy, była wizyta w centrum testowym. Zobaczenie na własne oczy urządzeń w ich rzeczywistym środowisku pracy dało nam zrozumienie, którego nie zastąpi żadna, nawet najlepsza dokumentacja.

To właśnie podczas takich spotkań najlepiej widać, jak ważne jest połączenie technologicznej precyzji z dobrym zrozumieniem biznesu i codziennych potrzeb użytkowników.

Wracamy z dopracowaną wizją kolejnych etapów, nową perspektywą i konkretnym planem działania. To był świetny czas, ale teraz pora przełożyć te wnioski na kod. Przed nami intensywna praca nad architekturą backendową oraz aplikacją webową.
Czas działać!

22/05/2026

(Un)obvious Lessons #8 🛠️

Topic: People, Processes, and LLMs

“Remote work truly works - as long as you have responsible people and smart processes behind it.”

That’s what Aleksandra sees in our day-to-day work at itCraft.

In practice, it comes down to a few simple but powerful principles:

🔹 Scrum helps – but it’s not always enough. For the good of the project, the client, and the team, it sometimes makes sense to combine Agile and Waterfall.
🔹 Tools are our allies. Miro, Slack, or Primetric work best when we use them intentionally – not just by habit.
🔹 AI isn’t magic. Large Language Models help save time, but you need to know how to use them safely.

At itCraft, we’re open to new solutions. We try out new solutions and only keep what actually works. Processes are here to support people, not the other way around.

How about you?
Which tool has recently made your workday easier? 👇

[Polish]

Lekcje (nie)oczywiste #8 🛠️

Temat: Ludzie, procesy i… LLM

„Praca zdalna naprawdę działa, jeśli masz po swojej stronie odpowiedzialnych ludzi i mądre procesy.”

Tak mówi Aleksandra, obserwując codzienną pracę w itCraft.

W praktyce oznacza to kilka prostych, ale potężnych rzeczy:

🔹 Scrum pomaga, ale nie zawsze wystarcza. Dla dobra projektu, klienta i zespołu czasem warto łączyć podejście agile i waterfall
🔹 Narzędzia są naszymi przyjaciółmi: Miro, Slack czy Primetric działają najlepiej wtedy, gdy świadomie z nich korzystamy
🔹 AI nie jest magią: modele językowe pomagają oszczędzać czas i energię, ale wymagają uważności oraz jasno określonych ram bezpieczeństwa.

W itCraft nie boimy się nowych rozwiązań. Testujemy, sprawdzamy i wdrażamy tylko to, co naprawdę działa, bo procesy są dla ludzi, nie odwrotnie.

A Ty?
Które narzędzie ostatnio uratowało Ci dzień w pracy? 👇

15/05/2026

(Un)obvious Lessons #7 🎓

Topic: From Junior to Mentor

Technology moves so fast that even keeping up with the documentation can feel impossible.
Arkadiusz realized is that staying ahead requires courage and initiative.

“It’s worth taking initiative and not being afraid of change. Every challenge, no matter how tough at first, helps you grow and broadens your perspective.”

But growth isn’t just about mastering new frameworks. It’s also about helping others along the way.

What does stepping into a Team Leader role teach you?
🔹 Mentoring juniors builds the company’s potential.
🔹 The opportunity you once received should now be paid forward to empower others.
🔹 A leader is someone who helps others grow, not just the one who knows the most.

At itCraft, change is constant, and helping others navigate it is our greatest strength.

Think back to your first mentor. What was the most valuable lesson they taught you?

[Polish]

Lekcje (nie)oczywiste #7 🎓

Temat: Od juniora do mentora

Technologia zmienia się tak szybko, że trudno nadążyć nawet za dokumentacją.
Arkadiusz przekonał się, że jedynym sposobem, by nadążyć, jest odwaga.

„Warto przejmować inicjatywę i nie bać się zmian. Każda z nich, choć początkowo trudna, rozwija i daje szerszą perspektywę.”

Ale rozwój to nie tylko nowe frameworki. To też podanie ręki innym.

Czego uczy rola Team Leadera?
🔹 Mentorowanie osób bez doświadczenia buduje potencjał firmy
🔹 Szansa, którą sam dostałeś na początku, powinna teraz pracować dla innych
🔹 Liderem jest ten, kto pomaga innym rosnąć, nie tylko ten, kto wie najwięcej

W itCraft zmiana jest stała, a wspieranie innych w niej to nasza największa wartość.

Pamiętasz swojego pierwszego mentora? Co było najcenniejszą lekcją, jaką Ci dał?

13/05/2026

Software as a Medical Device (SaMD) – when does a health app cross the line?

Most healthtech products don’t “become” medical devices overnight.
They simply cross that line sooner than the team expects.

And usually, they realize it when it’s already too late for small fixes.

The real issue?
That line isn’t defined by features.

It’s defined by how regulators interpret your product’s intended use.

A wellness app supports sleep, diet, or general well-being and stays out of diagnostics.
SaMD analyzes data, supports clinical decisions, and can influence treatment.

In practice:

Displaying heart rate during a run? That’s wellness.
Analyzing it to detect arrhythmia and suggesting a doctor’s visit? That’s already a medical device.

Before you move forward, ask yourself:
◼ Could your product be used to make medical decisions, even if that wasn’t the original intent?
◼ Does its output influence how a doctor or patient acts?
◼ Could your messaging be interpreted as supporting diagnosis or treatment?

If the answer to any of these is “yes”, you’re entering MDR territory.

This isn’t something you fix at the end.
It’s a decision that shapes your architecture, development, and go-to-market.

The earlier you recognize it, the fewer painful corrections later.

Because in SaMD, the biggest cost isn’t compliance.
It’s rebuilding a product that’s already in use.

At itCraft, we help teams spot this moment early, before product decisions turn into regulatory ones.

So here’s the question that rarely gets asked upfront:
are you still building a “health app”, or already designing SaMD without realizing it?

[Polish]

Software as a Medical Device (SaMD) - kiedy aplikacja zdrowotna staje się wyrobem medycznym?

Większość produktów healthtech nie „staje się” wyrobem medycznym nagle.
One po prostu… przekraczają tę granicę szybciej, niż zakładał zespół.

I zwykle dowiadują się o tym wtedy, gdy jest już za późno na drobne poprawki.

Największy problem?
To, że ta granica nie wynika z funkcji.

Tylko z tego, jak regulator interpretuje przeznaczenie produktu.

Aplikacja wellness wspiera sen, dietę czy ogólne samopoczucie i nie ingeruje w diagnostykę.
SaMD analizuje dane, wspiera diagnozę i może wpływać na leczenie.

W praktyce:

Pokazujesz tętno podczas biegu? To wellness.
Analizujesz je, wykrywasz arytmię i sugerujesz kontakt z lekarzem? To już wyrób medyczny.

Zanim przejdziesz dalej, odpowiedz sobie szczerze:

◼ Czy Twój produkt może być użyty do podejmowania decyzji medycznych, nawet jeśli nie był tak zaprojektowany?
◼ Czy jego wynik zmienia sposób działania lekarza lub pacjenta?
◼ Czy opis produktu można zinterpretować jako wsparcie diagnozy lub leczenia?

Jeśli choć na jedno z tych pytań odpowiedź brzmi „tak” - wchodzisz w obszar MDR.

I to nie jest kwestia dokumentacji „na końcu”.
To decyzja, która wpływa na architekturę systemu, development i strategię wejścia na rynek.

W praktyce oznacza to coś jeszcze:
im wcześniej to zrozumiesz, tym mniej „bolesnych korekt” później.

Bo w SaMD największym kosztem nie jest zgodność.
Jest nią przebudowa produktu, który już działa.

W itCraft pomagamy zespołom złapać ten moment wcześniej – zanim decyzje produktowe staną się decyzjami regulacyjnymi.

I teraz pytanie, które rzadko pada na początku:
czy Twój produkt jest jeszcze „health app”, czy już nieświadomie projektujesz SaMD?

08/05/2026

(Un)obvious Lessons #6 🚀

The first few weeks of a new project are pure excitement.
Ideas, energy, momentum.

But the real work begins later.

Over the years working in mobile, Agnieszka has seen just how much the market has changed.
Technology has sped up. Expectations are higher.

But the biggest lesson wasn’t about tech itself.

“The most rewarding part is seeing an app grow over many years. When the partnership lasts, and we’re genuinely solving real problems for people,” she says.

A decade of building products teaches you:

🔸 to spot changes before they become problems,
🔸 to care about quality – because it pays off in the years ahead,
🔸 to be patient – good products don’t just happen in a single sprint.

Quick wins give you an adrenaline rush.
Long-term growth gives you purpose.

What about you?
What brings you more satisfaction – the speed, or the staying power?

[Polish]

Lekcje (nie)oczywiste #6 🚀

Pierwsze tygodnie nowego projektu są ekscytujące.
Pomysły, energia, tempo.

Ale prawdziwa praca zaczyna się później.

Agnieszka przez lata pracy przy projektach mobilnych zobaczyła, jak bardzo zmienił się rynek.
Technologia przyspieszyła. Oczekiwania wzrosły.

Ale największa lekcja nie dotyczyła technologii.

„Największą satysfakcję daje moment, gdy aplikacja rozwija się przez wiele lat. Kiedy współpraca jest trwała, a my realnie odpowiadamy na potrzeby klientów”.

Dekada pracy przy produktach uczy:

🔸 reagowania na zmiany, zanim staną się problemem,
🔸 dbania o jakość – bo wraca do Ciebie w kolejnych latach współpracy,
🔸 cierpliwości – bo dobre produkty nie dojrzewają w jeden sprint.

Szybki efekt daje adrenalinę.
Długofalowy rozwój daje sens.

A Ty?
Co daje Ci większą satysfakcję – tempo czy trwałość?

06/05/2026

Technical documentation in MedTech

In medical projects, documentation is not just something you prepare for an audit.

It’s tangible proof that your product is safe and your code can be trusted, especially when certification is on the line.

And yet, many teams still treat it as just “a box to tick” at the very end of the project.
That’s where the problem starts.

Because great documentation doesn’t appear at the finish line.
It grows along the way, as a natural byproduct of a well-structured process.

What should it actually show?

◼ what you are building and why, intended use and clinical context;
◼ how it’s designed, requirements, architecture, key decisions, instructions for use;
◼ how you handle risks, in line with ISO 14971;
◼ whether it works, verification and validation;
◼ whether you’re in control, managing changes, versions, and maintenance;
◼ whether everything connects, traceability across the system.

That last point, traceability, is usually the litmus test of whether a project is truly under control.

In a well-run project aligned with IEC 62304, documentation is not something you “reconstruct” at the end. It grows together with the product.

So when you reach the finish line, you’re not scrambling to catch up.
You’re simply assembling a complete picture of what’s already there.

In MedTech, documentation is not an appendix. It’s proof of organizational maturity.

How does it look in your projects?
A natural outcome of the process, or still a stressful final stage?

[Polish]

Dokumentacja techniczna w MedTechu

W projektach medycznych dokumentacja to nie tylko coś „na audyt”.
To realny dowód, że produkt jest bezpieczny i można mu zaufać, szczególnie jeśli myślisz o certyfikacji.

A jednak wciąż wiele projektów traktuje ją jako coś „na koniec”.

I tu pojawia się problem.

Bo dobra dokumentacja nie powstaje na końcu.
Ona powstaje po drodze, jako naturalny efekt dobrze poukładanego procesu.

Co powinna pokazać?
◼ co budujesz i po co, czyli zamierzone zastosowanie i kontekst kliniczny;
◼ jak to zostało zaprojektowane, wymagania, architektura, decyzje, instrukcje używania;
◼ jak zarządzasz ryzykiem, zgodnie z ISO 14971;
◼ czy to działa, czyli weryfikacja i walidacja;
◼ czy masz nad tym kontrolę, zarządzanie zmianami, wersjami i utrzymaniem;
◼ czy wszystko się ze sobą łączy, czyli identyfikowalność (traceability).

To właśnie ten ostatni element najczęściej pokazuje, czy projekt jest naprawdę pod kontrolą.

W dobrze prowadzonym projekcie, zgodnym z IEC 62304, dokumentacja nie powstaje „na koniec”.
Ona rośnie razem z produktem.

I dzięki temu na końcu niczego nie nadrabiasz, tylko składasz spójny obraz tego, co już masz.

Bo w MedTechu dokumentacja to nie załącznik.
To dowód dojrzałości organizacji.

A u Ciebie jak to wygląda?
Proces czy nadal „etap na końcu”?

30/04/2026

Majówka w IT? Każdy ma swój tryb 😄
Od „jeszcze tylko jeden mail” po pełny offline.

👉 Sprawdź, który jest Twój i daj znać w komentarzu: A, B, C czy D?

EN:
Long weekend in tech? Everyone has their own mode 😄
From “just one more email” to full offline.

👉 Check which one is yours and let us know in the comments: A, B, C or D?

A quick guide 👇
A - Digital Nomad (laptop everywhere)
B - Hard Reset (fully offline)
C - Smart Home Master (tech does the work)
D - The Refactorer (side project time)

24/04/2026

(Un)obvious Lessons #5 ✨

Topic: Humility over Infallibility

In recruitment, it’s easy to fall into the trap of thinking you always know what others are thinking and that you’re always right

At itCraft, Katsiaryna discovered that relaxing a bit and leaving her ego aside made all the difference.

“Working here taught me humility and how to truly appreciate the efforts of others. It helped me let go of the need to be right all the time.”

But humility isn’t a weakness – it’s the ability to keep learning from those around you

What does a culture of respect and support teach us.

🔹 Owning your mistakes without the fear of being judged.
🔹 Listening with curiosity, not just waiting for your turn to respond.
🔹 A relaxed mindset that helps build deeper, more lasting professional relationships.

We often learn the most when we admit we don’t have all the answers. Suddenly, work feels easier and the team grows stronger.

What about you? Have you ever admitted a mistake publicly at work? How did your team react?

[Polish]

Lekcje (nie)oczywiste #5 ✨

Temat: Pokora zamiast nieomylności

W rekrutacji łatwo uwierzyć, że zawsze się wie, co myślą inni i że zawsze ma się rację.

Katsiaryna w itCraft nauczyła się czegoś innego - większego luzu i zostawienia własnego ego w tyle.

„Praca tutaj nauczyła mnie pokory i doceniania wysiłku innych. Pozwoliła mi porzucić przekonanie o własnej nieomylności.”

Ale pokora to nie słabość, to umiejętność uczenia się od innych.

Czego uczy atmosfera oparta na szacunku?

🔹 Przyznawanie się do błędów bez strachu przed oceną.
🔹 Słuchanie z ciekawością, nie tylko po to, by odpowiedzieć.
🔹 Luz w podejściu pomaga budować lepsze i trwalsze relacje.

Najwięcej uczymy się wtedy, gdy przestajemy udawać, że wiemy wszystko. I nagle praca staje się łatwiejsza, a zespół mocniejszy.

A Tobie zdarzyło się kiedyś przyznać publicznie do błędu w pracy? Jak zareagował Twój zespół?

17/04/2026

(Un)obvious Lessons #4 🤖

Topic: AI and tools that accelerate your workflow

AI is everywhere, but the right tools are what truly make a difference.
While analyzing new features for a client, Patryk discovered how AI can help generate user journey maps. The real game-changer, however, turned out to be Mermaid, a tool that turns simple, structured text into clear, usable diagrams.

“AI gives you a great head start, but your choice of tools determines how quickly you can turn ideas into functional diagrams. Leading platforms like Miro or FigJam don’t fully support this workflow yet, even though it would drastically speed things up,” says Patryk.

What can we learn from using tools wisely?

◼Synergy is key: Combine AI with the right specialized tools to save time and reduce errors.
◼Human in the loop: Automation provides the foundation, but the human expert still drives the process.
◼Small tweaks, big impact: Minor workflow improvements can create massive gains in overall efficiency.

At itCraft, we constantly test tools that let us work faster and smarter. Innovation isn’t just about the technology itself; it’s about how thoughtfully you apply it.

How about you? What AI-tool combos have you discovered recently that leveled up your workflow?

[Polish]

Lekcje (nie)oczywiste #4 🤖

Temat: AI i narzędzia, które przyspieszają pracę

AI jest wszędzie, ale odpowiednie narzędzia robią prawdziwą różnicę.
Przy analizie nowych funkcjonalności dla klienta, Patryk odkrył, jak AI może pomóc w generowaniu map user journey. Prawdziwym odkryciem okazało się jednak Mermaid - narzędzie, które przekształca tekst w diagramy przy użyciu prostej składni.

„AI może dać świetny start, ale to narzędzia decydują o tym, jak szybko przekształcisz pomysły w użyteczne diagramy. Czołowe narzędzia, jak Miro, FigJam czy Flowchart Makers, jeszcze nie w pełni to wspierają, a mogłoby mocno przyspieszyć pracę” - mówi Patryk.

Czego uczy mądre korzystanie z narzędzi?

◼ Łącz AI z odpowiednimi narzędziami, by oszczędzać czas i unikać błędów.
◼ Automatyzacja pomaga, ale to człowiek kieruje procesem.
◼ Małe usprawnienia mogą mieć wielki wpływ na efektywność.

W itCraft testujemy narzędzia, które pozwalają pracować szybciej i mądrzej, bo innowacja to nie tylko technologia, ale też jej rozsądne wykorzystanie.

A Ty? Jak używasz AI i narzędzi, by przyspieszyć swoją pracę?

ItCraft

29/05/2026

25/05/2026

22/05/2026

15/05/2026

13/05/2026

08/05/2026

06/05/2026

30/04/2026

24/04/2026

17/04/2026

Adres

Strona Internetowa

Ostrzeżenia

Skróty

Udostępnij

Kategoria