Datics AI
← All work

Dealership call center operator

A dealer call center's slow app traced to its queries and fixed

An outsourced call center for car dealerships ran its agents, appointments and call logs on an inherited app that had slowed down. We traced the slowdown to specific queries and one shared server, then shipped the fixes with the founder's approval.

Automotive & DealershipsCall center operations appModernized a live product

Reviewed
A live Laravel and MySQL app we did not build
Causes found
N+1 queries, missing indexes, one shared server
Options offered
Three, from a quick resize to high availability
Fixes
Shipped, each one approved by the founder

The challenge

The app the founder called the heartbeat of the business had slow dashboards, leaderboards and call log pages, and no change could reach production without his approval.

What we did

We set up least privilege access, reviewed the server, code and schema read only, and chose a middle path: a separate database server plus targeted indexes and query fixes.

The outcome

The fixes from the review went live in stages, each with validation steps and a rollback plan, and nothing reached production without the founder's approval.

The starting point

The client runs a business development center that sets appointments for car dealerships. Its web app, built by a previous developer, tracks agents, dealers, appointments and RingCentral call logs, with dashboards, agent leaderboards and a reminder that emails agents who stay off the phone too long.

What had to change

Dashboards, leaderboards and call log pages had become slow, and the server was under provisioned. A call report used for payroll could only be run from the command line by a developer.

What could not break

  • No downtime and no production change without the founder's approval
  • The previous developer was only partly available for handoff
  • Access only through the client's own AWS, GitHub and RingCentral accounts
  • Agents keep working in the app throughout the review

The calls we made

We treated it as a system we had to understand before we could change it: access first, a read only review second, a plan the founder could approve third.

  1. 01

    Least privilege access before anything else

    Access had first been shared through the AWS root account, so we asked for an admin user of our own and worked only through it.

    Ruled out

    Working day to day through the root account.

  2. 02

    Read before we change

    We reviewed the server and the code, extracted the schema and drew an ER diagram of the appointments, users, dealers and call log tables before proposing any change.

    Ruled out

    Quick fixes on a production system we had not built.

  3. 03

    Look at the code and the server together

    The slowdown had two causes: the app and MySQL shared one small server, and the code ran N+1 queries, lacked composite indexes and packed every call timestamp per agent into one string parsed in PHP.

    Ruled out

    Treating it as a server size problem alone.

  4. 04

    The middle option, with a way back

    Of three AWS options, we recommended moving the database to its own managed server and enlarging the app server, alongside the query fixes, in a short low traffic window with validation steps and a rollback plan. That is the plan that shipped.

    Ruled out

    A full high availability rebuild before the basics were fixed.

  5. 05

    AI work waits for the foundation

    The founder also wanted an AI system to assign daily work to agents and a payroll report screen. We turned both into scoping questions and kept them out of the first iteration.

    Ruled out

    Building AI on top of an app that was already struggling.

How the system fits together

daily workreportscall logsshares oneserverinspectedcauses founddatabase movedCall center agentsCalls, appointments,leaderboardsFounder and managersDashboards and payrollreportLaravel web appDashboards, leaderboards,call logsRingCentralCall data for every agentOne EC2 serverApp and MySQL side by sideRead only reviewServer, code, schema, ERdiagramStaged fixesIndexes, query fixes,rollback readySeparate databaseserverManaged MySQL on its ownserver
PeopleClient's existing systemOutside serviceBuilt by DaticsData storeThe app and its database shared one server; our review mapped both, and the approved plan moved the database out alongside the query fixes.

What we built

01

Access set up the safe way

An admin user of our own in the client's AWS account in place of the root login, plus access to the code on GitHub and the RingCentral data.

02

Server, code and schema review

A read only review of the production server and the Laravel code, with the database schema extracted and an ER diagram of the core tables.

03

Diagnosis down to the query

Named causes for the slow pages: N+1 queries, missing composite indexes, one query that packed every call timestamp per agent into a single string, and one undersized shared server.

04

The fixes, shipped

Three upgrade options with downtime estimates, a revised scope for the middle one, and then the fixes themselves, released with validation steps and a rollback plan ready.

How it works

Get access

We work through our own admin user, never the root account.

Read

We review the server, code and schema without changing anything.

Diagnose

We tie each slow page to its query, index or server cause.

Propose

We offer options with downtime, validation and rollback for the founder to choose.

Ship

The approved fixes go live with validation steps and a rollback plan ready.

A closer look

Review findings, as summarized for the founder (sample wording)Sample data
Area            Finding                                        Proposed fix
Dashboards      One query per agent in a loop (N+1)            Load related rows together
Leaderboards    Missing composite indexes on busy tables       Add targeted indexes
Call logs       Every call timestamp per agent packed into     Refactor the query, stop
                one string, then parsed in PHP                 parsing in PHP
Server          App and MySQL share one small server           Separate database server,
                                                               larger app server
Rollout         Low traffic window, validation steps           Rollback plan ready
Approval        Nothing changes until the founder approves

What changed

The fixes from the review shipped: the slow dashboards, leaderboards and call logs were traced to specific queries, missing indexes and a shared server, and the approved plan went live in stages. No change reached production without the founder's approval.

Under the hood

Datics role
Modernized a live product
Existing system
A Laravel and MySQL app on a single AWS EC2 server, with RingCentral call data, Bugsnag error tracking and a command line call report for payroll.
Deployment
The database moved to its own managed server with automated backups and monitoring, and a larger app server, cut over in a short low traffic window.
Access boundary
Work only through a dedicated admin user in the client's AWS account, with no production change without the founder's approval.

Cloud and infrastructure

AWS EC2Amazon RDS

Also in the stack

LaravelPHPMySQLRingCentralBugsnag

How it shipped

  1. Access

    Least privilege access to the client's AWS, GitHub and RingCentral accounts.

  2. Read only review

    Server, code and database review, the schema extracted and an ER diagram drawn.

  3. Options and plan

    Three AWS upgrade options with downtime estimates, then a revised scope for the middle option with query and index work.

  4. Fixes shipped

    The approved fixes went live in a low traffic window, with validation steps and a rollback plan ready.

The owner approves every change

The founder set the rule that nothing in production changes without him, and every step of the plan was written to wait for his approval.

Plain options, not one answer

We gave three upgrade paths with their trade offs and recommended one, so the founder could choose with the costs of downtime in view.

What this unlocked

With the foundation fixed, the same review sets up the AI work the founder wants: assigning each agent's daily work by tier and lead type.

Related work

Have a product with the same kind of constraints?

Tell us what already exists and what you want it to do. We will tell you what it takes.

Book a 30-minute Product Review