DEV Community: Pavel L.

5 Reasons Why I Built an ERP in Vanilla JavaScript

Pavel L. — Sat, 04 Apr 2026 09:11:19 +0000

"What framework did you use?" I hear this quite often from other devs when I share my journey building the ERP system I completed this year.

1. Freedom

Every time I started building with Svelte, React or Next.js I felt... constrained. I don't want to criticise these technologies, they are great and each has its audience. Back in the day they solved real limitations of JavaScript around code organisation, modularity, component architecture and state management.

But today things are different. JavaScript itself has grown up. You can build reusable components, use ES module imports natively, write clean arrow functions and structure things in an object oriented way without a framework telling you how.

There is one catch though. JavaScript is not a framework. No enforced structure, no constraints, absolute freedom to build things exactly the way you want. Including doing them completely wrong. That is what most developers associate with the word "Vanilla" and honestly I get it.

Here is a snippet from the dashboard where I manage ERP users:

Full Class Preview

A few things worth noting:

1. Many imports. Helps with modularity. The cool thing is this runs directly in the browser without compilation, though I would not recommend skipping it in production. More on that below.

2. Classes. I use them mainly as entry points for each page of the ERP while keeping everything else in exportable modules outside. No deep reason for classes here really, I just find the readability better and the patterns I repeat across pages help me navigate the codebase faster.

3. Repeatable pattern. Every page class follows the same structure:

jsconstructor → init → html → render → listeners

Works for Users, Manufacturing Journal, Orders, everything.

4. Universal components like Locale, Session, Header and Footer shared across the whole system.

2. Aesthetics and Minimalism

This matters less now that AI generates so much code but still. The freedom JavaScript gives you to structure things however you want makes it easy to keep things clean.

Code should look good. Bad looking code belongs in bad projects.

Simple repeatable methods like init and html, shared classes like Header and Footer, make the codebase easy to read without any bloat or unnecessary dependencies weighing things down.

I skip types. Simple variables and objects passed through methods or event bus handlers. I know the argument, there is no reason not to use types, but I don't care as long as everything works and the code stays concise. For a solo built system where I know every data structure by heart this works fine. I would not necessarily recommend this to a larger team.

3. Full Stack JavaScript

If I broke down my programming time by language it would go: PHP, JavaScript, Java, Python. Of those JavaScript and Python appeal to me most. Python's conciseness is great but the indentation style is not for me.

Node.js is pure JavaScript on the backend. When I was working with Next.js I kept asking myself: wait, is this frontend or backend? I think beginners run into this too. At first I thought I was just inexperienced but I now think it is a structural issue. With a different backend language the boundary is obvious immediately.

The biggest practical advantage of JavaScript on both ends is sharing identical logic. In my ERP I calculate various VAT rates across different scenarios. Things get complicated fast in the EU depending on whether your company is VAT registered and whether goods fall under a special tax regime.

I created a packages folder at the root of the project that shares the exact same tax calculation code across PDF invoices, accounting reports and live frontend quotation previews:

One source of truth for something this critical is not optional.

4. Performance

React carries 100KB+ before anything else loads. JavaScript runs natively in the browser. Everything else compiles down to it first. JavaScript just runs, straight from the start.

With a single JS file I can fetch everything needed for full UI rendering and localisation in one shot. The moment the script loads it executes.

Here are the Lighthouse scores. Most pages hit 100% without a single optimisation pass:

Some pages drop to around 80% but that is mainly due to large datasets and servers sitting thousands of kilometres away, not the architecture.

For the inventory page above the entire thing is one JS file at 30KB. I do use Bootstrap which adds 81KB of JS on top, that is a deliberate trade for UI consistency and something I have not optimised away yet. But with 100% Lighthouse scores across most pages the question becomes whether there is anything left worth optimising.

5. No Dependency Hell

How many times have you been there. A package needs updating because it is outdated or worse vulnerable. You run the update, get lucky, and then something breaks somewhere completely unrelated.

Basic projects end up with hundreds of dependencies. Now imagine an ERP with 20+ journals, reports and manufacturing modules all tightly coupled. When something breaks you are stuck.

I am not saying I avoid dependencies entirely. Three.js is a good example of one I rely on. But overall the project is much cleaner for it. My node_modules mostly feeds the Node backend, not the frontend.

AI

Is there an article that does not mention AI today. So here we go.

Something I keep thinking about is how ERP software updates should actually work in the future. The traditional model is one shared codebase, customisations live in their own layer, new releases keep everyone on the same version. It works but it is rigid.

What if the model flipped. Shipping code is cheaper and faster than it has ever been. What if every client just gets their own codebase from day one. No modifying a core that affects everyone. No releases nobody asked for. Each installation just evolves alongside the company using it.

This alone deserves a separate article but the part that connects to vanilla JS is this. I want to build an environment where AI agents can navigate the codebase, understand it and make changes directly based on user feedback. Not in staging. In production.

I know that sounds alarming. But imagine a user complains about an awkward button. Two minutes later it is a toggle instead of a checkbox and everyone moves on. No ticket, no sprint, no deployment pipeline.

The decoupled way my ERP pages are structured, and the fact that almost every part can be overridden through an overrides folder, gives me a starting foundation where AI generated changes are contained, easy to test visually and easy to revert without recompiling anything or restarting a container.

No compilation means you drop the code and check it in the browser immediately. I genuinely want to know if there is a workflow in React or Next.js that gets close to this.

Things I Learned Along the Way

Document title timing

All my data fetching is packed into a single JS call after page load. This works fast but it means I set the document title after the data arrives since that lives in index.html. Minor but worth knowing going in.

Decoupled pages

I moved toward treating each section of the UI as its own isolated thing. No centralised routing, no injected scripts that may not be needed on every page. The product editing page is heavy, 3D declarations, image uploads, an .obj viewer with Three.js. Keeping it isolated means that complexity stays contained.

State management

This is the one thing I wish I had done better. I built helper functions like onClick and onChange because writing document.addEventListener everywhere felt unnecessarily verbose. They work well until the frontend grows. Then partial DOM updates cause some listeners to go missing while others fire twice.

This means I end up solving problems React and Svelte have already solved. React through the virtual DOM, Svelte by manipulating the DOM directly.

The fix that actually worked was declaring listeners directly in the HTML. It sounds old school but it holds up:

That element always has the same reference no matter what happens to surrounding code. No separate initialisation needed.
You can see exactly what is listening right where the element lives.
No double executions, no mystery triggers.

Bundling

Running without compilation with many ES module imports causes browser caching issues that stick around even in incognito. A simple Rollup script fixed the live reloading and the caching disappeared. Loading 20+ individual imports is not ideal in production but the fact that something as complex as an ERP can run this way, no bundles, no framework, no frontend compilation step, is still something I find genuinely interesting.

Maybe it is the future. Who knows.

Architecture of an Open Source Manufacturing ERP

Pavel L. — Wed, 18 Mar 2026 08:14:49 +0000

This software’s first version dates back to the 1990s, long before GitHub existed.

Technologies and capabilities were very different then, but some of those UI/UX ideas were strong enough to survive multiple major revamps, including a full rebuild from scratch this year.

kenzap / factory

Open-source Manufacturing ERP / Factory OS

Kenzap Factory

About: Manufacturing resource planning and quotation software. Production, costing, estimation and planning designed for job-based manufacturing.

Stack:

PostgreSQL
Redis
Node.js
ES6 JavaScript

Demo: https://kenzap.com

What is "Kenzap Factory"?

An ERP system designed specifically for metal fabricators. It supports real production workflows. The focus is on job shops, make-to-order production, and compliance.

Key Features:

Manufacturing journal
Client journal
Access and user management
Metal cutting and nesting integration
Warehouse and product inventory
Financial reports
Analytics module

Production Workflow Support:

Job-based manufacturing processes
Real-time production tracking
Cost calculation and planning
Compliance management

User Journey

Below is a comprehensive overview of user workflows within this ERP system. Items marked with "-" are currently in development.

General User

Securely log in to the platform using WhatsApp or Email (2FA) ✓
Change platform language ✓
Navigate seamlessly across the platform ✓

Manager

Create new orders ✓
Access order logs ✓
Manage client records…

View on GitHub

This ERP is built around real factory workflows, where quotations, production execution, material write-off, and financial reconciliation all happen within one operational loop.

My goal is to create software that meets all modern factory needs, is technologically fresh, and provides unlimited room for AI innovation and automation synergies.

1. Architecture Overview

The project is a Node.js + Express backend with an ES module frontend, built and served as one deployable application.

Core directories

server/: APIs, documents, storage gateway, extension loading
public/: frontends (orders, manufacturing, worklog, cutting, stock, settings, etc.)
packages/: shared runtime logic across frontend/backend (for example, tax-core)
overrides/: tenant-specific replacements without touching core files
server/extensions/: plugin-like runtime extensions
dist/: compiled production output of public/
docs/: documentation and AI-assisting files for faster development

Build model

Frontend compilation is handled with Rollup, but it can also run without compilation because modern browsers support ES modules natively.

There is no heavy frontend framework involved. I borrowed a few structural ideas from Next.js, but the codebase is intentionally framework-free and modular.

JavaScript is now mature enough to handle large-scale architecture cleanly without mandatory framework coupling.

2. Data

All business data is stored in PostgreSQL (except uploaded files).

PostgreSQL gives us relational database standards, strong JSONB support, and vector embedding support in one place.

The system uses two tables:

data: JSONB payload table for core ERP entities
metering: timestamp-based machine/factory readings

2.1. `data` table

Core columns

_id — unique 40-character record ID
pid — parent relationship ID
sid — tenant/space ID (for SaaS mode)
ref — logical entity type (order, product, entity, settings, etc.)
js — full JSONB payload
embedding — optional vector field for AI/agentic operations

This approach is opinionated. It needs query discipline and indexing strategy, but it enables very fast iteration for highly dynamic domain models.

Below is an example of an order stored with ref = order.

2.2. `metering` table

Core columns

_id — unique record ID
time — UTC timestamp
reading — numeric reading
machine — machine ID
type — reading type

In manufacturing environments, this data enables predictive maintenance, heat maps, load balancing, and scheduling optimizations.

2.3. File storage

Product images, 3D models, and other assets are stored in S3-compatible buckets.

For self-hosting, you can use SeaweedFS or any cloud object storage provider.

Storage is abstracted through createStorageProvider, so the infrastructure layer stays portable.

3. Business Workflow as Architecture

The architecture follows this factory loop:

Quotations: manager creates quotation/order with formula-based pricing
Production: team executes stages in manufacturing journal + logs work in worklog
Materials: cutting and metal log manage coil usage and write-offs
Documents: invoices, waybills, production slips generated server-side
Finance: payments, balances, accounting exports
Reporting: manufacturing output, employee performance, machine activity
Forecasting: AI-driven planning and KPI analytics (currently early stage)

4. Frontend Organization

The UI is organized as operational journals:

public/orders, public/order, public/manufacturing, public/worklog, public/cutting, public/payments, etc.
Shared logic in public/_/components, public/_/modules, public/_/helpers
Action-heavy, modal-heavy UX optimized for fast factory-floor execution

5. Backend Organization

server/_ — helpers, dependencies, reusable backend components
server/api — API routes
server/document — PDF and export generators
server/extensions — extension runtime
server/scripts — migration and ops scripts
server/server.js — Express entry point

Route strategy

Core routes are loaded from server/api/*
In practice, tenant-specific behavior should go to overrides/server/api/*
Same approach for document generation via server/document/* and overrides

Extension model

Extensions in server/extensions/* are loosely coupled feature modules.

Each extension has:

index.js (entry point)
manifest.json (metadata/capabilities/permissions)

6. Dynamic Settings

Critical configuration is editable directly from the dashboard:

brand name, VAT number, tax region
timezone (affects cron + generated PDFs)
invoice/email/WhatsApp templates
system variables and attributes
inventory and raw material pricing
worklog and stock categories
extension-specific settings

Settings are cached in memory for low-latency access.

7. Localization

Every text in the system is localizable (frontend + backend).

Localization helpers

__html('Your text') — safe translation for HTML content
__attr('Your text') — safe translation for HTML attributes
__('Your text') — plain translated string

Tooling

npm run locales:export — extract localizable strings
npm run locales:translate:lv — auto-translate missing strings (for example, Latvian)

The translation script uses Anthropic API (server/scripts/locales-translate.js).

8. Upcoming Releases

Since the beginning of this year, at least one production feature has shipped almost every week.

You’re welcome to share feedback and ideas.

Planned work is tracked here:

https://github.com/kenzap/factory/tree/main/docs/exec-plans/active

9. License

This project is licensed under Apache-2.0.

It is friendly for commercial use and does not require publishing your modified source code.

10. Overview

For a more visual overview of the system check this video below.

Machine Telemetry and Factory Metering API

Pavel L. — Fri, 13 Mar 2026 14:00:20 +0000

Factory machines are a silent source of valuable insights. By collecting just a single metric from different machines, it is possible to visualize the load of the entire factory by hour, identify when shifts start and end, and detect the busiest workstations.

So I decided to create this guide to show how I collect readings from a bending machine UI and store them in a PostgreSQL table.

1. Goal

Capture changes in the machine’s bend counter and store them as time-series records. The goal is to build useful telemetry inside the factory ERP.

2. Structure

I defined a PostgreSQL table structure suitable for storing timestamp-based readings. An example is shown below.

The screenshot is taken from Adminer, which I use as a web interface to interact with my PostgreSQL database. I find it great for basic tasks, although there are probably better alternatives.

Next, I created a separate folder that works as an extension inside my ERP system. This is where the API endpoints reside. Its purpose is to accept POST requests:

POST /extension/machine-tracking/store-reading

Then I defined the payload (Codex actually helped generate it):

{
  "machine_id": "BM301",
  "reading": 1234,
  "time": "2026-03-13T10:30:00.000Z"
}

There are three main variables:

the machine ID
the reading value
the timestamp

The machine I started this integration with is designed to bend metal, as shown below.

View from a side.

Technically, there are many metrics that could be captured, such as the total number of cycles, power on/off signals, and others. However, simplifying the integration to a single parameter does not necessarily reduce the quality of telemetry.

So I decided to track just one metric, which is the number of bends. Specifically the number of times the metal beam moves up and down.

Each time the value changes, an API request is triggered and the backend stores the reading. Once multiple readings are collected over time, charts can be generated to visualize how busy the machine is throughout the day.

3. Building API

Well, prompts again. I sent the following prompt to Codex.

The schema called metering to store reading counters from various machines on the factory floor was already created in the previous step.

The final output consisted of two main files:

index.js — defines the API route
src/store.js — handles storing the data

Below is a screenshot of index.js.

Not much is happening here. We simply extend an Express route and perform basic validation of the incoming data before passing the payload to the store method.

const response = await store(req.body, db, logger);

In the store.js file, we pass the three payload parameters to the PostgreSQL database.

You can browse these files directly in my repository:
telemetry extension

4. Getting Data From the Machine

Now that the API and database are set up, the next question is: where do we get the data from?

My first thought was to use sensors connected to a Raspberry Pi acting as a gateway that would forward the payload over the internet to my ERP server.

However, since I understand how the machine’s UI operates (it’s a relatively simple browser interface communicating with the PLCs), I decided to tweak the interface itself to extract the reading without installing any additional hardware.

The bending machine’s software still relies on jQuery version 2.0 which was released over a decade ago.

The only change I had to make after Codex generated the code was updating the endpoint. I changed it from:

/extension/machine-tracking/store-reading

https://mydomain/extension/machine-tracking/store-reading

so that the machine interface could transmit the data to the ERP server publicly.

5. Debug

Obviously, things did not work out of the box, but I felt I was very close. The first issue turned out to be the endpoint itself.

It turned out that my default PostgreSQL user did not have permission to connect to the newly created metering database.

The fix was relatively simple. Using the Adminer interface, I extended the permissions for my default user.

GRANT USAGE ON SCHEMA public TO skarda_design;
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.metering TO skarda_design;
GRANT USAGE, SELECT ON SEQUENCE public.metering__id_seq TO skarda_design;

After that, I sent the request through Postman and it worked. I could hardly believe it, but when I checked the database, the payload had been stored correctly.

Even though I had deployed everything to production, the information was still not being transmitted from the machine. I opened the browser’s inspect panel on the machine interface and discovered that it was a CORS issue.

I simply needed to configure Express to allow requests sent from localhost. Once that was fixed and the browser tab on the machine was refreshed, the data started flowing.

I then connected two more machines using unique machine_id values and checked the metering table.

The results speak for themselves.

6. Visualisation

This is the most fascinating part, because we can now start thinking about meaningful insights from the collected data (I waited for 3 days before getting to this part) and how to visualize them. I defined three possible views:

Shift heatmap
Production rate trend
Per-machine counter trend

Then I sent another prompt. Here’s what we got.