
The Reality of Development, the Experience, and the Decisions Behind InDoc EDGE
Developing an enterprise platform rarely looks the way people imagine from the outside. It is not a linear progression from requirement to solution. As members of the development team describe it, it is more like assembling a story or a puzzle. You have a vision, then over time you add pieces, replace some, and sometimes realize a particular piece needs to be built differently.
This is the reality the InDoc EDGE development team knows firsthand. From this reality, the decisions shaping the platform emerge.
Development Is Not About Adding Features
Ask the InDoc EDGE developers what their job is, and you will not hear a list of features.
“We develop and maintain a platform that must remain reliable even when it is complex, under heavy load, and under pressure,” explains the team. “A large part of our work is invisible to users. It often involves improving, fixing, and simplifying things that may have been built more quickly in the past than we would build them today.”
In enterprise environments, every new feature introduces additional complexity, dependencies, and risk. That is why the development of InDoc EDGE is not focused on adding functionality as quickly as possible, but on maintaining the long-term stability of the document management system and the business processes it supports.
We Choose Technologies Deliberately, Not Because of Trends
On the frontend, the platform is gradually transitioning to React - not because it is popular, but because it offers long-term support and maintainability.
You never know what the next five years will bring, but you can decide what makes the most sense today.
This mindset applies to every technical decision. What works quickly today may become difficult to upgrade tomorrow or introduce additional integration risks. That is why the team does not optimize only for the present, but for how the system will perform years from now.
An Architecture That Evolves Alongside the System
Every system that evolves over more than a decade and adapts to real customer needs carries traces of that journey. InDoc EDGE was not designed in isolation - it grew alongside customer requirements, integrations, and practical experience.
As a result, some past decisions look different today. "When you change one thing, you unintentionally affect another. That is experience, not theory,” explains the team. That is why every release includes time dedicated to technical improvements - systematically and without rushing.
“We work on a system that has its own history. And that history must be understood, not ignored.”
The platform is gradually moving toward a more modular architecture, giving the team greater control over changes and reducing risk with every upgrade.
Mistakes Are Part of the Process - Responsibility Is in the Response
When system limitations appeared under heavier loads, the team did not look for a quick fix. They created simulation environments, identified root causes, and determined where the actual problem existed within the system.
“Some problems cannot be solved by adding more servers. Sometimes you have to fix the foundations.”
In practice, the greatest load does not come from the number of documents. It comes from processes: automated workflows, mass permission changes, and complex business logic. When issues occur, the team monitors the system, identifies bottlenecks, and resolves them - sometimes through code optimization, sometimes through infrastructure improvements.
Mistakes are part of development. Responsibility lies in what you do next.
How this process works in practice - from issue reporting to retesting - is explained by Klavdija Blatnik in the blog Kako zagotavljamo zanesljivost dokumentnega sistema v praksi.
How Updates Are Delivered Without Impacting Production
Every new version of InDoc EDGE is first deployed to a demo environment, where it is tested by both developers and customers, particularly integrations and business-critical processes.
Migrations are performed programmatically, without manual intervention. A release reaches production only when the team is confident in its stability.
“We know that upgrades are sensitive,” explains the team.
That awareness is at the core of the approach: do not rush, understand the consequences, and respond effectively when something goes wrong.
UX Is Not an Add-On, It Is Part of Reliability
Developers understand the system from the inside and may tolerate certain issues because they know what is happening behind the scenes. Users do not and they should not have to.
“What users expect is clarity and reliability.”
If the system needs time to process something, it should communicate that clearly. If users do not understand what is happening, trust is quickly lost, even when everything is technically working correctly.
That is why the team considers user experience an integral part of reliability, not a separate layer.
AI: The Question Is Not If, but Where
Today, the team uses AI to support development. They are not rushing to include it in the product itself.
“First, we need to understand where AI genuinely helps users and where it would simply be a trend-driven addition. We do not want features that sound impressive in presentations but fail to solve real problems.”
The development of InDoc EDGE is not driven by speed. It is driven by stability – through thoughtful decisions, understanding consequences, and a willingness to address challenges rather than avoid them.
Source: This article is based on a conversation with members of the InDoc EDGE development team. The full interview is available on Mikrocop’s special anniversary website.