When a warehouse stopgap starts becoming an ERP

A retrospective founder account. The exact starting date has not been reconstructed. Planned publication date: 19 October 2026 (Asia/Shanghai).

I wanted a temporary warehouse tool. It began growing into an ERP, a system for managing resources and operations. The useful part of that story is the gap between developing something and putting it into everyday use.

The problem and the temporary decision

As the business grew, goods began going missing in the warehouse. Existing manual controls were no longer enough.

We started moving to the 1C platform. In our particular case, implementation felt slow to me. That is my assessment of our experience, not a claim about every 1C implementation. Meanwhile, the immediate warehouse gaps needed attention.

I decided to try a temporary solution with GPT’s help while implementation continued. My own ERP was not the starting premise: first, I needed a stopgap.

What happened and what remained unfinished

I began iterating with GPT: explaining a task, looking at the result, and coming back with clarifications. Gradually, the solution began developing into an ERP. This describes my role in directing the work; it is not a technical account of who wrote each piece of code.

The result pleasantly surprised me and changed the scope of the idea. At that stage, implementation was still underway. Testing raised questions, and implementation brought difficulties that required further work. At that stage, we were checking the development results step by step in everyday use.

This account does not establish measured savings, complete integrations, or a fully accepted system. It also does not identify a first technical action, database design, or deployment architecture. Those details should not be filled in from assumptions.

An editorial checklist for discussing a growing prototype

The questions below are an editorial framework for examining this story, not a record of procedures we already carried out or an independently validated implementation method.

1. What was the original problem? Keep the immediate operational gap visible. In this account, that was missing goods and insufficient manual control. Later ambitions should not replace the original explanation.
2. What actually changed? Describe a specific observed change and its evidence before calling the tool a success. Here, the founder observed the stopgap developing into a broader system; the account does not quantify its business effect.
3. Which stage does the evidence cover? A development result, a server installation, and acceptance of actual warehouse work are different claims. Ask which one is supported rather than treating them as interchangeable.
4. What is still unresolved? Name the boundary of the account. At that stage, implementation was continuing; the specific errors need a separate verified description. An incomplete account can still be useful when its limits are visible.
5. What can the next example demonstrate? A scenario with training data can illustrate a bounded check. It should not be presented as proof of real operations or as the first development step unless the history supports that claim.

In the next entry, I want to show how a warehouse training scenario was prepared, and which checks remained to be done. That is a separate documented milestone, not the established beginning of development.

Which single workflow would you examine before trusting a temporary tool with actual operations?

Based on the founder’s account; edited and translated using AI.

Original founder account on GitHub

Illustration generated with AI; not a screenshot.