Building an Engineering Intelligence Platform

I am building an Engineering Intelligence Platform. It started as a personal frustration with spreadsheets and is growing into something that might serve our entire organization. Here is where it stands today.

The Problem

We have over 300 engineers across multiple accounts and projects. When a new engagement starts, finding the right people with the right skills and availability is a manual, slow, and error-prone process. Managers hoard information. Skills data lives in outdated spreadsheets. Capacity is a guess.

The Architecture

The platform is built on three layers. FastAPI serves the API layer with endpoints for capacity queries, skill searches, and delivery metrics. PostgreSQL stores structured data like project assignments, timelines, and utilization rates. Neo4j stores the skill graph — engineers, their skills, project experience, and collaboration relationships.

I am also experimenting with Qdrant for vector search over project descriptions and requirements documents. The idea is to match incoming project requirements against historical project data to find relevant team members.

What Works Today

The capacity mapping module is live and being used by three account leads. They can query available engineers by skill, see current utilization rates, and get recommendations for staffing new projects. The skill graph has data for about 150 engineers so far, manually loaded from our skills survey.

What I Am Building Next

Delivery analytics is the next module. I want to pull sprint data from Jira, aggregate it by team and account, and surface trends that help predict delivery risks before they materialize. The goal is to move from reactive reporting to proactive intelligence.

The Lesson

The best internal tools come from PMs who live the problem daily. I did not build this because I wanted to code. I built it because I was tired of making staffing decisions based on incomplete information. The platform is a means to an end, and the end is better decisions.