How did Solvro and Wrocław Tech turn "unofficial" software into a responsible collaboration?

In mid-April 2026, we had the pleasure of participating in iCHTS (International Conference on Human Technology and Society) as speakers and also as a Craft conference partner. Dawid Linek presented a case study titled "Shadow IT as an Innovation Engine", which tells the story of our club: from a garage project created outside the official university channels to jointly developing a formal cooperation model with Wrocław Tech. This is a good opportunity to tell this story more broadly.

 

Who are we? A short history of KN Solvro

KN Solvro was established in 2018 as a small Science Club bringing together students from Wrocław Tech with a common ambition: to solve real, everyday problems using technology. Why this name? Solvro - from the English to solve. Simple, yet apt.

In the early years, we operated modestly: a dozen people, a few projects, plenty of enthusiasm, and not necessarily much experience. We created applications from the ground up, guided by the principle of "by students for students"—because no one knows better what is missing at their university than a student. Interactive campus map, cafeteria menu on the phone, real-time tracking of free parking spots, scheduling planners, advanced event management systems for other student organizations—these are just some of the things that came from our hands.

The real breakthrough came in 2024. Solvro began to develop dynamically, both in terms of the number of members and the scale of projects undertaken. Today, we are an organization with nearly 160 active members, operating at the intersection of software engineering, artificial intelligence, and community building, and our applications reach thousands of users across the university. But this path wasn't without challenges, as we encountered what the corporate world knows well as Shadow IT.

What is Shadow IT and why does it concern us?

Shadow IT is a term from the scientific literature that describes IT systems, processes, and tools created outside the knowledge and control of an organization's official IT department. The classic definition by Rentrop and Zimmermann (2012) states:

"Shadow IT describes the supplement of 'official' IT by several, autonomous developed IT systems, processes and organizational units, which are located in the business departments. These systems are generally not known, accepted and supported by the official IT department."

In companies, Shadow IT arises when employees encounter a problem for which the central IT department has no time, resources, or priority. Instead of waiting, they create their own tools, such as spreadsheets, scripts, small applications, which work but exist outside any supervision. The mechanism is exactly the same in universities.

In our case, we were building applications used by thousands of students and staff at Wrocław Tech, integrating with university data systems, storing personal data, all in the shadows.

 

Pros of Shadow IT

Shadow IT has its real advantages, which is why it is so common both in companies and universities:

Drives innovation and creativity. When a small, agile team of students can create an application over the weekend that thousands of people start using on Monday (as we did with Testownik), that's the bottom-up energy that large organizations often simply lack.

Increases agility and speed of operation. Official IT projects in large institutions take months. We were able to deliver a working solution within a few weeks because we were not constrained by tender bureaucracy or long decision cycles.

Is closely tailored to users' needs. No one knows a student's needs better than another student. Our applications were designed by people who used them themselves—hence their high adoption rate.

Delivers real results. Each of our applications solved a specific, felt problem: a lack of transparency in the catering offer, difficult access to the campus map, chaotic event management. Users appreciated this.

Cons of Shadow IT

But every coin has two sides. And when our projects started to grow, we encountered the darker side of informality:

Security risk and compliance. When an application begins processing personal data—names, email addresses, student ID numbers—it falls under GDPR. We learned coding "on live organisms", which quickly leads to instability and production errors.

Problems with engineering quality. Enthusiasm doesn't replace experience. Code written by students learning the craft can be inconsistent, poorly documented, and difficult to maintain.

Risk of continuity of operation. This was one of the university's biggest fears: what happens to an application used by thousands when its creator finishes their studies and leaves for work? Without a succession plan, documentation, and backups, the application simply dies along with the graduate.

Problems with intellectual property. When 20 students collectively build an application over two years and then graduate—who owns the code? Do the rights belong to the university, the science club, or each programmer individually? These questions, without formal arrangements, remain in a dangerous gray area.

 

Application Release Procedure - Framework of Responsible Co-creation

Two years of intensive dialogue between KN Solvro and the IT Department, Information Security Office, Promotion Department, Legal Department, Intellectual Property Protection Department, Faculty of Computer Science and Telecommunications, and other university units have produced a specific result: on April 2, 2026, Wrocław Tech officially published the "Procedure for releasing applications for users of Wrocław Tech". This document changes the rules of the game not only for us but for all science clubs and software creators operating within the university ecosystem.

The procedure is not a bureaucratic barrier, but a roadmap for responsible implementation. During our conference presentation, we presented it as a framework consisting of 5 pillars and 10 specific steps, guiding an application creator from idea to production in a safe, transparent, and lawful manner.

Pillar 1 - Formalized Onboarding & Ownership

Clear rules from day one
The administration brings our development out from the shadows. Instead of operating blindly, the application creator formally presents their project to the university and immediately addresses issues that were previously the source of the biggest problems.

Step 1. Submission of application. Every implementation starts with a formal application to the IT Department (ITD). The application must include the name and description of the application, a list of planned users, a description of key functionalities, information about the architecture and technologies used, required integrations with university systems (e.g., USOS API, SSO). Especially important for science clubs is the requirement to define the status of copyrights and the scope of the license granted to the university—no more ambiguity about who owns the application after studies are completed.

Step 2. Preliminary analysis and test planning. ITD verifies whether the application does not duplicate existing university systems, initially assesses risk, and determines required tests and documentation. This stage ends with the Director of ITD's recommendation—positive or negative. A positive recommendation is the pass to the next steps.

Pillar 2 - Institutional Guardrails

Security and compliance as a foundation, not an obstacle
Rather than leaving the creator alone with legal and technical requirements, the university builds specific requirements, and the student must prove that their application meets them.

Step 3. Risk analysis. The application creator conducts a full risk analysis: identifies processed resources (student databases, class schedules, etc.), indicates potential threats (unauthorized access, data leakage, DoS attack), assesses vulnerabilities, and estimates the probability and impact of each threat. Based on this, they choose a strategy: mitigation (implementing security measures), acceptance (consciously accepting the risk), or avoidance (refraining from risky functionality). Applications processing personal data additionally require consultation with the Information Security Office.

Step 4. Access policies. The application must have precisely defined user roles—administrator, student, staff—and clearly defined actions, each of which can perform. The access policy must be consistent with university regulations and consider GDPR requirements regarding data processing authorizations.

Step 7. Application regulations. Applications available to a wide audience or processing personal data must have regulations written in simple, understandable language. The regulations define access rules, rights and responsibilities of users and administrators, data processing rules in accordance with GDPR, and if the application uses AI—also compliance with the EU AI Act.

Pillar 3 - Safe-to-Connect Infrastructure

Official API instead of makeshift workarounds. Instead of forcing students to build around university systems, the IT Department provides standard, secure integration points. We connect to the university ecosystem officially and safely.

Step 5. Integrations. The application creator defines formal points of contact with other systems—USOS, university email, Active Directory, TETA system. For each integration, they specify the communication protocol, data format, security rules, and error handling procedures. After implementation, ITD may decide to connect the application to the university monitoring system Zabbix or the OTOBO ticket system.

Pillar 4 - Resilience & Continuity

The application must outlive its creator. This was one of the university's biggest concerns about Shadow IT: a student finishes studies, goes to work, and the application, used by thousands, simply stops working. This pillar directly addresses this issue.

Step 6. Business continuity plan. Each application must have a documented continuity plan covering BIA criticality classification (low/medium/high), recovery parameters—RTO (maximum downtime) and RPO (maximum allowable data loss)—backup and archiving strategy with specified frequency and storage location, Disaster Recovery plan, and clearly defined roles and responsibilities on the creator's side. This way, the application doesn't die with its author's diploma.

Pillar 5 - Collaborative Quality Assurance

Approving an application for production is not a single "stamp" from the IT department. It's a joint responsibility of many units, which view the application from different perspectives—technical, legal, image, and accessibility.

Step 8. Security tests. Depending on the risk profile, the application may require static code analysis, automatic vulnerability scanning, penetration testing simulating attacks, and server configuration review.

Step 9. Performance tests. Checking how the application handles normal and extreme loads: load tests, stress tests, and stability tests.

Step 10. Approval for production release. The final consent document must be signed by: the science club's supervisor, Student Activity Support Department, Information Security Office (IOD/IBI), ZBI (WCSS), faculty IT system administrator, Promotion Department, Accessibility Department (WCAG), and IT Department.

This is not a gate blocking innovation, but a joint network of safety.Consent is subject to verification every 12 months, and security breaches or lack of response to reports may result in the application being removed from production.

Innovation with the Institution, Not Against It

The story of Solvro is proof that Shadow IT doesn't have to be an enemy but can be a starting point for something much better. Instead of confrontation, we chose dialogue. Instead of blocking, the university created a framework for responsible innovation. Instead of operating in the shadows, we now operate in full light, with the full support of the institution and real resources.

Today KN Solvro is the largest Science Club at Wrocław Tech and at the same time the largest organization of its kind in Poland. We cooperate at the local, national, and international levels, win awards at international hackathons, and educate future engineers who leave Solvro ready for professional challenges.

But above all, we continue to create applications by students for students. Only now we do it responsibly, sustainably, and with full awareness that good software is not only good code but also good governance.

"In the world of AI, the tools for building are now in the hands of everyone. Our task is not to take these tools away but to build safe frameworks within which they can be used responsibly." - Dawid Linek

 

The article was based on Dawid Linek's presentation at the iCHTS conference (April 2026) and internal documentation of KN Solvro and the Procedure for Making Applications Available to Users of Wrocław Tech dated 04/02/2026.