Selected work

Case study 01 / Enterprise systems · Project leadership

Rahtal.

Connecting organizational work, priorities, and performance through software that fits the way teams operate.

Project lead · Data scientist · Full-stack

PythonHTTPXREST APIsMCPDjangoReact

Overview

The context behind the code.

Rahtal is an enterprise management platform concerned with organizational alignment, priorities, and day-to-day work. I lead the project day to day: I work with the product owner, hold the overall design, and run the meetings where we decide which features to add and how.

The problem

The problem

Enterprise workflows rarely stop at one interface: people need to find their tasks, understand context, and record work through connected tools. That integration must respect the existing API contract, authentication lifecycle, and the difference between a safe read and a consequential write.

Architecture

Architecture

The public companion separates an HTTP client, authentication, task and performance services, and a small MCP interface. It connects to the existing Rahtal API as an independent application, with tokens kept in process memory and response errors translated at the boundary.

SYSTEM OVERVIEW
Connected tools01
Integration services02
Rahtal API03
Enterprise workflows04
Conceptual view · Read the case study for implementation context

The Rahtal platform itself is a private company system. The public source is the integration companion, the first version of a planned in-product agent; the diagram shows that integration boundary.

My contribution

My contribution

Besides leading the project, I am its data scientist and work on it as a full-stack developer. I also design the AI features planned for Rahtal: SageQL, my open-source reporting SDK, is one of the products we plan to build into it, and my public integration companion is version 0.1 of an in-product agent. The companion shows the engineering concerns in code: explicit service boundaries, authenticated API access, and focused tests around task retrieval and performance submission.

Engineering challenges

Engineering challenges

An expired session, malformed response, and an unavailable server need different handling. Performance submission also introduces ambiguity when a network failure follows a write, so the integration deliberately avoids automatically retrying an uncertain submission.

Engineering reflections

Engineering reflections

A failed read and an uncertain write are different responsibilities, and an integration should treat them differently: a read can simply be retried, while a write that may already have happened needs a deliberate decision.

Technology

The tools behind the work.

  • Python
  • HTTPX
  • REST APIs
  • MCP
  • Django
  • React
Next case studyDanobin