Conversation with members of the development team – Jernej Janež, Jure Knafeljc, Emil Avdič
The development of InDoc EDGE is not a story about features, but about decisions that need to stand the test of time. We spoke with the development team about how a system used in demanding environments is built in practice – and why reliability matters more than trends.
How does the long-term experience of the Mikrocop team shape the development of InDoc EDGE?
It mainly shows in the way we think. We do not build things for quick wins, but for long-term use. When you work with clients who use the system for years, sometimes even decades, you quickly realize that trends come and go, but the consequences of decisions remain.
That is why one question is always present in development: will this still hold up in a few years? Not just today.
How would you describe your work to someone who is not in IT?
We develop and maintain a platform that has to work reliably even when it is complex, heavily loaded, and under pressure. It is not just about adding functionality, but about keeping the system stable, clear, and manageable over time.
A large part of our work is not visible from the outside. It often involves improving, fixing, and simplifying things that may have been done faster in the past than we would do them today.
Development is not a linear process. It is more like building a story or putting together a puzzle. You have a vision, and over time you add pieces, sometimes replace one, and sometimes realize that one part needs to be built differently. That is how InDoc EDGE is developed – gradually, through experience and real situations.
How is the development team organized today?
Development is divided into frontend and backend, but in practice we work very closely together. The backend is the core of the system - data, processes, permissions, and integrations. The frontend is responsible for user experience and making functionality accessible.
Even though the user sees one platform, there are multiple connected components behind it. This means that with every change, you need to think more broadly - not just about what will work, but about what impact it may have elsewhere.
How do you choose technologies - especially at a time when trends change so quickly?
Very deliberately. We do not choose technologies because they are new or popular, but because they are stable, proven, and maintainable.
For example, on the frontend we are gradually moving to React - not because it is trendy, but because it has long-term support and makes future maintenance easier. On the backend, we use proven technologies, and over time we separate documents from the database, because experience has shown that this is necessary for performance.
“You never know what the next five years will bring – but you can decide what makes the most sense today.”
Jure Knafeljc, Head of Software Development Unit
How is the architecture of InDoc EDGE designed?
Honestly. InDoc EDGE grew as a monolith. That was not an ideal architectural decision, but a real consequence of rapid growth and the need to cover a lot of functionality in a short time.
Over time, the limitations of that approach became clear. You change one thing, and something else is affected without meaning to. That is experience, not theory.
Today, we are gradually breaking the system into more modular parts. Not overnight and not by force. With every release, we also dedicate time to technical improvements – because we know that without them, long-term stability is not possible.
Development today also means taking responsibility for past decisions. You are not working on a blank sheet, but on a system with its own history. And that history has to be understood, not ignored.
How do you deal with load, scalability, and performance?
In practice, the biggest strain does not come from the number of documents, but from processes: automated workflows, mass permission changes, and complex logic.
When issues appear, we do not hide them. We monitor the system, look for concrete bottlenecks, and fix them – sometimes through code optimization, sometimes by changing the logic, and sometimes through infrastructure.
What matters is that we know where to look for the cause and that we actually fix it, not just reduce the impact.
Have mistakes happened over the years?
Of course. Developing a complex system without mistakes does not exist.
We have had cases where limitations only became visible under heavier load. At that point, we stopped, created simulation environments, and identified what was not working at the core. Some problems cannot be solved by adding more servers – in those cases, you need to fix the foundation.
The difference is not whether mistakes happen, but how you respond to them.
“Mistakes are part of development. Responsibility lies in what you do next.”
Sometimes that also means slower development than some might want. But in the long run, it is the only way to keep the system stable and manageable.
How do you ensure code quality and testing?
Testing is not the final step, but an integral part of development. Every developer tests their own code, and often it is during testing that mistakes or weak decisions become visible.
We know that fixing one thing can affect something else. Tests are there to catch that as early as possible – not only when it reaches users. This approach is also essential because we work in environments where traceability, security, and certifications are not optional, but necessary.
How do updates happen without impacting users?
Every version first goes into a demo environment. There, both we and our clients test it – especially integrations and specific processes that are critical for them.
We know that updates are a sensitive matter. That is why migrations are handled programmatically, without manual intervention, and only when we are confident enough does a version move into production.
How does collaboration with other teams work?
Development is not isolated in its own bubble. We work closely with business solutions, the QA team, product management, and other teams.
Sometimes there is friction, because of priorities, deadlines, or requirements, but that collaboration is exactly what helps decisions be made with a realistic understanding of consequences.
How do you look at user experience (UX)?
As developers, we know the system from the inside, which means we tolerate certain things because we understand what is happening in the background. Users do not know the internal workings of the system – and they do not need to. What they expect is clarity and reliability.
If the system needs time, it has to show that clearly. If the user does not know what is happening, trust is quickly lost, even if everything works correctly in the background.
That is why we see user experience as part of reliability, not as an add-on.
Jernej Janež, developer
What is your approach to new technologies such as AI?
Today, we use AI as support in development. But we are not rushing to include AI in the product itself.
First, it has to be clear where AI truly helps the user and where it would only be an addition driven by trend. We do not want features that sound good in presentations but do not solve real problems.
“The question is not whether AI will be used, but where it actually makes sense.”
What motivates you most in your work?
The team. The fact that you can be honest, ask questions, make mistakes, and fix them together. And the feeling that you are developing a product used in serious environments, where reliability is not just a nice word.
What would you say is Mikrocop’s greatest value after 50 years?
Experience. And the understanding that trust does not come from promises, but from things working. Even when it is difficult.
