The client develops software products to help Fire & EMS departments improve their response times, optimize their resources and defend their budgets.


The client already had an app that simulates and tests complex dispatch policies for Fire & EMS departments before going live. Their configuration process for the app was entirely manual and involved sparing with their in-house analysts and resources to manage and control their customers’ data which wasn’t really productive or beneficial.

Their customers used to send information to them and wait for them to update this information in the backend manually. They would then have to go to the main application, run a few simulations and verify that the data provided was accurately updated. It required a few iterations to get it right, which resulted in multiple back-and-forth emails with data and a huge turnover time for a rather simple information update.

The client needed assistance developing a builder tool for the main/parent simulator application.

  • The primary goal of this application is to create an administrative/configuration portal for their customers (i.e; Fire and EMS departments).

  • The application should enable the Fire & EMS departments’ staff to manage a lot of their internal metrics and also run simulations to look at the performance and responsiveness of each of their various teams.

  • The application should be built from scratch with custom UI similar to the parent application so that the users do not have a big learning curve for the same.


We developed the builder application as an extension of the simulator application and styled every component as per the client’s branding and style guide. This project was unique in the way it was built (i.e.) as a child application that transitions from its parent seamlessly without the user knowing that they are migrating to another application. Though the application was built independent of the parent, it was built in a way that it could be tightly coupled once it fully developed, tested, and deployed.


  • We first structured the project’s folder, and created separate code repositories for the backend and frontend individually.

  • An important aspect of the application was single sign-on so that the user who moved from the parent application to the builder application was always logged-in and did not notice moving between multiple applications. Both the backend and frontend were developed in order to make this happen seamlessly.

  • We integrated with a 3rd party called ESRI that provided multiple backend and frontend integrations to its service called ArcGIS which is used to process and render spatial data on a map layer. For frontend, the ArcGIS JavaScript API was used inside Angular components to render the maps and the various spatial data on top of them.


Here are some solutions we provided for the challenges we encountered while working on the backend of this project:

  • Working with shape files: Some of our biggest challenges with this project was related to working with shape file data. Reading shape files, transforming shape file data from one projection to another, and finding ways to get this done using C#/Postgres DB was seldom straightforward. After a lot of strategy and consulting sessions with the client, we used PostGIS for dealing with Geographic Information Systems (GIS) data. Using the PostGIS plugin for Postgres, we could read, transform, write and do many more GIS related operations.

  • Dealing with complex DB relationships: We worked with a complex DB relationship schema which was already created by the client team. We suggested several database best practices to work with complex database relationships which the client really liked and hence readily adopted not just for this project, but for all other projects within their organization.

  • Project Logging: We faced unique challenges while logging information about each call to the database. As this was introducing additional load, it led to a slowdown of the entire application. In order to address this, we implemented asynchronous logging.


  • The application empowered the client’s customers to configure the following information on their own, without having to rely on the client for the same.
    • Incident Type Groups & Incident Types
    • Unit Types & their capabilities
    • Response criteria
    • Time targets
    • Application configuration
    • Historical Scenario Creation
    • Timeframes & Exception
    • ArcGIS-related sections: response zones, stations, hospitals, streets, etc. which were then rendered/reviewed on a map view provided by ArcGIS from ESRI.
  • The client’s customers could get access to a portal where they could make frequent updates or changes to their configuration data without needing to contact the client team.
  • The client’s customers were able to review the spatial data of geographies as maps to better understand the performance of various Fire & EMS teams across any geographical segments or areas.


  • Prior to building this app, customer support associates of client’s team were constantly on calls with their customers getting information and validating them, and going through the cycle iteratively if some incorrect information was provided while updating the configuration data.
  • The builder app has enabled our client to save a lot of the man-hours they previously needed to spend on adding, updating, and removing configuration information for their customers. This tool empowers their customers to make those changes directly, without involving our client’s team and that in turn leads to huge time & cost savings for our client.


We offer custom web application development, custom software development, and mobile app development services near you.

Schedule a Free Consultation!