Running customer code safely inside InDoc EDGE

InDoc EDGE is Mikrocop’s platform for document management and process automation in regulated sectors. Its roadmap held more than its team could build. We built the service that runs customers’ own code, delivered three modules and joined the core team.

Used by

InDoc EDGE in the browser: document folders, a tagged file list and a roadmap preview pane
Industry
Document management & process automation
Engagement
Projects, Teams and Specialists
Scope
Backend, frontend, architecture, testing, documentation
Timeline
June 2024 to September 2026

The situation

A roadmap larger than the team available to build it

InDoc EDGE manages documents and business processes for enterprises in regulated sectors, from capture and approval to electronic signing and long-term archiving. Its customers include OTP banka, Luka Koper and GLS.

Mikrocop’s roadmap held more work than its development team could deliver within the release schedule. Complete modules were planned with no one free to build them, and a new Scripting Sandbox needed expertise the in-house team did not have.

The sandbox was the hardest part. Customers write C# scripts in the process editor to add their own calculations and rules, so the platform has to run code it does not control. In the previous environment, a script could stop a sandbox instance or reach the machine it ran on.

What we built

A Scripting Sandbox we owned end to end

The sandbox was a fixed-price project. We owned its specification, architecture, development, testing and documentation.

It is a separate .NET service that InDoc EDGE calls over gRPC. Each script runs in its own isolated Linux process, with limited computing resources and no access to the host machine. More instances can be added as load grows, and they can be shared between InDoc EDGE deployments, with load balancing on the calling side. Redis caches compiled scripts, and a fallback to the legacy sandbox covered the transition.

We also delivered three modules independently, refining tickets with Mikrocop’s product owners and estimating with its technical team. For Document Signing, we rewrote Mikrocop’s internal library for creating and verifying digital signatures on current platform APIs. The External API work moved more configuration into InDoc EDGE’s own settings and added JWT authentication, with compatibility checks against existing client integrations. Bookmarks added organisation-wide bookmarks, controlled by administrators with full access control, alongside personal ones.

Inside the team

From delivering modules to building the core product

With the modules delivered, the wider roadmap still needed people. Our engineers joined Mikrocop’s core team and worked within its process, from specification to testing.

We extended the BPMN workflow engine, which models each business process, and rewrote the access control system. We traced and fixed hard defects, including multi-tenant context leaks and race conditions in distributed concurrent processing, and helped move the frontend from Durandal to React.

On the frontend, we designed in-app back navigation that behaves like a browser’s, with fallbacks that replaced hardcoded routes. We added form components for complex input and carried out the major package upgrades: React Query to v5, the deprecated MUI packages and react-i18next.

The outcome

A record release output and signing 65% faster

The releases we worked on shipped 30% more feature tickets than the releases before we joined, a record for InDoc EDGE.

Document signing and verification became 65% faster on a substantially simpler codebase. The new sandbox runs at twice the throughput of the previous environment, and scripts can no longer stop an instance or reach the machine it runs on. After the External API changes, some client-requested integrations need up to 90% less work, and one class of custom integration no longer has to be maintained.

Outcomes

  • 2x

    Script throughput against the previous environment

    With every script isolated and resource-limited

  • 65%

    Faster document signing and verification

    One signature fell from 1,053ms to 363ms in benchmarks

  • 30%

    More feature tickets shipped, a record for InDoc EDGE

    In the releases we worked on, compared with releases before we joined

What we shipped

  • Scripting Sandbox service, from specification to documentation
  • Isolated, resource-limited script execution that scales across instances
  • Rewritten library for creating and verifying digital signatures
  • External API configuration within InDoc EDGE settings
  • Organisation-level and personal bookmarks with access control
  • BPMN workflow engine extensions and a rewritten access control system
  • Fixes for tenant-separation and concurrency defects
  • Contribution to the frontend move from Durandal to React
  • In-app back navigation with fallbacks, replacing hardcoded routes
  • Frontend package upgrades, including React Query v5 and MUI

Built with

Back-end

  • .NET
  • ASP.NET
  • C#
  • gRPC

Data

  • SQL Server
  • Redis
  • Elasticsearch

Front-end

  • React
  • TypeScript

Platform

  • Docker Swarm
  • Isolate
  • TeamCity
  • Bitbucket

Other engagements, other constraints.

  • The Hyperice app open on a phone, beside a Hyperice massage gun

    Hyperice

    Backend rewrite for the HyperSmart app, four weeks before launch

  • Blissbook on a laptop: a workplace-violence policy open in the editor, with its approval status, reviewers and discussion thread alongside

    Blissbook

    AI features and core product development for HR policies

  • The PrizePicks app on a phone resting on a basketball: NBA player cards, each with a points line to pick over or under

    PrizePicks

    Architecture and development for The Esports Lab

Tell us what you’re building.

The complex, the critical, the bold. We’ll tell you how we’d ship it.