# Procurement Planning System - Shoham Fellner

_Case Study_

Built from scratch to replace the legacy platform behind the Ground Forces' annual budget.

- **Context:** IDF Teleprocessing Corps · via Inford-Team · 2024-2026
- **Role:** Product Engineer
- **Tech:** React, TypeScript, TanStack Query, SAP Gateway

_Interface reconstructed with generic labels and sample data. Not the production system._

## The Stakes

Roughly twenty people use this system. What they enter becomes the annual procurement plan for the IDF Ground Forces - what gets bought, what gets repaired, what sits in reserve.

The user count is not the measure here. The budget behind each line is. And it replaced the legacy platform outright rather than a module at a time, which meant the new system had to carry the whole planning process on its own from the day it went in.

## My Role

I owned frontend development inside an Agile team, along with the UX/UI process end to end - research, Figma, and the implementation that followed it - partnering with PMs and users from discovery through post-release iteration.

The backend was a separate SAP Gateway team. The data contracts between us were designed together rather than handed down, which is the reason several of the decisions below were possible at all.

## The Problem

Procurement planning is not one screen. It is dozens of interlocking views over the same catalogue: requirement tables tens of thousands of rows deep, dashboards pulling from several unrelated sources, and forms whose fields depend on what kind of item you happen to be planning for.

Any one of those, built the obvious way, stalls the entire screen. The work was deciding where to put the boundaries so that no single slow thing could take the rest of the page down with it.

## Decisions

### Every widget owns its own data

- **Constraint:** The dashboard reads from several unrelated sources, each with its own shape and its own latency.
- **Decision:** Each widget fetches, caches and parses its own data through TanStack Query, with its own loading and error state.
- **Trade-off:** More query keys to keep coherent, and a genuine “refresh everything” has to be built deliberately rather than coming for free. In exchange, one failing source degrades one widget instead of the page.

### Virtualization on the client, paging on the server

- **Constraint:** Requirement tables run to tens of thousands of rows, and planners scroll them rather than query them.
- **Decision:** List virtualization so the DOM only ever holds what is on screen, with pagination handled server-side.
- **Trade-off:** Browser find stops working across the full set, and sorting can no longer be done in the client. Both had to move to the server, which is work you sign up for the moment you virtualize.

### Forms generated from a schema, not hand-built

- **Constraint:** Which fields a planner sees depends on the material type, and the rules behind that change over time.
- **Decision:** Dynamic, schema-driven forms built on React Hook Form, so a category is data rather than a new screen.
- **Trade-off:** A level of indirection between the bug you see and the code that caused it. Worth paying once; not worth paying if the schema had been static.

### Shaping the contract instead of the response

- **Constraint:** What SAP Gateway returns naturally and what the interface needs are not the same shape.
- **Decision:** Design the schema and the data contract together with the backend team, rather than reshaping every response in the client.
- **Trade-off:** Slower to agree on, and it needs a backend team willing to have the conversation. It kept the same data from living twice in two different shapes.

## Evidence

The system itself is not public. What follows is the design work behind it, rebuilt with generic labels and sample data.

- [Each widget loads and fails on its own.](https://www.shoham-fe.dev/case-study/procurement-system/dashboard.mp4)
- [Tens of thousands of rows, constant scroll cost.](https://www.shoham-fe.dev/case-study/procurement-system/requirement-table.png)
- [Fields resolve from the material type.](https://www.shoham-fe.dev/case-study/procurement-system/schema-form.png)
- [Query boundaries between UI and SAP Gateway.](https://www.shoham-fe.dev/case-study/procurement-system/architecture.png)

## Outcome

Delivered as the replacement for the legacy platform, taken from research through to production inside an Agile cycle.

The MVP was deployed to production, with planners executing the annual procurement cycle in parallel with the legacy system to validate data integrity and workflows under real-world conditions.

## What I'd Change

I would introduce a Backend-for-Frontend (BFF) layer to offload heavy data parsing. We handled complex calculations on the client due to infrastructure constraints, which introduced unavoidable overhead to initial load times.

Additionally, rather than stretching a rigid SAP Gateway data structure to serve multiple dashboard components, I would enforce purpose-built data contracts. Reusing a single structure across too many contexts added unnecessary complexity to the client-side state.

## Other case studies

- [Live Drone Patrol Console](https://www.shoham-fe.dev/case-study/live-drone-patrol-console): Put the responding guard and the command room on the same live picture, from anywhere in the world.
- [OctSeven](https://www.shoham-fe.dev/case-study/octseven): A public platform where families build memorial pages for the people they lost. Development started two weeks after October 7th.
- [Aura Cloud](https://www.shoham-fe.dev/case-study/aura-cloud): Resolves who can actually do what across AWS, and flags where identity and policy disagree.

## Elsewhere on this site

- [Home](https://www.shoham-fe.dev/): Introduction, what I care about building, how I work, and the tech stack I reach for.
- [Resume](https://www.shoham-fe.dev/resume): Full professional timeline - roles, projects, education and skills - with a downloadable CV.
- [About](https://www.shoham-fe.dev/about): Longer-form background: how I got into frontend, the problems I like, and how I work with design.
- [Contact](https://www.shoham-fe.dev/contact): How to reach me, what I am available for, and what to include so I can answer usefully.
- [Case Study](https://www.shoham-fe.dev/case-study): Four projects in depth - the problem, the constraints, what shipped, and what I would change.
- [Privacy](https://www.shoham-fe.dev/privacy): What this site measures, which third parties see it, and how to opt out.

## Machine-readable sources

- [This page as HTML](https://www.shoham-fe.dev/case-study/procurement-planning-system): The same content rendered for browsers.
- [This page as markdown](https://www.shoham-fe.dev/case-study/procurement-planning-system.md): Stable markdown URL, served regardless of the Accept header.
- [llms.txt](https://www.shoham-fe.dev/llms.txt): Site overview and the full list of pages.
- [sitemap.xml](https://www.shoham-fe.dev/sitemap.xml): Every indexable URL.

---

Canonical HTML: https://www.shoham-fe.dev/case-study/procurement-planning-system