Talix Project
About the project :
Talix is a graduation project developed within the Faculty of Information Engineering at Damascus University by Mohamad Arnaout, a Devista employee. Mohamad shared the project’s journey, development process, and key insights with us as part of an article highlighting the experience behind Talix.
Talix is a project management platform that uses AI to run the discovery phase of a software project — the earliest and messiest part, where a client describes an idea and a team has to turn it into something buildable.
Most delivery problems in software start here. Requirements are gathered in scattered meetings, written down inconsistently, and misunderstood downstream. Our objective was to shorten the distance between "a client explains what they want, in their own words" and "the team has an approved specification, wireframes, and a sprint-ready backlog."
In Talix, a client is interviewed by an AI agent — by chat or by live voice — and can upload existing documents (PDF, Word) as context. The system extracts structured requirements from that conversation and generates three things the team then reviews, edits, and approves: Proposal , a set of interactive wireframes, and a product backlog of epics, stories, and tasks. Around that core sits the delivery side of the platform: sprint boards, work items, a GitHub integration, team chat, a calendar, change requests, and document approval workflows — so a project stays in one place from the first conversation to the last pull request.
The key design decision was that the AI drafts, humans decide. Nothing generated goes live without a person reviewing and approving it.
How it was done :
We worked in an agile cycle over roughly eight months, with ticketed tasks, a branch per ticket, and mandatory pull-request review before anything merged.
Research and scoping
We studied how a real software company actually runs discovery — the stages, the artifacts, and the approvals — and mapped that process into product requirements before writing code.
Architecture first
We committed early to Clean Architecture with a CQRS pattern, so every feature is an isolated use case with its own validation and authorization. This kept a large, fast-moving codebase from turning into a tangle as the team grew.
Feature slices in parallel
The backend and frontend were both organized into vertical feature slices, which let five developers work on separate modules at the same time with minimal collisions.
An AI pipeline, not a single prompt
The AI work was built as a chain — prompt builder, model call, response parser, requirement extractor — with conversation state cached so long interviews stay coherent. Prompts were tuned iteratively against real conversations rather than written once.
Testing and deployment
Unit, integration, and functional tests ran against a real containerized database. The platform is containerized with Docker and deployed to Azure through infrastructure-as-code and a CI/CD pipeline.
How Devista Helped :
Devista sponsored the project and stayed involved throughout every sprint. Their support went well beyond funding: they gave us a budget that covered everything the project needed and, more importantly, provided us with dedicated mentorship.
Devista assigned a Project Manager and a Solution Architect as mentors to guide us throughout the project, with Marius Ceobanu, Georgi Georgiev and Odai Alokeh supporting and advising us along the way. At the end of every sprint, we presented our work to them, received their feedback, and used it to improve and shape the next sprint.
What made that mentorship particularly valuable was that it covered both the technical and business sides of the project. On the technical side, we received guidance on our architecture, technical decisions, and implementation from people with real-world experience building production systems. On the business side, we were challenged with questions that students do not always get asked: Who is this for? What problem does it actually solve? Is this feature really worth building?
Having both technical and product perspectives in our sprint reviews meant that our decisions were not judged only by whether they were technically elegant — they also had to make sense as a real product.
That sprint-by-sprint mentorship and feedback loop is a major reason Talix evolved into a real product rather than remaining an academic prototype. It helped us correct our direction early, make better decisions, and, perhaps most importantly, learn how to explain and defend our choices to experienced professionals.
Mohamad's Contribution:
He contributed to Talix across three main roles:
Full-Stack Developer — developed features across both the frontend and backend, worked with the database and APIs, and integrated different parts of the system into a functional product.
AI Engineer — worked on the AI-powered parts of Talix, including the requirements assistant, AI-generated documentation and backlog, RAG and document processing, embeddings, and AI integrations.
Project Manager — took responsibility for planning and coordinating a sprint, breaking down requirements into actionable tasks, following progress, coordinating the team, and making sure the sprint goals were delivered.
Working across these three roles gave me a broader perspective on the project — from how the product should work, to how it should be built, to how the team should deliver it.
What Was Learnt :
This project taught me that building a real product is much more than writing code.
Technical depth — strengthened my Full-Stack development skills and learned how to work with a larger, more complex system from frontend to backend and infrastructure.
AI in real products — gained practical experience designing and integrating AI features, working with RAG, document processing, embeddings, and AI-driven workflows.
Architecture & decision-making — learned how to make technical decisions based not only on what can be built, but on what is scalable, maintainable, and actually useful.
Project Management — learned how to plan a sprint, break down work, coordinate a team, manage priorities, and take responsibility for delivery.
Product thinking — learned to question every feature: Who needs this? What problem does it solve? Is it worth building?
Working with mentors — learned how to present our work, receive critical feedback, defend our decisions, and turn feedback into concrete improvements.
Ownership — learned to take responsibility for outcomes rather than only completing assigned tasks.
Author: Mohamad Arnaout is a software professional at Devista with experience in software development, business analysis, and project management. He is passionate about designing practical technology solutions that improve processes, enhance collaboration, and deliver business value.
