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
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.
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