From C++ at 14 to Technical Product Owner: Benjamin Auinger (fiskaly GmbH) on API-first, eRecept, and Choosing Concepts over Tools

Introduction: A concise, concept-first career arc

In our session “Title: Benjamin Auinger, Technical Product Owner bei fiskaly” with “Speaker: Benjamin Auinger” from “Company: fiskaly GmbH,” we heard a compact yet telling story about growing from an early curiosity in programming to owning technical product direction. Benjamin’s throughline is consistent: foundations matter more than any one tool. Even as he steers roadmaps, APIs, and partner conversations, he keeps returning to the basics that transfer across languages, stacks, and products.

This recap follows what Benjamin shared: an early start in C++, a technical school with broad exposure, hands-on freelancing, and a three-year journey at fiskaly from junior developer to Technical Product Owner for the Austrian fiscalization solution and the company’s newest product, eRecept. We focus on the milestones, the mindset, and the practical advice he offered other developers.

Early beginnings: C++ at 14 and a wide toolkit at HTL

Benjamin began around age 14, experimenting with C++ to get into programming.

He then attended a “so-called HTL, it's a technical college,” where the exposure to languages and tools broadened considerably. He mentions Java, C#, C++, PHP, and JavaScript, alongside theoretical grounding in algorithms and data structures.

We read this as a powerful combination: early depth via a systems-leaning language, then breadth across paradigms, and an explicit focus on core CS fundamentals. The payoff is transferability—new tools come and go, but concepts and patterns repeat.

Learning through practice: Freelancing while still in school

While still at school, Benjamin started freelancing—initially with WordPress, moving into more complex web projects.

This stage doesn’t just compound technical habits; it introduces real-world constraints: timelines, scope, client expectations, and the negotiation between desirables and deliverables. Those conversations become the seedbed for product responsibility later on, where the “what” and “why” must align with the “how.”

Joining fiskaly: From junior developer to Technical Product Owner

Benjamin’s first “real” job was at fiskaly roughly three years ago, starting as a junior developer in a very small team—about five people, including the three founders.

Small-team contexts accelerate growth: you see decisions end-to-end, from architecture to delivery to customer outcomes. Benjamin first worked on the German product, then shifted to the Austrian product and into the Technical Product Owner role.

Today, he maintains eRecept, the newest product, alongside responsibility for the Austrian fiscalization solution.

What a Technical Product Owner does at fiskaly

Benjamin’s description of the role is crisp: provide the roadmap for technical products, discuss architecture with the team, coordinate with external partners (customers, business development, sales), align deadlines, and—crucially—make the “why” explicit for the team.

In practice, that bundles several overlapping skill sets:

• Roadmap design: sequencing milestones, resolving dependencies, pacing delivery.
• Architecture dialogue: surfacing tradeoffs, risks, and maintainability.
• Partner communication: aligning expectations with customers and go-to-market teams.
• Team clarity: ensuring every task has a purpose the team can articulate.

From our editorial vantage point, this is the shift from “I ship features” to “I create shared understanding for a system of people, requirements, and interfaces.”

API-first and domain focus: Fiscalization and digital receipts

fiskaly builds “API-first solutions for fiscalization.” In Germany, Benjamin references the “so-called DS-Finfo-Car” as a standard for “protocoling relevant text data.” Alongside that, the eRecept initiative aims to set a standard for digital receipts, currently active in Germany and Austria, with an ambition to reach a large portion of Europe by the end of the year.

For engineers, API-first is a powerful organizing principle: the contract between systems—well-defined requests, responses, and error semantics—becomes the central artifact. That helps teams coordinate internally and makes integration cleaner for customers.

How API-first shapes product work

• Consistency: A carefully defined API becomes the single reference for frontends, backends, and partners.
• Change discipline: Versioning, deprecations, and migration paths are explicit and plannable.
• Collaboration: External partners can test early, focusing their feedback on interface quality.

This aligns with Benjamin’s day-to-day: architecture conversations, roadmapping, and partner coordination revolve around the boundaries and behaviors exposed by APIs.

Small teams, outsized growth: Why early-stage contexts matter

Starting in a team of around five, including founders, is more than a biographical detail—it explains how quickly responsibility expands. In such environments, you:

• See how product, engineering, and go-to-market connect.
• Watch decisions reflect instantly in customer outcomes and system behavior.
• Learn to prioritize deliberately and accept tradeoffs.

Benjamin’s path—German product, then Austrian product, then Technical Product Owner—follows this pattern. Today he holds the threads for eRecept, integrating roadmap, architecture, and partner dialogue.

“Focus on concepts rather than tools”

Benjamin’s core career advice is direct and anchored in experience:

Tools aren’t irrelevant—he stresses that—but they’re replaceable. Concepts endure: algorithms, data structures, concurrency, architectural patterns, clean interfaces, testability, observability. Master those and adopting new tools becomes faster and safer.

Pragmatically, this is the distinction between short-term productivity and long-term effectiveness. Tools change; concepts compound.

Practical ways to double down on concepts

• Read code in multiple languages; spot recurring ideas beneath the syntax.
• Build small systems to isolate a concept (queues, caching, retry strategies).
• Translate features into fundamentals: What structure? What protocol? What invariants?

Education: Foundations matter, but learning isn’t confined to classrooms

Benjamin takes a nuanced view of education:

He notes that some teammates come from economics and are strong self-learners. The decisive factor is mindset:

Our takeaway: formal programs can speed up and structure foundational learning, but tech careers are flexible. If you deliberately acquire the fundamentals and keep learning, you can reach the same ground.

Building your learning path

• Target foundations: data structures, algorithms, complexity, networking basics.
• Use practice as an accelerant: side projects, freelancing, open-source contributions.
• Cultivate routines: curiosity, feedback loops, steady iteration.

A day in the life of a Technical Product Owner—through Benjamin’s lens

Translating Benjamin’s description into the work at hand highlights a role that connects dots:

• Roadmap and sequencing: Which milestones move eRecept and the Austrian fiscalization solution forward in a reliable way?
• Architecture dialogue: Which design choices secure maintainability and extensibility, and surface risks early?
• Partner conversations: Customers, business development, and sales bring different angles—the TPO aligns expectations so delivery, quality, and timelines make sense together.
• Team clarity: “Making it clear what needs to be done and for what reason” may be the most powerful productivity lever.

From where we sit at DevJobs.at, that’s the craft of translating technology into direction and context. Not just the next story in the sprint, but the connective tissue between “why” and “how.”

eRecept: A young product with a standard-setting ambition

Benjamin calls eRecept “our newest product.” The aspiration is to set a standard for digital receipts and make it usable through an API-first approach. The team is active in Germany and Austria, aiming to reach a large portion of Europe by year’s end.

Key takeaways for engineers and product folks alike:

• “New” doesn’t mean vague—define the interface early and bring the ecosystem along.
• Standards are collaborative: conversations with customers and GTM functions feed the roadmap.
• Ambition needs sequence: plan step by step while keeping the target picture visible.

From lines of code to systems thinking: A pattern of growth

Benjamin’s career reads as a shift from implementation to systems thinking:

1. Early technical curiosity (C++ at 14) builds depth.
2. Breadth in languages and tools (Java, C#, C++, PHP, JavaScript) builds flexibility.
3. Theoretical foundations (algorithms, data structures) enable transfer.
4. Practical pressure (freelancing) sharpens prioritization and communication.
5. Product focus (small team at fiskaly) nurtures ownership and context.
6. Technical Product Ownership ties together technology, roadmaps, and stakeholders.

For developers considering their next move, this suggests a route: strengthen concepts, seek real-world practice, open up to responsibility, and learn to articulate the “why” as clearly as the “how.”

Working with standards: The “DS-Finfo-Car” reference

Benjamin references the “so-called DS-Finfo-Car” as a standard in Germany for “protocoling relevant text data.” In such contexts, the quality of your interfaces often determines your velocity. Standards aren’t a burden; they are shared references that make quality measurable.

What that implies for technical teams:

• Check your API design against the standard early.
• Treat logging/protocoling as a first-class feature, not an afterthought.
• Budget time for consistency checks so integrations hold under change.

Actionable guidance for engineers and product-minded developers

Distilling Benjamin’s talk into practical steps:

• Learn the concepts behind your tools: use language diversity to train your grasp of paradigms.
• Accumulate practice: freelancing, projects, prototypes—anything that yields real feedback.
• Think API-first: define interfaces that let teams and partners integrate early.
• Practice purpose: explain the “why” behind tasks—clarity compounds.
• Keep a learning mindset: formal education helps, but the willingness to grow is essential.

Quotes worth remembering

• “Focus on concepts rather than tools.”
• “…making it clear what needs to be done and for what reason…”
• “…API-first solutions for fiscalization…”
• “I started freelancing… and then continued to more complex projects.”

They’re not slogans—they’re a method.

Closing: Clarity as a force multiplier

“Title: Benjamin Auinger, Technical Product Owner bei fiskaly” delivered a tight narrative. From writing C++ at 14 to owning the roadmap for eRecept and the Austrian fiscalization solution, Benjamin’s path highlights what endures in tech: concepts, practice, communication, and an open learning mindset.

In a role where API-first and references like “DS-Finfo-Car” frame the work, clarity becomes the core artifact—across roadmaps, architectures, stakeholders, and the team’s everyday priorities. That clarity is what lets teams scale and products endure.

If we were to pass along one message from this session, it would be this: build your foundation on concepts, have the interface conversations—technical and human—and keep your “why” in focus. The rest follows.

• 

  

  Patrick Gaubatz, CTO & Alexandru Stan, Agile Coach von fiskaly

  CTO und Agile Coach von fiskaly Patrick Gaubatz und Alexandru Stan erzählen im Interview über die Organisation des Teams, was neue Bewerber bei fiskaly erwartet und mit welchen Technologien dort gearbeitet wird.

  Watch now

• 

  

  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