Flavio Espinoza

The Elasticsearch Data Store and JDBC Ingestion — The speed layer -- and, to be clear about ownership, the part the back-end/database team built, not my team. It is the foundation everything I built sat on.

1. A.Indexed cache, not the system of record -- Elasticsearch held a denormalized, query-optimized copy of the data, so aggregations over the full dataset returned in near real time where the relational databases could not. The legacy report was slow precisely because it queried the relational sources live.
2. B.JDBC ingestion -- a JDBC architecture continuously translated relational rows (and Salesforce data) into JSON documents and indexed them, so the store stayed current without anyone re-running an hour-long report.
3. C.Incremental, not full reloads -- after a brutal first full population, the pipeline moved to small, frequent incremental syncs (down to roughly every five minutes), which is what made the dashboard feel live.

The Pivot Dashboard and Faceted Analytics — The front door, and the thing executives actually used. An Angular single-page app that turned the Elasticsearch store into an interactive pivot table: click to filter, and every chart recomputes instantly.

1. A.No designer on the team -- there was no UX/UI designer, so the entire interface was mine. I designed the whole thing: the layout, the interaction model, and the color scheme. I owned how Mercury looked and felt, not just how it worked.
2. B.Facets as buckets -- every dimension is a clickable "bucket" button; click one and it pins to the left rail and fires a fresh Elasticsearch query, so a user composes a view (country to state to city, by office, by sales manager) one click at a time, with no page reloads.
3. C.The analytics dimensions -- installs broken down by sun hours, system size, estimated production, module count, customer age, and rate per kWh, each rendered as a D3 donut plus a histogram, filterable by state, city, and office.
4. D.Operational truth -- a user could see at a glance which accounts were producing power versus which were still waiting on a final inspection from a local building department -- the difference between booked and billable.
5. E.Custom D3, not a chart library -- the donuts, histograms, and rank tables were built from scratch in D3 so they could all redraw together off a single query result.

The Sales Leaderboard — Vivint Solar's sales force was door-to-door, and the leaderboard made performance a live scoreboard.

1. A.Reps ranked "baseball-card" style -- each card showed active deals, installs, kW installed, and installs scheduled, ranked across the org.
2. B.Drillable like everything else -- the same facet model applied, so a regional or district manager could filter the board down to their own people.
3. C.Part of the IPO story -- showing not just totals but the depth and consistency of the sales engine was exactly the kind of thing the company put in front of investors.

Save and Share Reports — The win I am proudest of, and the one that shows how I think. The new (non-technical) CTO loved Mercury but wanted to save a pivot and send it to someone. At first that meant a developer hand-building each custom report and redeploying -- and deploys were painful back then (no CI/CD; some days we shipped three times just for this).

1. A.The insight -- a pivot is not a screenshot, it is a JSON object. Every click was just building an Elasticsearch query in JSON. So "save this report" did not need a new deploy; it needed to persist that JSON. I put it to our VP of Engineering: "Couldn't we just save this on a MongoDB database?" His reply was, "I can't believe I didn't think of that."
2. B.The build -- we added a Save button: name the report, write its query JSON to MongoDB, done. No redeploy, no developer in the loop. The thing that used to require a deploy now took a click.
3. C.Share by link -- copy a saved report's link from a dropdown and email it; an authorized recipient opens Mercury straight to that report. The route carries no query parameters, so the platform resolves the saved query server-side instead of exposing it in the URL. Dallin, my lead developer, built that resolution layer.
4. D.Why it is the story -- I am not a computer-science graduate; I trained as a building architect. The value I add is seeing the structure under a problem -- here, that "save this report" was really "persist this JSON" -- and that reframing turned a redeploy-every-time chore into a one-click feature.

Identity and Access Control — Every view in Mercury is scoped to the person looking at it. Getting that right was the difference between a sales tool and a data leak.

1. A.Session-based auth -- login ran on Express and Passport.js (company email and password), with the authenticated session -- not the URL -- deciding what a user could see.
2. B.Lessons learned from our parent company -- a backend developer who came over from Vivint Inc told us about how an internal user could reach records they were not entitled to by manipulating an identifier in the URL. We made sure ours was secure: identity is derived server-side from the session, and sensitive identifiers never ride in the URL.
3. C.Scoped impersonation for support -- a deliberate, authorization-gated support tool let an admin view a specific rep's data (pick the rep from a dropdown, under your own login) to debug "my Hawaii sales are not showing up" issues for reps working across several states. It is a support feature run under the admin's own identity, not a way to become another user.

What this project shows — Mercury is the project where I learned that my edge is not the credential. I did not come up through a computer-science program -- I trained as a building architect -- and what I bring is the ability to see the structure under a problem and act on it. A partner at my first architecture firm once wrote that I "consider the broad ramifications of a project even while working on the smallest detail," and that is exactly the move that turned "save this report" into "persist this JSON," and an hour-long static report into a live, shareable analytics platform that helped take a company public. I led a small team of junior developers, taught myself Node in a weekend to do it, and owned the surface that executives, auditors, and investors actually touched.