A pet project that went live! Or... How I built an inventory management web app for a game!

It might be one of those worldwide human shared experience. You know... like how wherever you are in the world, a mom's slipper is seen as a surgical drone strike. Well, you could say the same to a programmer's tendency to start pet projects left and right... and never finishing them. I'm not unfamiliar with the feeling. In fact, I've had my share of unfinished zombie git folders which rot away in a hard drive somewhere in a card box stashed away.

But today, we will not talk too much about them. We will talk about one of the few which actually made it out of the cemetery! With sweat, tears, and blood. It climbed out of the ditch and found the light, and actually reached the point where it went live! It's not perfect, far from it. But for a pet project, it's a hell of an achievement in my eyes. To the point that I almost felt like an eagle watching their baby fly for the first time. Almost. Haphazardly, perhaps, but at least it survived. In this case, at least it works...ish.

The background story

Let's start from the beginning. Like most pet projects, it started with the old question that every programmer asks themselves one day: "can I automate this?" even though, sometimes, you shouldn't. Not that that ever stopped me trying anyway. I used to, and still do, play a game called Foxhole, "a massively multiplayer game where thousands of players shape the outcome of a persistent online war that lasts for weeks." I was playing as part of a logistics team that supplies the frontline with goods (weapons, ammunitions, building materials, etc). Something that players learn quite rapidly in this game is that "you can't win alone."

In order to make an impact for your faction, you need to cooperate. Be it with your neighbours, other people, and other teams and alliances. Cooperation is deliberately part of the gameplay loop. And more so for the logistics since in order to supply goods, you need to produce them, and for that, you need materials that need to be harvested and refined. So, we specialise. Some do harvesting, refinement, or transformation, and in between all these steps all the way to when they are used, you have transportation.

You need to take things from where they are produced to where they are needed, but you have little idea where things are without asking dozens of people. And even if you know who produces what, are you really going to pester them every minute if they have this or that? So, I got to thinking. How could I automate this?

The thinking

Before you get into making the product, you need to know what you are going to make. And for that, you need to know your target audience and most importantly, know their needs. Or at least, what you think they need. For my particular case, I identified three target personas:

• The producers are interested in "buying" raw materials and "selling" the obtained transformed products. For that, they need a place to advertise what they need and what they have.
• The transporters are interested in moving goods from one place to another. For that, they need to know which places have the stuff that other places want.
• The managers are interested in planning what goods are needed where and when. They need to know who does what, has what, needs what.

Users developed a network in and of themselves using Discord to advertise price lists between unaffiliated teams, or to collaborate between alliances. People say what they have, what they need, and negotiations take place for a deal to be made. Thereafter, the stakeholders organise themselves to fulfil their obligations! Rather straightforward, but also a big hassle if you don't want to deal with the politics and general human-factor involved. This got me thinking. What players need is two folded: an better inventory management system and a marketplace of some sort.

The former is pretty simple and straightforward, yet the implications and implementations would become quite the headache. At the moment, the in-game stock UI is less an inventory management display... and more of an inventory display. It shows what's in the inventory at a specific location, and that's pretty much it. You need to move around the map to look for items and god forbid you have your resources scattered across the map. It's good when you have a single stock, it's a nightmare if you manage more than five. So, we need a system that allows for a better bird's eye view of stocks across multiple locations.

The latter goes hand in hand with the former. After all, if you have a good view of your stocks, you can easily share it to others, or even make it "public" so they shop by themselves. The rest, I would say, is pretty much like an e-commerce platform.

And that's how Foxstock was born.

The idea

The idea was never to build "an app." That word sounds far too clean, corporate, and too… finished. What I really wanted to build was a layer that sat on top of the chaos and made it legible to reduce friction. There is a difference between meaningful coordination and administrative fatigue, and most logistics teams drown in the latter.

What I observed, after weeks of hauling crates back and forth like an underpaid Victorian dock worker, was that the problem was not production. Nor was it transport. Nor even demand. The problem was information asymmetry. Someone always had something. Someone always needed something. The tragedy was that those two someones rarely knew about each other at the right time.

Discord helped, but Discord is a river. Messages flow, then vanish under the current. A price list posted at noon is buried by memes at 3pm, or a call for materials at 5pm is forgotten by 7.

So I started sketching what would eventually become FoxStock around a simple premise: logistics needs a shared source of truth.

Instead of a spreadsheet passed around like contraband, or screenshots of in-game inventories, I wanted an actual, structured, collaborative system where stockpiles across the map could be represented in one coherent view.

That is where the concept of the Network came from.

A Network is an operational boundary that define who participates, what locations are relevant, and which stockpiles belong to the same logistical ecosystem. Inside a Network, you create Locations. Inside those Locations, you manage Stockpiles. Inside those Stockpiles, you track Items and quantities. It sounds obvious when you say it like that, almost disappointingly mundane, but that hierarchy is what turns scattered resources into an intelligible system.

Instead of opening five different in-game menus across five towns, you open one dashboard and see the state of your entire operation. From there, the rest followed almost naturally.

Once you can see the state of your operation at a glance, you start asking different questions. A refinery town overproducing components while a frontline bunker starves for ammunition stops being a vague suspicion and becomes a visible discrepancy.

Originally, I entertained the idea of turning FoxStock into a fully fledged marketplace. Listings, offers, maybe even some form of transactional workflow. The temptation was strong; after all, if you can see supply and demand, why not formalise the exchange? But the more I reflected on how teams actually operate in Foxhole, the more I realised that negotiation is part of the social fabric. Deals are not just about numbers; they are about trust, alliances, history, and sometimes ego. Trying to codify that into rigid mechanics would have stripped away something essential.

Maybe I will implement such a feature one day. Who knows? The project may be live, but it's far from finished. Instead of enforcing transactions, FoxStock exposes information. If you choose to share your Network, others can inspect your stock levels and identify opportunities themselves. A transporter does not need a contract; they need to see that Town A has surplus crates and Town B has a shortage. A manager does not need a marketplace tab; they need clarity on what to prioritise. The "market" emerges from shared data rather than from imposed rules.

Of course, shared data without structure quickly becomes shared chaos. One of the first design constraints I imposed on myself was that not everyone should be able to modify everything. In any organised logistics group, there is at least some degree of hierarchy. Some members update quantities after production runs. Others merely consult the information to plan routes. Leaders oversee the broader picture. FoxStock reflects that reality by allowing Network owners to invite users and assign roles with specific permissions. It is not heavy-handed, but it prevents the system from collapsing under its own openness.

Under the surface, implementing that structure was less poetic than conceiving it. Managing concurrent updates, ensuring that permission checks are enforced consistently, designing a data model flexible enough to survive future changes without becoming a tangled mess — these are the unglamorous parts of software development. The parts that do not make it into triumphant blog posts. There were migrations that required careful handling, features that had to be refactored once their real-world use exposed blind spots, and countless small adjustments prompted by actual player behaviour rather than theoretical use cases.

And that is perhaps the most valuable aspect of building something for a community you are part of: feedback is immediate and brutally honest. If a feature is awkward, people simply ignore it. If updating stockpiles is cumbersome, they stop updating them. It reminded me a bit of my experience with amateur novel-writing. A system meant to reduce friction cannot afford to introduce new forms of it. Every additional click, every ambiguous label, every unclear flow becomes a liability.

The "launch"

I am a pretty shy and quiet guy. So, when FoxStock finally went live, I stayed quiet as always. I simply deployed it, shared the link within my logistics circle, and watched. A Network was created. Locations were added. Quantities were updated after a production cycle. Then, almost casually, someone used the information to organise a transport run without having to ask half a dozen questions in chat.

That quiet adoption was a real milestone to me. Not because the application was flawless (it certainly was and is not) but because it proved that the premise held. A shared, structured representation of stockpiles could meaningfully reduce the cognitive load of coordination.

In essence, FoxStock is not an attempt to reinvent Foxhole’s economy. It is a companion layer to make distributed effort legible. It does not eliminate negotiation, politics, or human error, but reduces the noise so that cooperation can focus on what actually matters: moving resources where they are needed, when they are needed, with as little administrative drag as possible.

For a project that began as a scribble in frustration, that outcome feels almost disproportionate. It started with the naive question of whether something could be automated. It ended as a modest but functional tool used in operations. And for once, instead of joining the ranks of abandoned repositories, this one survived long enough to be useful.