Inside fiskaly’s Engineering Culture: GitOps Autonomy, Open Source at Scale, and People-First Hiring – Insights from Patrick Gaubatz & Alexandru Stan (fiskaly GmbH)

What we learned at DevJobs.at from this session

In the session titled “Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly” (Speaker: Patrick Gaubatz & Alexandru Stan, Company: fiskaly GmbH), the two leaders offered a candid look into how an API-first company builds and operates core infrastructure in a highly regulated domain. The headline takeaway: fiskaly is an engineering-centric organization that gives teams true product ownership—from “build it” to “run it” to “document and support it.” At the same time, the company balances strict compliance requirements with modern engineering practices—and it scales an infrastructure that already involves “hundreds of thousands of Docker containers.”

A few concrete points Patrick and Alexandru emphasized:

• The development team counts 23 people—roughly 50% of the entire company. fiskaly is decisively engineering-driven.
• Multiple development teams with specific skill sets own at least one product—some teams already run multiple products.
• GitOps is the operating principle: teams own their code, infrastructure, and processes and make decisions where the work happens.
• Roles are deliberately separated: Engineers, a technically proficient Technical Product Owner (TPO), and an Agile Coach collaborate as peers; People Leadership is kept outside the team to support a flat hierarchy.
• The environment is highly regulated: certifications, security guidelines, and long rollout cycles shape day-to-day work—even as modern technology is embraced where it fits.
• The platform is fully containerized (Docker, Kubernetes) on Linux; PostgreSQL and Nginx are core components. TypeScript/JavaScript is used across the stack, while performance-critical parts increasingly move to Go.
• Hiring and onboarding are transparent, lean, and human-centric—from a culture interview and focused coding challenge to a structured, buddy-supported start.

Below is our editorial recap for engineers and tech leaders who want to understand how fiskaly organizes teams, makes technology choices, approaches hiring, and supports growth.

Context: API-first in the critical domain of fiscalization

fiskaly describes itself as an API-first company. Its products are primarily backend services that deliver “a very specific solution in a critical context”: fiscalization. Patrick noted the topic’s specificity and pointed to the company website for details. What matters here is the operational implication: these services underpin cash register systems. Even “a split second” of downtime can affect “hundreds of customers.” That level of criticality shapes architecture, processes, and culture.

Patrick also explained how the nature of technical challenges has shifted as the company matured. Early on, the focus was on finding technically viable solutions under strict constraints—certifications, security guidelines, compliance rules. With that foundation established, growth brought new concerns to the forefront: understanding the system as a whole, investing in observability, meeting stringent availability requirements, and operating at a scale that commands respect.

In regulated infrastructure, this isn’t a warning—it’s a design premise. It demands conservative engineering, mature architecture, and disciplined change management.

Team size, structure, and end-to-end ownership

Patrick put the development team at 23 people—about half the company. That’s a strong signal of engineering focus. fiskaly runs multiple development teams with specific skill sets. GitOps drives the design: teams should be strong enough to “own the whole product”—including development, operations, documentation, and support processes. Decisions are made where knowledge and responsibility live: in the team.

What this means in practice:

• Teams own at least one product—some teams already own more than one.
• Artifacts and processes are fully handled by the people who build and run them.
• Quality, security, deployment, and support are treated as integral parts of product work.

For a young company, this depth of ownership is noteworthy—and it works because competencies are deliberately separated while still collaborating on equal footing.

Role design: Peer structure over micro-hierarchy

Alexandru outlined the role setup, which borrows from traditional agile teams and then consciously decouples responsibilities:

• Engineering team members (Engineers)
• Technical Product Owner (technically proficient, providing guidance and direction)
• Agile Coach (process care, improvements, optimizations)
• Separate People Leadership (people management intentionally removed from the team context)

The goal is to reduce friction, maintain a flat hierarchy, and create a peer environment. Technical, product, and process leadership happen within the team. Personal development and people management are handled separately to avoid conflicts of interest. The result is a mode of work where roles complement each other rather than overlap unhelpfully.

GitOps as a promise of autonomy

At fiskaly, GitOps is more than tooling; it’s an organizational stance. Teams own production paths, policies, and automation—and they are empowered “to actually change the processes in the way it’s tailored for their work.” Decision-making is pushed to where the work is done. That takes maturity, but it creates speed and accountability. If you build it, you also run it—with all that entails for security, compliance, and reliability.

For engineers, this translates into real agency. The company wants teams to be autonomous—and it gives them the means, including documentation, monitoring, and support as part of product ownership.

Working in a regulated environment: Balancing compliance and modernity

fiskaly’s products undergo certification, adhere to security guidelines, and live through long update cycles. Patrick described the challenge of finding the “sweet spot” between what the security and compliance world has been doing for decades and the modern technologies and approaches the team brings in.

Practical implications:

• Not every technical option is on the table—constraints are real.
• Every change to certified product parts must go through certification—this takes months.
• Once a version is live, you “have to live with it” for months.

The consequence: work is done with great care, the stack is deeply understood, and changes are constructed to respect the regulatory cadence. For engineers, that’s demanding and educational: decisions must be auditable, maintainable, and operationally sound.

Scale and operations: Success brings a new class of problems

As fiskaly grew, operational and scaling challenges became more prominent. The statement was unambiguous: keeping “hundreds of thousands of Docker containers” running is a challenge in itself—especially in a domain where even a “split second” of downtime impacts “hundreds of customers.”

Day to day, this implies:

• Reliability and observability are first-class citizens in system design.
• Edge cases aren’t hypothetical—they’re inevitable. The system must be prepared.
• Change management demands extra diligence because certification adds latency to rollouts.

This realism shows that fiskaly explicitly prioritizes performance, resilience, and operational knowledge—and treats error culture and system understanding as non-negotiable.

The stack: Open source, Linux-first, and intentional choices

Technologically, fiskaly is clearly positioned:

• Backend-centric, API-first.
• TypeScript/JavaScript across the stack, especially for UI-facing parts.

n- Performance-critical components are increasingly implemented in Go.

• Everything is containerized with Docker; orchestration is handled by Kubernetes.
• Linux is the foundation—Patrick noted that in development “everyone uses Linux on their desktop.”
• Open source is the backbone: PostgreSQL as a core database (once considered “boring,” now a strength), plus Nginx.

A striking decision: fiskaly builds in a way that makes it “potentially possible to run” all processes and containers “on your laptop.” That’s not just convenience; it’s a strategic stance against deep reliance on vendor-specific managed services.

Instead, fiskaly chooses ownership end-to-end—from the developer machine to production. It aids debugging, reduces lock-in, and strengthens long-term autonomy.

Collaboration in practice: Build it, run it, document it

The GitOps approach results in a pragmatic reality: teams don’t just write code; they also run and document the products, including support processes. It’s demanding, but it creates visibility and accountability. Tooling, process, and standards decisions live with the team. The Agile Coach keeps processes healthy, the Technical Product Owner provides both product direction and technical guidance, and engineers shape execution.

Separating People Leadership from the team context reduces role conflicts and reinforces a peer culture. Leadership happens where it should—technical leadership within the team, personal development via people leadership.

Hiring: Lean, transparent, and people-first

Alexandru described a deliberately open process. The interview steps are public on the website, and the company plans to share onboarding details as well. Recruiting starts with the first email—and it’s lean by design because time matters.

The steps:

1. Application without a motivation letter. A resume and a GitHub profile are sufficient. Sharing a bit about yourself there is a plus.
2. Screening by development colleagues: does the profile fit current team needs?
3. First interview as culture fit. No technical discussion here—it’s about personality, working style, and team fit.
4. Coding challenge. The team provides boilerplate code so candidates can focus on the task. The goal: assess technical proficiency, see whether candidates “speak our language,” and give both sides a view into code and practices.
5. Technical interview with “some of our best colleagues in the field.” The focus: seniority, depth, and the ability to explain, integrate, and motivate—i.e., the impact on the team environment.

A few notable signals:

• It’s not just about coding; it’s about contributing to “a team atmosphere that is enjoyable.”
• If someone is a good fit, fiskaly doesn’t wait to compare against a batch—they make the offer.
• Long notice periods (3–4 months) aren’t a barrier.

Onboarding: Structure, buddies, and early proximity

Once the offer is accepted, People & Culture jumps in: gathering information, sharing what comes next, and rolling out a structured onboarding starting on day one. There’s an onboarding package to learn about the company and colleagues, and active connections to other teams and departments—because, as Alexandru put it, “the whole company is the product.”

Onboarding is planned across:

• the first day,
• the first week,
• the first month,
• the second month,
• and the first three months overall.

Two to three “buddies” support the newcomer:

• A People & Culture buddy for administrative topics (e.g., how to take a day off).
• A team buddy to guide through code, context, and day-to-day work.

fiskaly emphasizes being “on premise” during the first weeks. The experience: onboarding is faster, and newcomers feel “at home” sooner. In parallel, there’s a continuous conversation about growth and career development. The company aims for “long-term commitments.”

Why this setup appeals to engineers

From our DevJobs.at vantage point, the session made a compelling case—grounded entirely in what was said—for why engineers and engineering leaders might be drawn to fiskaly:

• True product ownership: teams build, run, document, and support—with GitOps as the backbone.
• Autonomy with accountability: decisions move “to the people doing the work,” not to distant committees.
• Clear, flat roles: Engineers, TPO, Agile Coach, and separate People Leadership—peer collaboration over micro-hierarchy.
• Learning in a regulated domain: certification, security guidelines, and long release cycles teach care, architecture discipline, and systems thinking.
• Real scale and reliability: “hundreds of thousands of Docker containers,” a context where “every split second counts.”
• Open-source-first: Linux on the desktop, PostgreSQL, Nginx; the ability to run “the whole system on your laptop”; deliberate avoidance of black-box dependencies.
• Intentional stack: TypeScript/JavaScript where it fits; Go where performance is critical; Docker and Kubernetes by default.
• Transparent hiring: a short, clear process focused on culture and technical fit—minus unnecessary hurdles.
• Thoughtful onboarding: buddies, cross-team exposure, and a preference for early in-person time to accelerate integration.
• People-first stance: respect for candidates’ time, continuous growth conversations, and a long-term view.

Quotes and ideas that stick

A few lines from the session capture fiskaly’s culture and expectations:

Together, these statements reveal a blend of pragmatism and high standards—technically, organizationally, and interpersonally.

Conclusion: Ownership, care, and speed—without losing sight of people

The session “Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly” (Speaker: Patrick Gaubatz & Alexandru Stan, Company: fiskaly GmbH) portrayed an organization that doubles down on engineering excellence and team autonomy—without romanticizing the constraints of a regulated environment. Instead, fiskaly seeks balance: modern technology where it’s robust and controllable; process discipline where it protects security, compliance, and operational stability.

For tech talent, the setup offers a compelling mix of agency, learning, and impact. If you want to build systems that are critical, operate at scale, and remain understandable, certifiable, and debuggable, fiskaly provides that environment—with teams that own what they build and a culture that genuinely puts people first.

Our impression: this is more than software development. It’s end-to-end product operations—GitOps pipelines, on-call attention to container fleets, and a buddy who opens the right doors on day one. That’s what makes fiskaly stand out as an engineering employer.

• 

  

  Kostas Plakidas, Back End Developer bei fiskaly

  Kostas Plakidas von fiskaly spricht im Interview über seinen Werdegang – angefangen bei Turbo Pascal bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Anfänger.

  Watch now
• 

  

  Benjamin Auinger, Technical Product Owner bei fiskaly

  Benjamin Auinger von fiskaly erzählt im Interview über seine Laufbahn im Programmieren, was das Spannende in seinem Job als Technical Product Owner ist und gibt Tipps für Neueinsteiger.

  Watch now