Back to portfolio
SaaS · Inventory Management

Mimos Papelaria

SaaS inventory management system for a stationery store: products, stock movements, categories, suppliers and reports, with UI/UX, a React front end and the back end

My role
Full Stack Developer · UX/UI Designer
Mimos PapelariaMimos Papelaria
01

Context

Mimos Papelaria sells cute stationery and organization items: notebooks, pens, washi tapes, stickers and planners. I created a SaaS inventory management system for it and did everything: the UI/UX, the React front end and the back end, from data modeling to the API.

Client
Mimos Papelaria
Category
SaaS · Inventory Management
Roles
Full Stack Developer, UX/UI Designer
Stack
React, API REST
02

Challenge

A stationery store sells lots of small, similar items with high turnover and constant restocking. In a spreadsheet, products sell out without warning and nobody knows who changed the stock, or why. The system had to be simple for whoever runs the store day to day and strict about the rules: no duplicate SKUs, no outgoing movement that leaves stock negative and no movement without someone responsible.

03

The system, screen by screen

Every screen follows the same structure: a side menu with the brand, the key numbers at the top, tables with pastel status colors and a single wine-colored button for the main action.

  1. 01 / 10

    Access

    The sign-in page already sums up the system ("Your stock in order. Your stationery store blossoms.") and each person signs in with their own e-mail and password. Without signing in, nothing about the stock is visible.

  2. 02 / 10

    Overview

    The dashboard opens with the four numbers that matter: registered products, stock value, low-stock items and sold-out items. Below, the week's incoming and outgoing movements in a chart, the products at their restocking limit and the latest movements.

  3. 03 / 10

    Products

    The catalog with search by name or SKU, filters by category and stock status, CSV export and pagination. Each row shows SKU, category, price, quantity and a status (available, low or sold out) that updates on its own as stock changes.

  4. 04 / 10

    Adding a product

    The form in two parts: the item details (name, SKU, category, supplier, cost and sale prices, initial stock) and stock control, with the minimum quantity that triggers the alert and the shelf location. Alongside, tips on how to build the SKU.

  5. 05 / 10

    Movements

    The complete stock history: the month's incoming, outgoing and adjustment totals and, in the table, the date, product, type, quantity, person responsible, source or reason and status of each record, with search and a date filter.

  6. 06 / 10

    New movement

    Recording an incoming, outgoing or inventory adjustment takes just a few fields: product, quantity, reference, reason and date. Before saving, the system shows the current stock and the balance after the movement and asks for confirmation.

  7. 07 / 10

    Categories

    The categories that organize the catalog (writing, notebooks, decoration, stickers, paper), with the number of products in each one and a warning for items that still have no category.

  8. 08 / 10

    Suppliers

    Restocking partners in cards, with category, phone, status and the date of the last order, plus search by name or company tax ID and export.

  9. 09 / 10

    Reports

    Stock turned into purchasing decisions: total value, turnover, losses and critical products for the month, stock value by category, restocking suggestions based on minimum stock and a comparison of incoming and outgoing movements over the last six months.

  10. 10 / 10

    Mobile version

    On the phone, the dashboard rearranges itself into cards: the stock numbers, the low-stock items and a quick button for a new movement, with navigation at the bottom of the screen.

04

Architecture

I designed the data model and the API contract before the screens, so the stock rules would live in the back end and not depend on the interface.

Front end
React, with reusable components and a responsive layout
Back end
REST API with routes for products, movements, reports, categories and suppliers
Data model
5 entities (products, categories, movements, suppliers and users) with UUID keys
Movements
Each record stores the stock before and after, the type (in, out, adjustment or loss), the reason and who did it
05

Business rules and security

The rules that protect the stock are validated in the back end, not just on screen:

Unique SKU
A duplicate SKU is rejected by the API (HTTP 409)
Balance
An outgoing movement can't leave stock negative; validation and saving happen in an atomic transaction
Traceability
Every movement records the user, date, reason and reference
History
A product with movements is archived, never deleted
Prices
Values stored as decimals, never as floating point
Access
Sign-in with hashed passwords and role-based permissions
06

Technical documentation

The functional scope, the relationships between entities, the business rules and the API routes, documented alongside the design as a guide for development.

Entities, relationships and business rules
Data model and REST API routes
07

Design system

A component library to keep the screens consistent (buttons, fields, statuses and cards) and the system's feedback states: success, validation error, low stock and sold-out product, each with its own color and message.

Components
States and validations

Visual System

A pastel palette inspired by paper, ribbons and notebooks, with rounded corners, soft borders and delicate icons: the system has the same charm as the store, and pink works as its signature.

Palette

Mimos Pink

#E88FAA

Main brand color and buttons

Soft Lilac

#C9B5E6

Navigation and highlights

Butter Yellow

#FFF0B8

Gentle alerts and highlights

Mint Green

#C9E6D1

Success and available stock

Paper Cream

#FFFAF0

Main background

Deep Mauve

#665063

Text and headings

08

Takeaways

An inventory system is only reliable if the rules hold on every path. Starting with the data model and the business rules, and only then designing the screens, made the interface simpler: each screen only has to show what the back end already guarantees.