Looking Back on Our TechTalkThursday #25

Our third TechTalkThursday in 2025 – it was number 25 of our event series – took place on the 4th of September 2025 at 6PM in our office. We proudly welcomed three external speakers who all held captivating talks. There were many people attending the event on site, also some interested Nine employees, a few speakers’ guests and a lot of external attendees interested in the topics of Technical Debt, Software Companies Worrying About Infrastructure and NixOS.

This TechTalkThursday was also live-streamed on our YouTube channel and we were happy to see some listeners also on that platform. As usual, Thomas Hug, our CEO and founder of the company, started off the event with a short introduction, presenting the evening’s agenda, introducing the speakers and presenting the topics of their upcoming talks. This time, the three speakers were Patrick Scheller, Lukas Lehmann, co-founder of Pupil AG, and Lena Fuhrimann, founder of bespinian.

Technical Debt, How You Catch It and How You Deal With It

Patrick’s talk was the first one of the evening and explored the unavoidable reality of technical debt in software development, why it arises, and how teams can manage it effectively.

He began by stressing that technical debt cannot be eradicated. Every decision in development involves trade-offs between speed, quality, and maintainability. Even the best teams and companies accumulate debt because business pressures, deadlines, and competing priorities inevitably influence technical choices. Technical debt, therefore, is not merely a technical issue but a strategic business decision: sometimes organizations consciously accept debt to deliver faster or prioritize other goals.

Patrick categorized the sources of technical debt into three broad areas:

Code & architecture – Poor testing, insufficient documentation, ignored code reviews, and unresolved bugs all contribute. Without checks and balances, teams “fly blind,” letting defects pile up until they cause major issues.
Project & process management – Inadequate planning, weak requirement analysis, scope creep, and poor prioritization can all undermine project outcomes. Failures in communication exacerbate misunderstandings, requiring rework and wasted effort.
People & knowledge – Lack of experience, poor knowledge sharing, low motivation, team friction, and high turnover reduce cohesion and slow progress. A lack of ownership or failure to adopt new practices further deepens the problem.

These factors interact with the “project management triangle” of time, scope, and cost. Adjusting one inevitably impacts the others, and technical debt magnifies this interdependence. For instance, investing more time and budget may not yield proportional quality improvements if knowledge gaps or poor architecture persist.

To counteract these challenges, Patrick highlighted measurement and monitoring. Teams should track task volume, estimation accuracy, lead time from feature definition to delivery, mean time to repair (MTTR), bug rates, and maintainability trends. Such metrics, observed over time, reveal whether debt is compounding or being managed.

On a practical level, he suggested:

Regularly updating libraries, tools, and language versions to reduce fear and complexity of upgrades.
Performing “proximity updates” (small improvements in related code areas when already working there).
Scheduling small refactorings every sprint, while planning large refactorings carefully.
Using patterns such as the Strangler or Backend-for-Frontend (BFF) approach to gradually modernize systems.

Another crucial element is “selling” refactoring and debt repayment to stakeholders. Developers cannot simply argue for cleaner code; they must frame the benefits in terms that matter to different audiences. Executives care about cost and risk, project managers focus on delivery speed and stability, and developers value maintainability. Presenting data and trends makes the case stronger and helps secure time and budget for debt reduction.

Patrick closed his presentation by emphasizing that all systems have technical debt. The key is not elimination but continuous management: working on it incrementally, prioritizing strategically, and preventing excessive accumulation. Ignoring it only increases the “interest” teams must pay later in the form of slower delivery, more bugs, and reduced flexibility.

Ultimately, successful organizations treat technical debt as an inevitable part of software development, but one that must be actively monitored, managed, and communicated across all levels of the business.

Why Software Companies Should Stop Worrying About Infrastructure

In the second talk, Lukas from Pupil outlined the company’s journey from a small MVP for school administration to a rapidly scaling Swiss edtech provider, and explained why software companies should keep their focus on software rather than infrastructure.

Pupil began when a teacher, frustrated with inefficient school processes, built a small PHP/MySQL tool. Initially piloted in one school, it quickly spread, leading to the formal incorporation of the company in 2019. Early funding enabled the hiring of skilled developers and provided resources to navigate the long sales cycles of public schools. Pupil’s breakthrough came with accreditation in the Canton of Thurgau in 2020, followed by public tenders in St. Gallen (2021), Schwyz (2022), and Aargau (2023). These wins positioned the company as a leading digital solution for K-12 schools in Switzerland.

Pupil provides an all-in-one cloud-based school management platform, consolidating processes like certificate printing, student and parent data management, device integration, messaging, and parental communication. Previously, schools used three to five separate tools, which created inefficiency and data silos. By offering modular adoption – schools can start with messaging, for example, and later expand – Pupil simplifies digital workflows while maintaining a clear focus on K-12. Narrowing the scope avoids unnecessary complexity and technical debt, a common risk when trying to serve too broad a market.

According to Lukas, in the early days, Pupil ran on a few Linux VMs, which were cost-effective but limited in scalability. As adoption grew, this setup became inadequate. The company debated a shift to microservices but instead chose a domain-driven hexagonal architecture within a single codebase, balancing modularity with maintainability. This approach supports a 30+ developer team without the overhead of managing dozens of microservices.

The key realization for them was that customers don’t care about infrastructure details. Schools only care about data privacy, reliability, performance, and new functionality – not whether the system is “cloud-native” or follows the latest architecture trends. As Lukas analogized, diners in a restaurant don’t care whether meals are cooked on gas or induction – they care about the food.

Instead of reinventing infrastructure, Pupil partnered with us for managed cloud services and migrated from single VMs to Kubernetes-based deployments. This reduced setup time for a new school from several hours to just minutes, fully automated. Their DevOps team, a team of only two people, leverages managed services wherever possible to minimize overhead.

As explained by René, a coworker of Lukas and DevOps engineer, Pupil runs production and test systems separately to safeguard customer data. Each school tenant gets its own Kubernetes namespace with dedicated PHP and Nginx containers, databases with failover, and persistent storage (moving towards S3). Monitoring is handled with Grafana and related tools provided by Nine. The architecture allows sharding across clusters (e.g., 300 schools per cluster) for scalability.

Lukas emphasized that business value lies in software and customer features, not in building bespoke infrastructure. The company prioritizes simplicity (“keep it simple, stupid”) and relies on managed services to scale efficiently. Regulatory needs like ISO certifications limit access to production environments, ensuring security while maintaining development speed. Feature development is driven by both customer requests and product management’s prioritization, balancing diverse school needs across cantons.

Pupil’s story demonstrates that infrastructure should not distract software companies from their true mission: delivering customer value. By outsourcing infrastructure concerns, simplifying architecture, and focusing narrowly on K-12 needs, Pupil has scaled rapidly while keeping costs, risks, and complexity under control.

NixOS: How My Laptop Became Declarative

In her talk, the last one of the evening, Lena shared her personal journey from experimenting with Arch Linux to embracing NixOS, and explained how Nix’s declarative approach transformed the way she manages her laptop and development environments.

Early in her career, Lena used Arch Linux and enjoyed its flexibility, but found herself repeatedly installing, uninstalling, and reconfiguring software manually. This contrasted sharply with her work in containers, where a Dockerfile provided a declarative specification of the environment – fully reproducible and portable. To bridge this gap, she first wrote a small tool, Pacman-file, that allowed her to list desired packages declaratively. While useful, it only covered package installation, not system services, configurations, or themes.

She then experimented with GNU Stow to manage configuration files from a Git repo, which improved reproducibility for her home directory. Still, the operating system itself lacked declarative management. Her turning point came when she discovered Nix, which enables declarative, reproducible, and reliable configuration of entire systems, from laptops to cloud servers.

Fuhrimann showed that Nix is three things:

A package manager (created in 2003 as a PhD project), installable on Linux and macOS. Its goals are reproducibility, declarativity, and reliability. Nix isolates dependencies, preventing conflicts common in other package managers.
A functional programming language, used to define system and package configurations. It is pure and idempotent – given the same configuration, it always produces the same result. Declarativity means specifying the desired state, not the steps to reach it.
An operating system (NixOS), where everything from system services to the desktop environment can be declared in configuration files. NixOS supports both stable and rolling releases, atomic upgrades, and system rollbacks, making it resilient to errors.

The Nix store underpins reproducibility. Installed packages and dependencies are stored with unique hashes, allowing multiple versions of software (e.g., different GCC versions) to coexist without conflicts. Rollbacks and validation mechanisms add resilience, while periodic cleanup prevents unbounded disk usage.

Lena demonstrated how adding a single line to her configuration file enables new services (e.g., running n8n automation). The system automatically resolves dependencies, sets up services, and applies changes atomically. Nix can also declaratively configure user environments, from editors like Neovim to desktop themes.

Nix has grown into one of the most active open-source communities on GitHub, with a repository of over 120,000 up-to-date packages – more than Arch’s AUR or Homebrew. Conferences like NixCon and local meetups foster collaboration. The ecosystem also includes tools such as Disco for declarative disk encryption and partitioning.

Advantages of NixOS:

Declarative OS-as-code approach
Strong reproducibility and lack of dependency conflicts
Atomic upgrades with rollback support
Ability to define and share development environments across teams
Large, active community and ecosystem

Drawbacks:

Steep learning curve, especially for those used to traditional Linux distributions
Inconsistent documentation despite community activity
Some features remain experimental
Increased disk usage due to multiple package versions
Occasional cryptic error messages and lack of strict Filesystem Hierarchy Standard (FHS) compliance

Lena concluded that NixOS is not a silver bullet but a powerful paradigm shift toward treating laptops and personal computers like declaratively defined infrastructure. Despite its challenges, the benefits of reproducibility, modularity, and reliability make it compelling for developers willing to invest in learning. Last but not least, she encouraged the audience to experiment with NixOS and join the vibrant community.