Skip to content

Internal Consumables Accounting System — demo pack

This page assembles sections relevant to demos and stakeholder presentations: overview, role, architecture, decisions, roadmap, and demonstration.

Contents

Summary

Status

partial implementation / historical project

Role

initiator, concept author, prototype developer

Stack

Type: Internal automation / early ERP-like inventory system; Period: early transition stage from infrastructure administration to internal systems development

Project value

A lightweight internal ERP-like system for IT department consumables accounting - tracking stock levels, material movement history, and procurement planning.

What this demonstrates

ExpendIt demonstrates my early transition from an infrastructure-focused role to internal systems development and system analysis.

The project already contained elements that later became part of my professional profile:

  • analysis of a real operational pain point;
  • identification of domain entities;
  • an attempt to build an accounting model;
  • intention to replace a manual process with a structured system;
  • practical automation for internal users;
  • attention to data, operation history, and planning.

The project was not completed as a mature product, but it became an important step toward systems thinking, software development, and my later transition into systems analysis.

Overview

Summary

Create a lightweight internal ERP-like system for the IT department: not as a large corporate platform, but as an applied tool that would help track current stock levels, material movement history, and future procurement needs.

Technology Stack

  • Spring Boot backend
  • Thymeleaf-based simple UI
  • Local deployment

Role and Responsibilities

The project was started as an independent from-scratch development effort, but was not completed as a finished ERP system. However, the project is important not as a production-ready product, but as an early transition point from the role of a system administrator to the role of a person who designs and builds applied IT systems.

Architecture and Integrations

Architecture

Architectural Approach

The project was conceived as a layered modular monolith: application logic, data model, simple user interface, and persistence layer were intended to be separated by responsibility, but without premature architectural complexity.

Integration Flows

Decisions, Trade-offs, and Risks

Key Decisions

Trade-offs

Modular monolith without premature complexity

Application logic, data model, simple user interface, and persistence layer were separated by responsibility, avoiding distributed architecture and premature abstraction for an internal prototype.

Early prototype vs finished ERP

At the current maturity level, the project is more accurately described as an early internal automation prototype rather than a completed ERP system.

See also Architecture Decision Records.

Roadmap and Demonstration

Roadmap

Screenshots and Demo

What This Demonstrates

ExpendIt demonstrates my early transition from an infrastructure-focused role to internal systems development and system analysis.

The project already contained elements that later became part of my professional profile:

  • analysis of a real operational pain point;
  • identification of domain entities;
  • an attempt to build an accounting model;
  • intention to replace a manual process with a structured system;
  • practical automation for internal users;
  • attention to data, operation history, and planning.

The project was not completed as a mature product, but it became an important step toward systems thinking, software development, and my later transition into systems analysis.