alignment · Nov 2024 – May 2025

A Talent-Pool Tracking App, From Scratch to Production in Two Months

Took a talent-pool tracking app from scratch to production in 2 months — React SPA over a Node.js REST API, secured with Azure AD — by turning stakeholder needs into UI flows and API contracts.

Role: Built the app end to end — stakeholder workflows, UI flows, API contracts, backend, front end, and deployment
Team: Engineering, working with cross-functional hiring and workforce stakeholders
Scope: Back-office recruitment and workforce tracking at BlackRock, plus a multi-tenant portfolio management system
Level: Software Development Engineer

Time to production

from scratch2 months

Method: Greenfield build — from first stakeholder conversations to the app deployed and in use.
Window: first 2 months

Recruitment & workforce tracking

no dedicated appreal-time

Method: Qualitative outcome: the app enables real-time recruitment and workforce tracking for back-office stakeholders.
Window: post-launch

Context

At BlackRock I was asked to build a back-office app for tracking the talent pool — recruitment and workforce data that stakeholders across functions needed to see in real time. There was no existing app to extend. It had to go from nothing to production in two months.

Start with the people, not the code

Different stakeholders had different pictures of what "tracking the talent pool" meant. On a fixed timeline, the biggest risk was building the wrong thing. So before writing code I walked through the real hiring and workforce workflows with them and turned those needs into concrete UI flows and API contracts.

Stakeholders react to screens and data shapes far better than to abstract requirements. Disagreements came up in a conversation instead of in a rewrite, and once the contract was agreed, front end and back end could be built in parallel against it.

Boring stack, thin slices

A greenfield internal app on a two-month clock doesn't need a distributed architecture; it needs to ship. I built a React SPA over a single Node.js REST API and delivered it in vertical slices — one workflow at a time, screen to API to database — so stakeholders could use and review each piece as soon as it landed.

Security without building auth

The app holds recruitment and workforce data, so it's secured with Azure AD (OAuth2/JWT): users sign in with their corporate identity, and the API validates the token on every request. The app never handles a password.

Alongside: multi-tenant portfolio management

In the same role I also engineered a multi-tenant portfolio management system with role-based access control, faster data processing, and enterprise report generation — the same habits applied to a different problem: get the access model right first, then make it fast.

What broke

My first data model stored a candidate's pipeline stage as a single current-status field. As soon as stakeholders used it, they wanted the history — who moved a candidate and when — for real-time tracking and reporting. That meant a schema change mid-build. Now I ask what reports people need on day one, because reporting requirements tell you whether you're modelling state or history.

Outcomes

The app went from scratch to production in two months, giving recruiting and workforce stakeholders real-time tracking in one place — secured with Azure AD and built on contracts clean enough to extend.

Decision Records

DR-001 · alignment

Walking through real hiring and workforce workflows with stakeholders and agreeing UI flows and API contracts up front is what made a two-month delivery possible

Context

The app had to serve recruiting and workforce stakeholders across functions, each with their own picture of what 'tracking the talent pool' meant. On a two-month timeline there was no room to build the wrong thing and iterate our way back.

Options considered

✗
Build from a written requirements list and iterate on feedback
Requirements lists hide the workflow. You discover what people actually do only after building something they can't use — expensive on a fixed timeline.
✓
Map the workflows with stakeholders, then agree UI flows and API contracts before building
Stakeholders react to concrete screens and data shapes instead of abstractions. Disagreements surface in a conversation, not in a rewrite, and front end and back end can be built in parallel against the agreed contract.

Tradeoffs

Front-loads time into conversations before any code exists, which can feel slow in week one. It paid for itself by removing rework later.

Outcome

A shared, agreed picture of the screens and the API contract that front end and back end were built against.

DR-002 · architecture

A React SPA over a single Node.js REST API — delivered slice by slice — was the fastest safe route to production

Context

Greenfield internal app, small team, fixed two-month window. The risk wasn't scale; it was not shipping.

Options considered

✗
Split into multiple services from the start
Adds deployment, networking, and coordination overhead for no benefit at this scale and timeline.
✓
One React SPA and one Node.js REST API, built in end-to-end slices
Fewest moving parts. Each slice — a workflow from screen to API to database — was usable and reviewable by stakeholders as soon as it landed.

Tradeoffs

A single API will need to be split if the app grows a lot. That's a good problem to have later, and the agreed contracts make it tractable.

Outcome

Working features reached stakeholders continuously instead of all at the end.

DR-003 · architecture

Using Azure AD with OAuth2 and validating JWTs at the API gave enterprise-grade access control without building any auth ourselves

Context

The app holds recruitment and workforce data. It needed proper authentication and authorization, and building a bespoke login system would have been both slower and riskier.

Options considered

✗
App-level username and password accounts
Another credential store to secure and audit, and a worse experience for users who already sign in with corporate identity.
✓
Azure AD sign-in (OAuth2) with JWT validation on every API request
Users sign in with existing corporate identity; the API trusts only validated tokens. No passwords handled by the app.

Tradeoffs

Depends on getting the identity-provider configuration right, and local development needs a working token flow. Far less risk than custom auth.

Outcome

Every API request is authenticated against Azure AD-issued tokens.

Where I Got It Wrong

Failure 1

An early data model stored each candidate's pipeline stage as a single current-status field; once stakeholders saw it, they needed the history — who moved a candidate, and when — for real-time tracking and reporting

Cost: A mid-build schema change and rework on the screens and endpoints that read status

Lesson: Ask what reports people need on day one — reporting requirements tell you whether to model current state or history, and that's much cheaper to learn in a workflow walkthrough than in a migration

Long-Term Impact

Gave recruiting and workforce stakeholders one real-time view of the talent pool, built on contracts clean enough to extend.