Complied

Objective

All companies, private and public, have compliance requirements. PE/VC fund managers and accounting firms follow up with their clients periodically to ensure such compliance tasks get done on time. Given the strict timelines, to-and-fro paperwork and repetitive nature, our client wanted to build a cloud-based task management system focused on statutory compliance.

The summary of requirements is listed below.

1. Target users are firms (sole-traders and partnerships), companies (private and public) and auditors (PE/VC/CA/CS firms).
2. Auditors can create and assign compliance tasks across companies. These tasks usually have a set due date and recurrence.
3. Companies will have two types of roles - compliance officer with administrative access and collaborator with limited access.
4. Compliance officers receive tasks assigned by auditors. They can have conversations, attach necessary files and even invite other members from their organisation.
5. Compliance officers can create to-dos internal to their organisation that are NOT visible to auditors and vice-versa.
   
6. All collaborators receive email notifications about upcoming and overdue tasks.
   
7. Auditors can see a health report of organisations and can export this data into PDF or XLS formats.
   
8. The application must have built-in presets for the most common type of compliance tasks. E.g., Income tax filing, Service tax filing, Professional tax filing, etc.
   

Our solution

We had multiple discussions with the client to get a deeper understanding of the problem. After which, we chose the following stack,

1. MySQL - the most popular open-source RDBMS considering data integrity and reporting.
2. PHP - popular open-source web programming language considering the ease of hiring new developers in future.
   
3. Kohana - an easy to learn and flexible PHP framework.
   
4. ZMQ - an async messaging library for implementing chat and notifications.
   
5. Bootstrap - a popular front-end framework to help speed up development by reusing most basic elements.
   
6. jQuery - a popular javascript plugin to quickly manipulate DOM elements.
   
7. Handlebars JS - a clientside templating library to turn JSON data into HTML in browser.

The Process

We started by defining the atomic task - what attributes it can have, how many different types there need to be and which fields could be optional (depending on the type).

We refined the task structure by iterating it through multiple real-world examples and verified if it was fit for presets.

After finalising the task structure, we revisited the workflow diagrams from our early discussions with the client. We understood how the tasks behaved with each of the roles and what states they could be in at a given time. This understanding helped us in writing well-defined user stories for development.

Development

Given the complexity of the system, we decided on having three streams of work happening in parallel.

Front-end

1. Design screens for every step in every workflow.
2. Turn approved designs into functional interfaces.
   
3. Implement client-side validations where applicable.
   
4. Communicate to the back-end through HTTP/AJAX requests.
   
5. Listen to incoming messages through web sockets and handle them appropriately.
   

Back-end (PHP)

1. Define service classes for every model.
2. Implement business logic like validations, authentication, push notifications, cronjobs for automated tasks, etc.

Back-end (Database)

1. Data modelling.
2. Identify performance bottlenecks in complex queries and perform query optimisation.
3. Find solutions outside the CRUD functionality provided by the ORM to improve performance.

Challenges

Creating and managing recurring tasks was the most challenging feature. To understand the complexity, here's an example.

1. Chetan is the compliance officer for the company "ABC Logistics". 
2. The company's auditor Arun assigns him a task - "Income tax advance payments" with due-date recurring every quarter.
3. Chetan, in turn, delegates the tasks to any other collaborator within his company.

For this use-case, the application must create instances of this task for each quarter and assign them to Chetan. The application must keep track of the comments, attachments, collaborators and other activity (like due-date changes) for each instance. That way, in a few years, Chetan can see the previous quarters' tasks and the tasks for upcoming quarters.

During the first few trials, we noticed performance problems whenever we created a recurring task. To the end-user, the application felt unresponsive for a few seconds before returning to its normal state. After many iterations and query optimisations, moving a critical portion of the logic to MySQL procedures fixed this. The response seemed almost instantaneous.

Reception

Complied is one of the most complex systems we've ever developed. We had questions throughout the development phase, some of which our client had not thought about initially. However, we resolved them all with intense collaboration across the team and with the client. We also managed to deliver the project on-time and on-budget. Our client, happy with the project outcome, has been recommending us since.