A dedicated team, not an augmentation
The client didn't add a few Azati engineers to an existing roster, they stood up a new, focused team of specialists matched to the stack and the specific modules that needed building.
Technologies used
TypeScript
React
MobX
Ant Design
Storybook
Motivation
A large multi-industry technology holding company was building an internal enterprise task and project management platform intended as a domestic alternative to Jira and Confluence. Development spanned multiple parallel teams and vendors, each responsible for distinct parts of the system, all integrating into one application built on a shared architecture.
Business challenges
Challenge 01
Building modules for a platform several other teams were changing at the same time
With multiple vendors and internal teams working on different parts of the same application simultaneously, coordinating scope and avoiding conflicting changes required constant attention:
- Multiple parallel teams developing different parts of the same platform
- Integration handled by the client's core team, not Azati directly
- Shared architecture and UI kit requiring strict adherence across teams
- Coordination overhead to avoid conflicting or duplicated work
#1
Challenge 02
Keeping architecture consistent across independently developed modules
Following Feature-Sliced Design and a common UI kit was not optional. Every module had to integrate cleanly into a system being extended by teams the developers didn't work alongside day to day:
- Feature-Sliced Design architecture followed strictly across modules
- Shared UI kit and internal standards maintained without central oversight of every team
- Integration scenarios needing to be anticipated in advance, not discovered at merge time
#2
Challenge 03
Requirements that changed as the product evolved
Business logic was refined throughout the engagement as the platform's scope became clearer, which meant some already-built functionality had to be adapted mid-development:
- Business requirements clarified and adjusted as the project progressed
- Business logic changes requiring rework of functionality already in progress
- Balancing responsiveness to change with keeping delivery on schedule
#3
What this engagement demonstrates about enterprise frontend delivery
Modules that integrate cleanly into someone else's platform
Delivering functionality that a different team, the client's core team, integrates into a shared codebase requires discipline that self-contained project work doesn't demand. Every module had to be architecturally clean enough to merge without special handling.
Real Jira-adjacent domain knowledge
Building task cards, custom fields, epic and story dependency structures, and filtering systems for a Jira-style platform requires understanding how these systems actually get used at scale, not just how to build a form.
FSD and a shared UI kit as working discipline, not documentation
Feature-Sliced Design, a common UI kit, and internal project standards were followed as day-to-day working constraints across every module Azati delivered, which is what made parallel development by multiple teams actually work.
Building an enterprise platform with multiple teams in parallel?
Azati can stand up a dedicated frontend team that builds cleanly integrable modules inside your existing architecture, without duct-taping onto your core team.
Build my platform's frontend modulesWhat Azati's team built
Azati's scope centered on the task entity and the mechanisms around it: how a task is structured, how it can be customized, how it's filtered, and how it relates to other tasks.
01
Task card entity development
The task card is the core object users interact with constantly. Azati's team developed and extended this entity, adding structure and functionality that the rest of the platform's task-related features built on.
Key capabilities:
- Task card entity structure and development
- Ongoing extension as platform requirements evolved
- Integration-ready design for the client's core team
02
Custom fields, including computed fields
Beyond standard fields, the team implemented computed fields, values derived automatically from other task data rather than entered manually, extending what users could configure and track on a task without added manual effort.
Key capabilities:
- New custom field type implementation
- Computed fields deriving values from other task data
- Field logic integrated into the task entity
03
Task filtering system
Large project spaces with many tasks need reliable, flexible filtering to stay usable. Azati built the filtering functionality that let users narrow down task views across large datasets.
Key capabilities:
- Filtering logic across task attributes
- Support for large-scale project spaces
- UI and business logic for filter configuration
04
Epic and story category logic
The team designed and implemented the dependency structure between task categories, epics and stories, similar in concept to Jira, giving the platform a way to represent hierarchical relationships between work items.
Key capabilities:
- Epic and story category modeling
- Dependency structure between task categories
- Board-level representation of task relationships
05
UI components and documentation
Components were built on Ant Design and documented in Storybook, supporting reuse across the modules Azati delivered and giving other teams a clear reference for how components were meant to be used.
Key capabilities:
- Ant Design-based component development
- Storybook documentation for delivered components
- Reusable UI components aligned with the shared UI kit
What Azati built
| Area | Azati contribution |
|---|---|
| Task entity | Developed and extended the task card entity |
| Custom fields | Implemented new field types including computed fields |
| Filtering | Built the task filtering system for large project spaces |
| Categories | Designed epic and story dependency structure |
| UI components | Built components on Ant Design, documented in Storybook |
| Code quality | Participated in code review, refactoring, and defect fixes |
| Architecture | Maintained Feature-Sliced Design across all delivered modules |
Security
Development took place within the client's corporate perimeter, following internal security processes. Source code was managed in GitLab, with mandatory code review required before any change was integrated.
How the engagement was delivered
A Fixed Price engagement with a dedicated team
Azati staffed a dedicated team, including a frontend developer, business analyst, and project manager, working on a Fixed Price basis alongside the client's core team and multiple other vendors developing different parts of the platform.
Agile delivery inside a shared architecture
The team worked in an Agile model, adapting to evolving requirements while maintaining the architectural discipline the multi-team environment required:
- Agile delivery with regular adjustment to evolving business logic
- Feature-Sliced Design followed as the shared architectural standard
- Modules developed independently, then integrated by the client's core team
What came out of the engagement
Functionality that became part of the live platform
The modules Azati built, the task entity extensions, custom fields, filtering, and epic and story logic, were integrated into the main application and used by other teams going forward, not built and shelved.
Computed fields and entity dependency modeling delivered
Two specific technical contributions stood out: implementing computed fields on the task entity, and designing the dependency scheme between task categories on the board, epics and stories, modeled after how Jira represents these relationships.
Expertise retained past the engagement
Some of the business analysts who worked on this engagement remained with the client afterward, a signal of the working relationship's strength beyond the immediate deliverables.
Deep experience in large-scale, modular enterprise frontend delivery
The engagement strengthened Azati's expertise in React, TypeScript, MobX, Feature-Sliced Design, Storybook, and reusable component organization, along with practical experience designing complex task entities, custom fields, and filtering mechanisms at enterprise scale.
Strategic wins
What this engagement demonstrates:
Multi-vendor platform delivery requires architectural discipline, not just good developers
When several teams are building different parts of the same application in parallel, the shared architecture, in this case Feature-Sliced Design and a common UI kit, is what actually makes that possible. Good code that ignores the shared standard still breaks the system.
Domain-specific complexity hides inside "simple" features
A task filter or a custom field sounds simple until it has to work reliably across a platform with epics, stories, computed values, and thousands of tasks. Real Jira-scale complexity lives in the details of these systems, not in their surface description.
Standing up a dedicated team beats partial augmentation for scoped modules
For clearly bounded functional modules within a larger multi-team effort, a dedicated team matched to the stack integrated more cleanly than adding individual contributors to an existing roster would have.
The described expertise is relevant for
- Enterprise task and project management platform development
- Feature-Sliced Design architecture for large frontend applications
- Custom field and computed field implementation
- Task filtering systems for large-scale project data
- Epic and story dependency modeling
- React, TypeScript, and MobX frontend engineering
- Multi-vendor, multi-team enterprise platform delivery
