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

Measured from the login records, June to September 2026. The jump in September comes from the third site, connected since the end of August.

Starting point

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

My job was an internal platform that computes forecasts, supports planning and holds up in daily work. There was no development team. I was the only developer, and I still am. That shapes every decision in this project: whatever I build, I have to 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 acceptance, not 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 analytics database. That keeps operation simple. There is no extra database instance to maintain. A data state can be copied, backed up and restored like a folder.

Third: operation is part of the foundation. Roles and permissions, a change log and monitoring were not planned as add-ons but as part of the core. Whoever 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 delivers data, checks permissions and logs every change. The runtime layer holds the prepared data in columnar files. I describe the data platform that fills them every working day in project C.

I shipped in small steps. By July 2026 there were 29 production releases. Every release delivered a finished benefit, not half a construction site. The code comprises about 110,000 lines. During a major version upgrade of the service in September, 5,390 tests passed.

Roles and permissions define who sees which areas and who may change what. In September I rebuilt the permission model. Before, every page was hard-wired to one team in the code. Two levels per department were not possible that way. Now every permission carries its own areas, pages and write rights, and department admins maintain them in the interface. Before the switch, a check script compared the old and the new model for each of the 34 users. Result: zero differences, live the same day. Since then users request permissions themselves in their profile. Of 49 requests, 47 have been approved.

The change log records who changed what and when. Monitoring reports errors to me before a user does. These building blocks are unspectacular. They are the reason I can run the platform alone.

I replaced the legacy systems and manual processes one after another, 13 by July 2026. An old tool was switched off only once the new path was in use. Many of them were individual Excel reports maintained by hand. 8 more have been added since, 21 in total. The daily list of open items from accounting is now a report in the platform. One page replaces seven Excel reports from livestock settlement that were built by hand after every weekly close. I checked it against the templates: all 52 rows of the weekly report match exactly. The feedback from the business user was live the same day.

The platform does not just show numbers, it also weighs them correctly. Sales analysis used to be entirely revenue-centred. In the meat industry that misleads, because a premium cut carries the cheaper ones. Revenue and cost were both available but never joined. For 86 percent of the kilograms sold there is a planned price accurate to the week. That makes the contribution margin computable, and a new page ranks customers and articles by it. The result contradicts the revenue view: two customers that are almost level in revenue contribute very differently.

Result with measurement

I measure usage from the login records, not from feedback. In June 2026, 18 people were active in the month, in July and August 23 each, in September 54. The jump in September comes from the third site, connected since the end of August. In 90 days 60 people logged in, 1,074 times in total. There are 67 personal accounts. 11 people were active on at least 27 days, so almost every working day. In those 90 days 44 bug reports came in from daily use. To me that is a good sign: people who report something work with it.

What I have not measured: time saved. So I do not claim any. Whether the platform improves decisions depends on forecast accuracy. I measured that and present it in project B, including the levels at which the model does not beat the simple carry-forward.

What I would do differently

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

I would build the permission model as data from the start, not as code. The rebuild in September went well because I secured it with a check script. It should not have been necessary.

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

I would write the operations manual from the first release, not afterwards. 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 a second head earlier.

Technology

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