Forecasting platform: sole developer from the first line to daily operation

Measured from the login records, April and July 2026. In September 2026 it is 35 people within a single week, out of about 40 possible at two of three sites.

Starting point

In July 2025 I joined a mid-sized meat industry group as an AI engineer. The group operates three sites. Forecasting and planning ran in legacy systems and manual processes that had grown side by side. Each answered one question. None showed the whole picture. Anyone preparing a decision collected numbers from several places first.

My brief was an internal platform that computes forecasts, supports planning and holds up in daily use. There was no development team. I was the only developer, and I still am. That shapes every decision in this case study: whatever I build, I must be able to run alone.

Decision

Three decisions shaped the platform.

First: one system instead of many. I did not rebuild the legacy systems. I collected the questions behind them and answered them in one application. Every replacement was a step of its own with its own sign-off, never a side effect.

Second: files instead of a database server in the runtime layer. The application reads its data from columnar files through an embedded analytical database. That keeps operations simple. There is no extra database instance to maintain. A snapshot of the data can be copied, backed up and restored like a folder.

Third: operations belong in the foundation. Roles and permissions, a change log and monitoring were not planned as an extension but as part of the core. Someone who is solely responsible cannot afford security work after the fact.

Implementation

The interface runs in the browser. Behind it sits a service with 388 endpoints that serves data, checks permissions and logs every change. The runtime layer keeps the prepared data in columnar files. The data platform that fills them every working day is the subject of the third case study.

I shipped in small steps. By July 2026 there were 29 production releases. Each release delivered a finished benefit, not half a construction site. The code base is around 110,000 lines.

Roles and permissions define who sees which areas and which changes they may make. The change log records who changed what and when. Monitoring reports errors to me before a user does. These three building blocks are unspectacular. They are the reason I can run the platform alone.

I replaced the 13 legacy systems and manual processes one after another. An old tool was switched off only once the new path was in use. A large part of them were individual Excel reports that someone maintained by hand. The platform replaces them with evaluations on data as of today, some refreshed every half hour.

Result and measurement

I measure usage from the login records, not from feedback. Between April and July 2026 the number of active people per month grew from 9 to 28. There were 767 logins in 90 days. In September 2026, 35 people use the platform within a single week, out of about 40 who could at the two connected sites. Whoever logs in works with it daily, management included. The third site is still to come. 13 legacy systems and manual processes have been replaced.

What I did not measure: time saved. So I make no claim about it. Whether the platform improves decisions depends on forecast accuracy. I measured that and present it in the second case study, including the level at which the model does not beat the simple baseline.

What I would do differently

388 endpoints are too many for one person. Many grew out of individual views. I would design a smaller, more uniform interface earlier and build the views on top of it. That costs time at the start and saves it on every later change.

I would give every replacement a switch-off date from the beginning. A fixed date forces everyone involved to take the new path seriously. Without a date, the old tool stays open longer than it deserves.

I would write the operations manual from the first release instead of catching up later. As a single person I am the bottleneck. Every page I write early is one question fewer that only I can answer. The AI team I am now building is the answer to that. I should have pushed for the second person sooner.

Technology

• React
• TypeScript
• FastAPI
• Python
• DuckDB
• Parquet
• RBAC
• Audit log
• Monitoring