DEV Community

Cover image for How I Built a Production Management Tool After Years of Excel Chaos
Alexander
Alexander

Posted on

How I Built a Production Management Tool After Years of Excel Chaos

We make artist paints. Small manufactory in Krakow, Poland. Five people, around 200 products, dozens of raw materials. For years we tracked everything in spreadsheets.

It worked. Until it didn't.

The breaking point

Excel is great until you need to answer questions like:

  • What's the real cost of this product including labor and overhead?
  • Which batch of pigment did we use in order #4521?
  • How much titanium white do we actually have if we count reserved stock?

We tried to solve this with more sheets, more formulas, more VLOOKUP magic. The file grew to 15MB. It crashed regularly. Nobody wanted to touch it.

So we looked for software. Found two options: simple inventory apps that couldn't handle recipes and batch tracking, or enterprise ERPs that cost thousands per month and needed consultants to set up.

Nothing in between.

Building our own

I'm not a professional developer. Backend experience, some frontend, enough to be dangerous. But I figured if I understand the problem deeply, maybe I can build something that actually fits.

Stack ended up being pretty standard:

  • Laravel on the backend
  • Vue.js for the frontend
  • PostgreSQL
  • Hosted on a regular VPS

Nothing fancy. The complexity wasn't in the tech, it was in understanding what small manufacturers actually need.

What I learned about the domain

Manufacturing software has this weird problem: every business thinks they're unique. And they kind of are. A cosmetics maker and a food producer have different compliance needs. A furniture workshop tracks things differently than a paint factory.

But underneath, the patterns are similar:

  • Raw materials come in with batch numbers and expiry dates
  • You combine them according to recipes
  • You get finished products (or semi-finished ones that become ingredients for other products)
  • You need to trace what went where

The trick was making the system flexible enough to handle variations without becoming a monster of configuration options. I wrote more about how small manufacturers usually outgrow spreadsheets on our blog if you want the non-technical perspective.

Multi-language from day one

We're in Poland but sell across Europe. The interface needed to work in multiple languages from the start. Currently at 13 languages.

I used a simple approach: JSON translation files, nothing complicated. The real challenge was finding good translators for manufacturing terminology. Google Translate doesn't know the difference between "batch" as in cookies and "batch" as in production batch.

The cost calculation rabbit hole

This one took months to get right. Sounds simple: add up ingredient costs, divide by output quantity. Done.

Except:

  • What about waste? If you lose 5% of material during production, that affects unit cost
  • What about labor? Someone spent 3 hours on this batch
  • What about equipment depreciation?
  • What about utilities allocated to production?

Most small manufacturers just guess their margins. They price based on competitors or gut feeling. When I finally built proper cost calculation with all these factors, some of our products turned out to be barely profitable. Others had way better margins than we thought.

Traceability is not optional

Food safety, cosmetic regulations, quality control. If something goes wrong with a product, you need to know exactly which raw material batches were used. And which customers received products from that production batch.

This was non-negotiable. Every production entry records which ingredient batches were consumed. You can trace forward (raw material to finished product to customer) or backward (customer complaint to production batch to raw materials to supplier).

Boring to build. Critical when you need it.

Opening it up

After using it internally for a year, we cleaned up the code, added multi-tenant support, and launched it as https://krafte.app

Now a few hundred manufacturers use it. Mostly in Europe. Cosmetics, food, chemicals, other paint makers. The feedback loop is great because they hit edge cases we never considered.

What I'd do differently

Honestly? I'd use a proper framework for the frontend from the start. Started with jQuery and blade templates, had to rewrite significant parts when moving to Vue.

Also underestimated how much time goes into "boring" features. Export to Excel. Email notifications. User role permissions. The unsexy stuff that enterprise customers absolutely require.

Takeaways

If you're thinking about building software for a niche industry you know well:

  1. Your domain knowledge is the moat. Generic developers can build software, but they don't know that manufacturers need FIFO stock management or that batch numbers sometimes come from suppliers and sometimes are generated internally.

  2. Start with your own pain. We used the tool for a year before selling it. Every feature existed because we needed it.

  3. Simple tech is fine. Laravel and Vue aren't exciting in 2026. They work. That's what matters.

  4. Talk to users constantly. Our best features came from customer requests that seemed weird at first but made total sense once we understood their workflow.

If anyone's working on niche B2B tools, happy to chat in comments.

Top comments (0)