Skip to content
Experience

Juristic · Engineering case study

AI imports that never block

Turning AI-assisted document imports into a persistent background workflow.

My role
Engineering ownership of the asynchronous workflow and its backend foundation
Team
Full-stack Developer in a seven-developer product team
Technologies
TypeScript · AdonisJS · Python · LLM integration · Background jobs · WebSockets

Import job lifecycle · target design

  1. Uploaded

    The user keeps working

  2. Processing

    Background job with live progress

  3. Ready for review

    Preview for the initiating user only

  4. Approved

    Executes exactly once

  5. Imported

    Nothing lands before approval

Survives the tab

Refresh, navigate or close the browser; the job continues.

Reopen for free

Opening a finished proposal never triggers a new model run.

Expires politely

Ready proposals provisionally expire after seven days.

Backend foundation implemented. The review interface is still being built.

01The problem

What was wrong, and why it mattered.

Importing a document with AI could block users while a language model produced a board proposal. The redesign lets people keep working while processing runs in the background, with the proposal waiting for their review.

My responsibility

I am driving the asynchronous design and have implemented its backend foundation, with the complete frontend workflow still in development.

02Constraints

What the solution had to respect.

  • Nothing is imported until the initiating user approves
  • Jobs survive navigation, refresh and closing the browser
  • Several imports can run at once, each uniquely identified
  • Sensitive previews reach only the initiating user
  • Authorization holds across organisations, boards and users
  • Reopening a finished proposal never starts another model run
  • An approved proposal can never execute twice
  • Document content stays out of shared real-time events and logs
  • Existing Word and Excel imports keep working

03Technical approach

How I am building it.

  1. 01Persisted import jobs and proposals server-side
  2. 02Reused the existing progress infrastructure
  3. 03In-app notifications for the first version, email later
  4. 04Ready proposals provisionally expire after seven days, within existing retention policies

04Decisions and trade-offs

The calls that shaped it.

  1. 01

    Persist the job, not the tab

    Jobs and proposals live on the server, independent of the browser session.

    The trade-off

    A lifecycle and clean-up to manage, in exchange for work that survives refreshes and closed tabs.

  2. 02

    Approval is a one-way door

    Approving a proposal is idempotent and executes exactly once.

    The trade-off

    Explicit state transitions and guards, so retries and double clicks can’t import twice.

  3. 03

    Private by design

    Previews go only to the initiating user; content and instructions stay out of broad events and logs.

    The trade-off

    Debugging relies on non-sensitive status signals rather than payloads.

  4. 04

    Reuse before building

    Existing progress infrastructure and in-app notifications first.

    The trade-off

    Email notifications wait for a later version; the first version ships sooner.

05Systems touched

Across the stack.

  • Import interface
  • API gateway
  • Background jobs
  • Python AI services
  • Real-time progress
  • Notifications
  • Authorization

06Outcome

Where it stands.

The backend foundation is in place. The review interface and complete workflow are still being built.

Described at a public level of detail. No customer names, internal identifiers or proprietary code.