Jan Fietz
You have a project that sits outside your day-to-day. I build it with you – until it runs.
Backends, interfaces, platforms and frontends – mostly for renewable energy and industry: monitoring, SCADA, integration, control, automation.
15 years of software for energy assets: SCADA, grid connection, monitoring, control · remote, across Europe
Situations
Four situations I get brought in for
If yours looks different, describe it anyway. Whether I'm the right person, I'll tell you after two minutes, not two weeks.
-
01
Your customer wants an integration you don't have yet.
The order hinges on an interface: to a grid operator, a control room, an ERP or a partner's system. Nobody in-house really knows the protocol, the specification runs to a hundred pages and doesn't answer the questions you actually have, and the customer asks every week when it will be ready. The people who could build it are already booked out for the next few months.
If that sounds familiar: the interface itself is usually built in weeks. The time gets lost in the places where the specification says nothing – timing behaviour, error cases, ordering on restart.
-
02
The product is growing faster than the platform.
At a few hundred assets everything was fine. A few thousand later, reports take minutes, the database fills up overnight, and the UI loads until the customer gives up. Sales has just signed the next large customer, the team is tied up keeping it running — and nobody can say whether the platform will carry the next order of magnitude at all.
If that sounds familiar: scaling rarely fails on the language or the framework. It fails on a data model that was designed for the first order of magnitude.
-
03
The system has run for years. Nobody wants to touch it anymore.
It does what it should, and everyone in-house knows that only holds as long as nothing changes. The documentation is the code, the special cases live only in the database, and every adjustment sales promises becomes a risk to live operations. Rebuilding is out of the question, it has to keep running – but somebody has to understand what is actually running.
If that sounds familiar: such systems are rarely as opaque as they look. Usually what's missing is just someone with the time to read them before changing them.
-
04
The product exists as an idea. And as a first customer.
The domain knowledge is there, the data or the assets are there, maybe a prototype that works on someone's desk. What is missing is the backend underneath it, a user interface a customer can operate without a walkthrough, and a connection you can rely on in operations. The first customer is waiting for a date. Nobody in-house has taken something like this all the way into operations — not because the team couldn't, but because nobody has done it before.
If that sounds familiar: your first customer sets the deadline, not the architecture. What gets built in those first months usually stays — including what was meant as a stopgap.
Process
How working together actually goes
-
First call, 30 minutes.
You describe the situation. I tell you straight whether I'm the right person for it. If I'm not, I say so.
-
Assessment of the existing system and the requirements, fixed price.
Before I propose a project, I look at what is there and what is needed. The result is a written report – it is yours, whether or not we work together afterwards. Details below.
-
Proposal with milestones.
Based on the report: clearly bounded milestones, each with a fixed price and an acceptance criterion. No proposal before the assessment, because I don't quote numbers I can't back up.
-
Delivery you can watch.
The code sits in your repository from day one. If you don't have one, I set one up for you – in your name, with full access, not in mine. Weekly demo. Interfaces are tested against a simulator before they run against the real counterparty. Every milestone is handed over as a versioned state with a changelog and documentation – documentation is an acceptance criterion, not rework.
-
Handover.
Onboarding for your team, operations documentation, and a retainer for operations and further development if you want one. The goal is that you don't need me to understand the system.
What you're probably wondering
You're one person. What if you drop out?
That is why the code sits in a repository you have full access to from day one, why documentation is an acceptance criterion, and why handover is part of every proposal. Losing me should be inconvenient, not existential for your project.
We don't have the know-how in-house. How are we supposed to judge your work?
By results that don't come from me: sign-off by the grid operator, the test against the simulator, the weekly demo where you see what runs. My word is the weakest evidence in that list.
Why not a systems integrator?
You can do that. You get a team, but rarely the person who has taken the protocol through acceptance before. With me that is the same person who writes the code.
How can one person replace a team?
Not with hours. With architecture designed for operations from the start, with tooling that takes over boilerplate and tests, and with handover as a fixed part of every milestone. I don't replace your team – I build what your team develops further later.
Four decisions that always apply
- Open standards. Open source and standard protocols, so you can migrate – away from me, too.
- No cloud dependency. Container-based workloads that run the same way on another provider or on-premises.
- Linux all the way down. From the shell to the container runtime. That is what decides things when systems are under load or a grown setup has to be analysed.
- AI tooling in daily work. For boilerplate and tests, not for architecture. No number attached, because I can't back one up.
Getting started
Every project starts with an assessment.
I look at your systems, interfaces and requirements, talk to the people involved, and deliver a report: what is there, what is missing, where the risks are, what I recommend and roughly what it costs. After that you know what the project involves – including if you go ahead with someone else.
- Price
- Fixed price, stated up front
- Duration
- Duration and dates are agreed in writing before the start
- Result
- A written report plus a walkthrough for your team
- Ownership
- The report is yours
30 minutes, no obligation. No proposal without an assessment.
Experience
Why I know this
For fifteen years I built and ran, at Quantec Networks, Quantec Systems, Scada International and Opoura, exactly the systems this page is about: a SCADA middleware that by the time I left connected more than 8,000 assets for over 30 customers in Europe and the US; interfaces to grid operators and direct marketers (aggregators) with closed-loop active and reactive power control on a 100 ms cycle; a product for the European balancing reserve market, live in Denmark, Sweden and Poland; and most recently a new monitoring platform for around 7,000 assets – from the first design to building the team. The frontends for these I built in React on Node.js; the last one monitored 6,000 assets in a single instance.
I was a developer there, then senior, then team lead and architect. I sat through the acceptance tests, the migrations during live operation, and the nights when the control loop wouldn't converge. Today I do this directly for the companies that need such systems.
Quantec Networks, Quantec Systems, Scada International, Opoura GmbH · 2011 - 2026
Vendor-Agnostic Data Acquisition Platform for Wind Turbines
15 years of responsibility for a SCADA middleware with over 8,000 connected assets at 30+ customers across Europe and the US — from protocol layer to cloud-native deployment.
Role: Developer → Senior → Team lead · Technical advisory · Third-level support as an employee
Quantec Networks, Quantec Systems, Scada International, Opoura GmbH · ~10 years
Interfaces and Control for Direct Marketers and Grid Operators
Bidirectional extension of the data gateway: 10 Hz closed-loop active and reactive power control, multi-protocol, in production at thousands of plants and connected to leading TSOs and direct marketers.
Role: Development and architecture of the control and interface layer as an employee
Quantec Systems, Scada International, Opoura GmbH · Live in DK, SE, PL
Product for the European Ancillary Reserves Market
Stand-alone product for the European balancing reserve market: primary, secondary and tertiary reserve including Nordic variants — for wind, solar, BESS, hybrid and controllable loads.
Role: Market and control interfaces · cross-product integration coordination as an employee
Quantec Systems, Scada International, Opoura GmbH · Greenfield to production
Real-Time Monitoring Platform for Mixed Generation Portfolios
Greenfield platform for 24/7 operations: roughly 7,000 assets and controllers in real-time monitoring, ~50 concurrent operators, multi-cloud and on-premises via the same deployment pipeline.
Role: Architecture and initial implementation · building and leading the development team · product management as an employee
Code
If you want to see how I write code.
I maintain telcon-iec60870 and telcon-tase2, Rust libraries for IEC 60870-5 and TASE.2, plus telcon-opcxmlda for OPC XML DA on Linux without a Windows gateway. All public, all of it came out of problems I ran into on projects. Three minutes in the code says more about my work than any reference.
Contact
Tell me about the situation.
30 minutes, no obligation. You describe where it's stuck – I'll tell you straight whether and how I can help.
Three sentences is enough: which assets, which counterparty, where it's stuck.
Prefer email? mail@jan-fietz.de
Remote, across Europe · German and English · on-site for acceptance tests and workshops · independent since 2026