Rebuilding the engine of a growing legal AI platform
Our Scandinavian legal tech client builds a secure AI platform for legal work: research, document analysis, drafting and workflow automation. Every answer links back to its source.
- Industry
- Legal tech
- Region
- Scandinavia
- Product
- Secure AI platform for legal work
- Users
- Law firms, in-house legal teams, enterprises
- What matters most
- Security, traceability, compliance
- Scale
- Large document volumes, many tenants
The product was growing faster than the foundation underneath it.
The client needed senior engineers, not extra hands.
- Security first Every integration, backend service and processing flow had to be designed around security.
- Backend under strain Fast-grown, tightly coupled code where error handling and testing were lagging behind.
- Large documents Big files and batches were processed in waves, and the system was reaching its limits.
We rebuilt the engine while the product kept moving
DO OK joined the client’s team mid-growth and took over the backend, document processing and infrastructure.
-
Stabilise
We mapped the logic and service dependencies, then stabilised CI, error handling and tests.
-
Rebuild processing
We swapped Celery for ARQ to fit the AsyncIO backend, so large files now run in parallel.
-
Migrate data
We planned a controlled database migration and carried it out with the client’s developers.
-
Join the team
We now share decisions on architecture, testing and plugin-based integrations with the client.
A platform ready for what comes next
| Before | After |
|---|---|
| Changes were risky in a tightly coupled codebase | Stable CI, safer everyday releases |
| Large files and batches processed in waves | Large files processed in parallel |
| Heavy, costly worker infrastructure | Lighter infrastructure, same workload |
| DO OK as an external supplier | Part of the client’s product team |
Meanwhile, the client grew its customer base and entered the US market, and the platform kept pace.
DO OK didn’t just add engineers. They understood our platform quickly and helped us rebuild the parts that were holding us back, while we kept shipping.
Head of Engineering at a Scandinavian legal tech company
How the project unfolded, step by step
Built for work where every answer must be checkable
The platform serves law firms, in-house legal teams and enterprises that want AI in everyday legal work without giving up privacy, control or compliance. Explainability, security and auditability sit at the centre of the product.
Source traceability is central: a lawyer can follow any generated answer back to the material it came from. The system ingests PDFs, scanned PDFs, Word documents, TXT and CSV files, at scale and across separate tenant environments.
A product moving faster than its foundations
When we joined, the client was adding new capabilities and connecting them to its wider product ecosystem. Security dictated how every integration, service and processing flow was built.
The backend had grown quickly, and delivery needed to become more dependable. At the same time, large uploads and high-volume processing showed where the system needed optimisation.
Chosen for depth, not headcount
The client was looking for a partner senior enough to work inside a complex AI product in a demanding domain. In early technical discussions, we showed we could understand the product context quickly. Our range across backend, infrastructure and DevOps suited a team whose priorities kept shifting.
In short, the client needed more than extra developers. They needed a partner who could understand a complex product quickly.
Step one: make every change safer
In a large, active codebase, even small changes needed careful thought. We first built a clear picture of the existing logic, the dependencies between services and the constraints of a security-sensitive platform.
Then we stabilised the CI process and raised the baseline for day-to-day reliability. Everything that followed depended on being able to change the system without breaking it.
Step two: a processing engine that fits the backend
As usage grew, the Celery-based background processing began to show its limits. The backend runs on AsyncIO Python, so we replaced Celery with ARQ, a task queue built for that model.
| Celery (before) | ARQ (after) | |
|---|---|---|
| Fit with AsyncIO backend | Poor fit | Built for it |
| Concurrency | One backend worker per file | 300 files at once on a fraction of the workers |
| Infrastructure needed | Heavy worker layer | Substantially less |
Step three: data and infrastructure
A central database choice had become a poor fit as the platform evolved. We defined a controlled migration plan to reduce risk, and the client’s internal developers carried it out with us.
In parallel, we worked across backend, DevOps and selected frontend, giving production delivery and runtime operations a dependable base.
From vendor to product team
As the work progressed, DO OK became part of the client’s wider product team. Our role shifted from immediate fixes to the platform’s longer-term direction: a cleaner backend architecture, better testing and a plugin-based approach to future integrations.
What changed
The platform once struggled with documents around 50 MB; today it handles far larger ones. The worker layer runs on much less memory, and users wait less when uploading heavy document sets.
During the collaboration, the client expanded its customer base significantly and entered the US market. The platform kept pace.
Key takeaways
- Stabilise before you scale. A reliable CI made every later change safer.
- Pick tools that fit your stack. ARQ matched the AsyncIO backend; Celery did not.
- Work as one team. The biggest changes were planned by DO OK and delivered together with the client.
