DEV Community: Guadalupe Rosas

Inbox Zero for Devs: How I Built a JavaScript Script to Destroy Gmail Spam

Guadalupe Rosas — Wed, 24 Jun 2026 21:28:29 +0000

Hey dev community! 👋

As developers, our inboxes often turn into a graveyard of job alerts (LinkedIn, Indeed, ZipRecruiter) and tech newsletters we subscribe to with the intention of "reading later" but never actually open. The result? Important emails get lost, and we get the dreaded "Account storage is almost full" notification.

Recently, I hit that wall. I had thousands of accumulated emails. While Gmail allows you to create filters for incoming mail, it doesn't have a native feature to say: "Delete this email automatically after 7 days".

So, I decided to solve it the way we solve everything: by writing some code.

🛠️ The Solution: Google Apps Script + JavaScript

Since the Google Workspace ecosystem runs on a JavaScript-based environment, I put together a custom script. Fun fact: a simple loop originally failed due to Google's strict 6-minute execution limit. To fix this, I optimized the code to process emails in batches of 100, preventing the server from timing out.

Here is the final production-ready script:

function cleanSpamTsunami() {
// 1. Loop to delete ALL Job Board emails in batches of 100
var continueJobSearch = true;
while (continueJobSearch) {
var jobThreads = GmailApp.search('computrabajo OR indeed OR linkedin OR OCC OR neuvoo OR talent.com OR jooble', 0, 100);

if (jobThreads.length > 0) {
  Logger.log('Deleting a batch of ' + jobThreads.length + ' job alert emails...');
  GmailApp.moveThreadsToTrash(jobThreads);
} else {
  Logger.log('No more job alerts found!');
  continueJobSearch = false; // Break the loop
}

}

// 2. Loop to delete old Newsletters (older than 7 days) in batches of 100
var continueNewsletters = true;
while (continueNewsletters) {
var newsletterThreads = GmailApp.search('unsubscribe OR "cancelar suscripción" older_than:7d', 0, 100);

if (newsletterThreads.length > 0) {
  Logger.log('Deleting a batch of ' + newsletterThreads.length + ' old newsletters...');
  GmailApp.moveThreadsToTrash(newsletterThreads);
} else {
  Logger.log('No more old newsletters found!');
  continueNewsletters = false; // Break the loop
}

}

Logger.log('Deep clean completed successfully.');
}

⚙️ How to Set It Up in 3 Steps:

Create the Script: Head over to script.google.com, create a new project, and paste the code.
Authorize it: Click Run (the Play button ▶️) to authorize the script to access your account. > 💡 Note: Google will show a security warning because it's an unverified app. Don't worry—it's literally your own code. Just click **Advanced* -> Go to project (unsafe).*
Automate it (The Trigger): On the left menu, click on Triggers (the Clock icon ⏰), select Add Trigger, and set it to run on a Time-driven event with a Daily timer scheduled between Midnight to 1 AM.

And that's it! Your inbox will stay clean, your storage optimized, and you'll hit a real automated Inbox Zero every single day.

What do you think? How do you handle inbox clutter or automate your dev environment? Let me know in the comments! 🚀

🏥 A Personal Note from the Author

Hey everyone, thank you so much for reading this far.

Writing code and automating solutions is my passion, but recently I had to undergo a major unexpected surgery that has me temporarily bedridden. As a Java developer and the main provider for my family, being unable to work during this recovery phase has been a tough financial and emotional challenge.

I rarely do this, but I have launched a GoFundMe campaign to help cover medical expenses and support my family while I get back on my feet and return to coding at 100%.

If you found this script helpful, or if it saved you some storage space today, please consider supporting or sharing my campaign. Every little bit counts and means the world to us right now. 🙏❤️

🔗 Support or share the campaign here: Help Adrian & His Family on GoFundMe

Lessons Learned Building POS Lite: From Idea to Full Stack Application

Guadalupe Rosas — Wed, 17 Jun 2026 21:19:21 +0000

Introduction

In the previous posts, I shared the process of building POS Lite, a full stack point of sale system for small businesses, stores and gyms.

I wrote about the project overview, backend architecture, frontend development and deployment using AWS EC2, Docker, Vercel and Cloudflare.

In this final post, I want to share the biggest lessons I learned while building the project.

This post is not only about the technical side. It is also about the decisions, mistakes, improvements and mindset that helped me understand what it means to build a more complete full stack application.

Building a Real Project Is Different from Following Tutorials

Tutorials are useful, especially when learning a new technology.

But building a complete project is different.

In a tutorial, many decisions are already made for you. In a real project, you have to decide things like:

How should the project be structured?
Which features should be built first?
How should the backend communicate with the frontend?
How should authentication work?
How should data be stored?
How should the app be deployed?
How should errors be handled?

This was one of the biggest lessons for me.

A real project forces you to connect many concepts together.

Start Simple, Then Improve

At the beginning, it is easy to want the perfect architecture, perfect UI and perfect database design.

But trying to make everything perfect from the start can slow you down.

With POS Lite, I learned that it is better to start with a working version and then improve it step by step.

For example:

First, make the product module work.
Then improve validation.
Then connect it to inventory.
Then improve the UI.
Then add reports.
Then improve deployment.

Small improvements over time are more realistic than trying to build everything perfectly in one step.

Backend Structure Matters

When the backend is small, it may feel okay to put logic anywhere.

But as the application grows, structure becomes very important.

Using a layered structure helped me keep the backend organized:

Controller → Service → Repository → Database

This made it easier to separate responsibilities.

The controller handles HTTP requests.

The service contains business logic.

The repository communicates with the database.

This structure helped me understand why clean backend organization matters in real applications.

Authentication Is More Than Just Login

Before building POS Lite, it was easy to think about authentication as just a login form.

But authentication is more than that.

It includes:

Validating credentials
Generating tokens
Protecting routes
Sending tokens from the frontend
Handling expired or invalid sessions
Managing user access
Keeping sensitive data secure

Working with JWT authentication helped me understand how frontend and backend security connect in a full stack application.

Frontend Is Not Just About UI

Frontend development is not only about making screens look good.

A good frontend should help users complete tasks quickly and clearly.

For a point of sale system, this is very important.

The user needs to:

Search products
Process sales
Review inventory
Understand reports
Receive feedback after actions
Navigate without confusion

This helped me think more about user experience.

A clean interface is useful, but a practical interface is even more important.

Deployment Changes Everything

A project feels very different once it moves from local development to deployment.

Locally, things may work correctly.

But in deployment, new problems appear:

Environment variables
CORS errors
Wrong API URLs
Server ports
Docker configuration
Database connections
HTTPS issues
DNS setup
Build errors

Deploying POS Lite helped me understand that deployment is a major part of full stack development.

It is not just the final step.

It is part of the engineering process.

Environment Variables Are Critical

One of the most important lessons was learning how important environment variables are.

The frontend needs to know the backend API URL.

The backend needs database credentials.

The app needs secrets for authentication.

Hardcoding this information is not a good practice.

Using environment variables made the project more flexible and closer to a real production setup.

Small Bugs Teach Big Lessons

Some bugs were small but taught me important lessons.

For example:

A missing environment variable can break the frontend.
A wrong port can make the backend unreachable.
A CORS issue can block frontend/backend communication.
A small mistake in the database configuration can stop the application.
A missing validation can create bad data.

These problems were frustrating, but they helped me learn how to debug more carefully.

Documentation Helps You Think Clearly

Writing about POS Lite helped me understand the project better.

When you explain what you built, you notice things like:

What is clear
What is confusing
What needs improvement
What decisions were good
What decisions should be changed later

Documentation is not only useful for other people.

It is also useful for yourself as a developer.

What I Would Improve Next

POS Lite is still evolving.

Some improvements I would like to work on next include:

Better error handling
More complete validation
Improved role-based access
Better reporting features
More automated tests
Better UI for mobile devices
Cleaner deployment workflow
Improved database structure where needed
Better documentation for the API

A project is never truly finished.

There is always something to improve.

What I Would Do Differently

If I started the project again, I would probably do some things differently.

For example:

Define the database model more carefully from the beginning
Document the API earlier
Add validation sooner
Create reusable frontend components earlier
Plan deployment requirements before the final stage
Keep better notes about technical decisions
Add testing earlier in the process

These are not failures.

They are part of the learning process.

Advice for Other Developers

If you are building your own full stack project, my advice is:

Build something realistic.
Start small.
Finish a working version.
Improve it step by step.
Deploy it.
Document what you learn.
Share your process.
Do not wait until everything is perfect.

A finished and deployed project teaches more than an unfinished perfect idea.

Final Thoughts

Building POS Lite helped me connect many parts of software development:

Backend development
Frontend development
Authentication
Database design
API communication
Deployment
Cloud infrastructure
Documentation
Product thinking

The biggest lesson was that full stack development is about connecting many pieces into one working system.

POS Lite is still a work in progress, but building it has helped me grow as a developer and understand how real applications are designed, built and deployed.

Thanks for reading this series.

Deploying POS Lite with AWS EC2, Docker, Vercel and Cloudflare

Guadalupe Rosas — Wed, 17 Jun 2026 20:46:11 +0000

Introduction

In the previous posts, I shared an overview of POS Lite, explained how I designed the backend with Spring Boot and showed how I built the frontend with React, Next.js and Material UI.

In this fourth post, I want to focus on deployment.

Deploying a full stack application is an important step because it connects everything together: the frontend, the backend, the database, environment variables, domains, SSL and server configuration.

For POS Lite, I used the following deployment setup:

Backend deployed on AWS EC2
Backend containerized with Docker
Frontend deployed on Vercel
Domain and DNS managed with Cloudflare
Database using PostgreSQL

The goal was to move the project from local development to a production-like environment.

Deployment Goals

Before deploying the project, I wanted to define a few goals.

The deployment needed to be:

Simple enough to manage
Close to a real production setup
Separated between frontend and backend
Secure enough to use HTTPS
Easy to update as the project evolves
Good enough to present as a professional portfolio project

I did not want the project to only work locally on my machine.

I wanted to make it available online and learn what it takes to deploy a real full stack application.

Architecture Overview

The production setup looks like this:

User
  ↓
Cloudflare
  ↓
Vercel Frontend
  ↓
AWS EC2 Backend
  ↓
PostgreSQL Database

The frontend is hosted on Vercel.

The backend runs on an AWS EC2 instance using Docker.

Cloudflare manages the domain, DNS and SSL configuration.

The frontend communicates with the backend through HTTPS requests.

This setup helped me understand how different services work together in a real deployment flow.

Why I Used Vercel for the Frontend

The frontend of POS Lite was built with React and Next.js, so Vercel was a natural option for deployment.

Vercel made it easier to:

Connect the project from GitHub
Deploy the frontend automatically
Configure environment variables
Handle frontend builds
Serve the application globally

The deployment flow was simple:

Push the frontend project to GitHub
Import the repository into Vercel
Configure environment variables
Deploy the application

The most important frontend environment variable was the backend API URL.

Example:

NEXT_PUBLIC_API_URL=https://api.example.com

This allows the frontend to know where the backend is running.

Why I Used AWS EC2 for the Backend

For the backend, I wanted more control over the server environment.

That is why I decided to deploy the Spring Boot backend on AWS EC2.

Using EC2 helped me practice:

Creating a virtual server
Connecting through SSH
Installing dependencies
Running Docker containers
Configuring ports
Managing backend deployment manually

This was more challenging than deploying the frontend, but it helped me understand the infrastructure side of a full stack application.

Preparing the EC2 Instance

The backend runs on an Ubuntu EC2 instance.

The first step was to create the instance and open the required ports.

Some important ports are:

22    SSH
80    HTTP
443   HTTPS
8080  Backend application

After connecting to the instance through SSH, I installed Docker.

A simplified installation flow looks like this:

sudo apt update
sudo apt install docker.io -y
sudo systemctl enable docker
sudo systemctl start docker

Once Docker was running, the server was ready to run the backend container.

Dockerizing the Spring Boot Backend

To deploy the backend more consistently, I used Docker.

The idea was to package the Spring Boot application into a container so it could run the same way on the server.

A simplified Dockerfile looks like this:

FROM eclipse-temurin:17-jdk-alpine

WORKDIR /app

COPY target/pos-lite.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

This Dockerfile does a few important things:

Uses a Java runtime image
Creates an application directory
Copies the compiled JAR file
Exposes the backend port
Runs the Spring Boot application

Docker helped make the deployment process more predictable.

Building and Running the Backend Container

After creating the Dockerfile, the backend image can be built with:

docker build -t pos-lite-backend .

Then the container can be started with:

docker run -d \
  --name pos-lite-backend \
  -p 8080:8080 \
  --env-file .env \
  pos-lite-backend

The --env-file option is useful because sensitive configuration should not be hardcoded inside the application.

Environment Variables

Environment variables are very important in deployment.

For the backend, some of the main variables include:

SPRING_DATASOURCE_URL=jdbc:postgresql://host:5432/database
SPRING_DATASOURCE_USERNAME=username
SPRING_DATASOURCE_PASSWORD=password
JWT_SECRET=your-secret-key
SERVER_PORT=8080

Using environment variables keeps the application more flexible and safer.

It also makes it easier to use different configurations for local development and production.

PostgreSQL Database

POS Lite uses PostgreSQL as the database.

The backend connects to PostgreSQL through the datasource configuration.

For a project like this, there are different options:

Running PostgreSQL on the same EC2 instance
Using a managed database service
Using an external PostgreSQL provider

For this project, the important part was learning how the backend connects to a production database and how configuration changes between local and deployed environments.

Database configuration is one of the areas where deployment becomes more real because local assumptions often stop working once the app is online.

Cloudflare for Domain, DNS and SSL

Cloudflare was used to manage the domain, DNS and SSL.

This helped with:

Domain management
DNS records
HTTPS configuration
SSL/TLS encryption
Better security and performance

A simplified DNS setup can include:

Type    Name    Target
A       api     EC2 Public IP
CNAME   www     Vercel domain

The api subdomain can point to the backend running on EC2.

The frontend can point to the Vercel deployment.

This makes the project feel more professional because users access the app through real domains instead of raw deployment URLs.

Connecting Frontend and Backend

Once the backend was deployed and the domain was configured, the frontend needed to communicate with the backend.

The frontend API URL was configured using an environment variable:

NEXT_PUBLIC_API_URL=https://api.example.com

Then the frontend could call backend routes like:

https://api.example.com/api/products
https://api.example.com/api/sales
https://api.example.com/api/reports

This step was important because it connected the two main parts of the project.

A full stack app is not truly deployed until the frontend and backend can communicate correctly in the live environment.

Common Issues I Faced

Deployment came with several challenges.

Some of the common issues were:

Environment variables not configured correctly
Backend running locally but not on the server
Ports not open in the EC2 security group
CORS errors between frontend and backend
Wrong API URL in the frontend
Docker container stopping after an error
Database connection errors
HTTP vs HTTPS configuration issues

These problems were frustrating at times, but they helped me understand how deployment works beyond tutorials.

What I Learned

Deploying POS Lite helped me improve in several areas:

Working with AWS EC2
Running applications with Docker
Configuring environment variables
Deploying a Next.js frontend with Vercel
Managing DNS with Cloudflare
Connecting frontend and backend in production
Understanding CORS and HTTPS issues
Debugging server-side deployment problems

The biggest lesson was that deployment is not just about uploading code.

Deployment involves infrastructure, configuration, networking, security and debugging.

Key Takeaways

Some of my main takeaways were:

Docker makes backend deployment more consistent.
Environment variables are essential for production.
Vercel simplifies frontend deployment.
AWS EC2 provides control but requires more configuration.
Cloudflare helps with domain, DNS and SSL.
Small configuration mistakes can break the entire deployment.
A project feels much more real once it is available online.

This deployment setup helped me understand the full lifecycle of a full stack application, from local development to a production-like environment.

What’s Next

In the next and final post of this series, I will share the biggest lessons I learned while building POS Lite.

I will write about technical lessons, mistakes, improvements, project structure and how building a real full stack project helped me grow as a developer.

Thanks for reading.

Building the Frontend of POS Lite with React, Next.js and Material UI

Guadalupe Rosas — Wed, 17 Jun 2026 20:35:08 +0000

Introduction

In the previous posts, I shared an overview of POS Lite and how I designed the backend using Spring Boot, JWT authentication, PostgreSQL and REST APIs.

In this third post, I want to focus on the frontend.

The frontend is the part of the application that users interact with directly, so my goal was not only to build screens that work, but also to create an interface that feels practical, clean and easy to use for a real point of sale system.

For this part of the project, I used React, Next.js and Material UI.

Frontend Goals

Before building the interface, I defined a few goals.

The frontend needed to be:

Clean and simple
Easy to navigate
Fast for daily operations
Connected to the backend API
Useful for business users, not only developers
Organized enough to grow as the project evolves

A point of sale system should not feel complicated. Users need to manage products, check inventory, process sales and review reports without wasting time.

That idea guided many of the UI decisions in the project.

Tech Stack

The frontend uses:

React
Next.js
Material UI
TypeScript
Axios
React Hook Form
React Context
React Hot Toast
Barcode scanner support

This stack helped me build a modern interface while keeping the project organized and maintainable.

Main Frontend Modules

POS Lite includes several frontend modules.

Authentication

The authentication module handles the login flow.

The user enters their credentials, the frontend sends the request to the backend and then uses the authentication token to access protected pages.

This module was important because most of the application should only be available to authenticated users.

Dashboard

The dashboard gives users a quick overview of the business.

It can show useful information such as:

Total products
Recent sales
Low stock alerts
Sales metrics
General system activity

The dashboard is important because it is usually the first screen users see after logging in.

Products

The products module allows users to manage product information.

This includes:

Creating products
Editing products
Viewing product details
Assigning categories
Managing prices
Tracking stock

This is one of the core parts of the system because products are used in inventory, sales and reports.

Sales

The sales module is one of the most important screens in the project.

The goal was to create a flow where users can:

Search or scan a product
Add it to the sale
Adjust quantities
Review totals
Complete the transaction

This module helped me think more about usability because a sales screen needs to be fast and clear.

Inventory

The inventory module helps users monitor product stock.

It can also show low stock alerts so that users know when they need to restock certain products.

Reports

The reports module is used to review business information.

Some examples are:

Sales reports
Inventory reports
Low stock reports

This helped me think beyond forms and tables and more about how the frontend can support decision-making.

Application Structure

I organized the frontend into reusable sections.

A simplified structure looks like this:

/app
  /(auth)
    login
  /(dashboard)
    dashboard
    products
    categories
    sales
    inventory
    reports

/components
  /ui
  /forms
  /tables
  /layout

/context
  AuthContext

/services
  api.ts

/types
  index.ts

The goal was to avoid putting all the logic inside pages.

By separating components, services, context and types, the project becomes easier to maintain and extend.

API Communication

The frontend communicates with the backend through an API service.

Instead of writing API calls directly in every component, I created a reusable setup using Axios.

A simplified example looks like this:

import axios from "axios";

const api = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_URL,
});

api.interceptors.request.use((config) => {
  const token = localStorage.getItem("token");

  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }

  return config;
});

export default api;

This makes it easier to send authenticated requests to protected backend endpoints.

It also keeps API configuration in one place instead of repeating the same logic across the app.

Authentication Flow

The frontend authentication flow works like this:

The user submits the login form.
The frontend sends the credentials to the backend.
The backend returns a JWT token.
The frontend stores the token.
Protected requests include the token in the Authorization header.
The user can access private pages.

This helped me understand how frontend authentication connects with backend security.

UI/UX Decisions

Since POS Lite is a business application, the interface needed to be practical.

Some of the decisions I focused on were:

Clear navigation
Simple forms
Readable tables
Fast access to common actions
Feedback messages after user actions
Consistent layout across pages
Responsive design for different screen sizes

Small details matter in this type of application.

For example, after creating or updating a product, the user should immediately know if the action was successful.

That is why notifications and clear feedback are important.

Forms and Validation

Forms are used across many modules, especially products, categories and sales.

I used form handling to make the user experience smoother and reduce errors.

Some examples of validation include:

Required fields
Valid prices
Valid stock quantities
Product category selection
Login credentials

Good validation improves the user experience because users can correct mistakes before submitting incorrect data.

Barcode Scanner Support

One of the features I wanted to include was barcode scanner support.

For a point of sale system, barcode scanning can make product search and sales faster.

The idea is simple:

The user scans a barcode.
The frontend reads the barcode value.
The system searches for the matching product.
The product is added to the sale or displayed for editing.

This feature made the project feel much closer to a real POS system.

Challenges

One of the biggest challenges was keeping the frontend organized as the number of screens increased.

At the beginning, it is easy to build each page separately.

But as the project grows, duplicated code becomes a problem.

Some questions I had to think about were:

Which components should be reusable?
Where should API calls live?
How should authenticated state be managed?
How should forms be structured?
How can the UI remain simple as features are added?

These decisions helped me understand that frontend development is not only about making the interface look good.

It is also about structure, usability and maintainability.

What I Learned

Building the frontend helped me improve in several areas:

Creating reusable components
Managing authentication state
Connecting React with a Spring Boot backend
Structuring a Next.js application
Working with API services
Building forms and tables
Thinking about user experience
Designing screens for real workflows

The biggest lesson was that a good frontend is not just about visuals.

A good frontend should help users complete their tasks clearly and efficiently.

What’s Next

In the next post, I will focus on deployment.

I will share how I deployed POS Lite using AWS EC2, Docker, Vercel and Cloudflare, and what I learned from connecting the frontend and backend in a production-like environment.

Thanks for reading.

How I Designed the Backend for My Point of Sale System with Spring Boot

Guadalupe Rosas — Wed, 17 Jun 2026 20:12:40 +0000

Introduction

In the first post, I shared an overview of POS Lite, a full stack point of sale system I have been building for small businesses, stores and gyms.

In this second post, I want to focus on the backend.

The backend is one of the most important parts of the project because it handles the core business logic, authentication, database communication and the API consumed by the frontend.

For this project, I built the backend using Java, Spring Boot, Spring Security, JWT authentication and PostgreSQL.

Backend Goals

Before writing the backend, I wanted to define a few goals.

The backend needed to be:

Simple enough to understand and maintain
Structured enough to grow over time
Secure enough to protect private routes
Clear enough for the frontend to consume
Close to how a real business application would work

I did not want to build only a basic CRUD API. I wanted the backend to support real flows like authentication, inventory management, sales tracking and reporting.

Tech Stack

The backend uses:

Java
Spring Boot
Spring Security
JWT
PostgreSQL
Spring Data JPA
Maven
REST APIs

This stack helped me practice several common backend development concepts in one project.

High-Level Architecture

The backend follows a layered structure:

Controller → Service → Repository → Database

Each layer has a specific responsibility.

The Controller layer receives HTTP requests and returns responses.

The Service layer contains the business logic.

The Repository layer communicates with the database.

The Database stores the system data using PostgreSQL.

This separation helped me keep the project more organized and easier to maintain.

Main Backend Modules

POS Lite includes several backend modules.

Authentication

The authentication module handles user login and protected access.

It uses JWT so that the frontend can authenticate users and send the token when accessing private endpoints.

Products

The products module manages product information such as name, price, category and stock.

This module is important because products are used in inventory, sales and reports.

Inventory

The inventory logic helps track product stock and identify products with low stock.

This is one of the features that makes the project feel closer to a real-world business system.

Sales

The sales module handles sales transactions.

This part connects products, quantities, prices and totals.

It is one of the most important flows in the application because it represents the main operation of a point of sale system.

Reports

The reports module is used to generate useful information from the system data.

For example:

Sales reports
Inventory reports
Low stock reports

This helped me think beyond basic CRUD and more about how users would actually use the system.

API Design

The backend exposes REST endpoints that the frontend can consume.

Some example routes are:

POST   /api/auth/login
GET    /api/products
POST   /api/products
PUT    /api/products/{id}
DELETE /api/products/{id}

GET    /api/categories
POST   /api/categories

GET    /api/sales
POST   /api/sales

GET    /api/reports/sales
GET    /api/reports/inventory

The goal was to keep the API predictable and easy to understand.

A clear API structure makes frontend development easier because each module has a defined purpose.

Authentication with JWT

Authentication was one of the most important backend features.

The general flow is:

The user logs in with valid credentials.
The backend validates the credentials.
The backend returns a JWT token.
The frontend stores the token.
The frontend sends the token when requesting protected resources.

Protected requests include the token in the authorization header:

Authorization: Bearer <token>

This helped me understand how stateless authentication works in a full stack application.

Database Design

The database was designed around the main entities of the system.

Some of the main entities are:

Users
Products
Categories
Sales
Sale items
Inventory records

A simplified relationship would look like this:

Category → Products
Sale → Sale Items
Product → Sale Items
User → Sales

This structure allows the system to track which products belong to each category, which products were sold and how sales are connected to users.

Challenges

One of the biggest challenges was deciding how to organize the backend so it would not become messy as the project grew.

At first, it is easy to create endpoints quickly. But as more features are added, structure becomes more important.

Some questions I had to think about were:

Where should the business logic live?
How should the API responses be structured?
How should protected routes be handled?
How should database relationships be modeled?
How can the backend stay maintainable as new modules are added?

These decisions helped me understand backend development beyond just writing endpoints.

What I Learned

Building the backend helped me improve in several areas:

Structuring a Spring Boot project
Creating REST APIs
Working with PostgreSQL
Using Spring Data JPA
Implementing JWT authentication
Separating responsibilities between layers
Thinking about business logic
Designing backend modules for a real application

The biggest lesson was that backend development is not only about making endpoints work.

It is also about designing a structure that can support the application as it grows.

What’s Next

In the next post, I will focus on the frontend side of POS Lite.

I will share how I built the interface using React / Next.js, how the frontend communicates with the backend and how I structured the main screens of the application.

Thanks for reading.

Building POS Lite: A Full Stack Point of Sale System with Spring Boot, React and AWS

Guadalupe Rosas — Wed, 17 Jun 2026 10:47:49 +0000

Introduction

Over the last months, I have been building POS Lite, a full stack point of sale system designed for small businesses, stores and gyms.

The goal of this project is not only to build a working application, but also to practice and demonstrate real-world software engineering skills: backend development, frontend development, authentication, database design, deployment and cloud infrastructure.

I wanted to build something closer to a real business application, not just a simple portfolio project.

Tech Stack

POS Lite is built with:

Java
Spring Boot
Spring Security
JWT Authentication
PostgreSQL
React / Next.js
Docker
AWS EC2
Vercel
Cloudflare

What POS Lite Does

POS Lite includes features commonly needed in a point of sale system:

Product management
Category management
Inventory control
Sales tracking
User authentication
Dashboard metrics
Low stock alerts
Barcode scanner support
Sales and inventory reports

The idea was to create a system that could be useful in a real-world context, especially for small businesses that need a simple way to manage sales and inventory.

Why I Built This Project

Many beginner projects are useful for learning, but they usually stop at basic CRUD operations.

With POS Lite, I wanted to go further and work on problems that are closer to real software development:

How should the backend API be structured?
How should authentication be handled?
How should the frontend communicate with the backend?
How should the database model support real business flows?
How should the app be deployed?
How can the project be presented professionally?

This project helped me connect different parts of full stack development into one complete application.

Backend Overview

The backend was built with Spring Boot and exposes REST APIs for the main business modules.

Some of the backend responsibilities include:

Managing products and categories
Handling sales operations
Protecting endpoints with authentication
Connecting to PostgreSQL
Returning structured data to the frontend

One of the most important parts of the backend was keeping the structure clean enough so that new features could be added without making the project difficult to maintain.

Frontend Overview

The frontend was built with React / Next.js.

The main goal was to create an interface that feels practical for a real user, not just a technical demo.

Some of the frontend modules include:

Login
Dashboard
Inventory
Sales
Product forms
Reports
Barcode scanner flow

I also focused on making the UI clear enough for a business user, because a point of sale system should be fast and easy to use.

Deployment

The project uses a cloud-based deployment setup:

Backend deployed on AWS EC2
Frontend deployed on Vercel
Domain and DNS managed with Cloudflare
Docker used for containerization

This part helped me understand more about environment variables, server configuration, deployment errors, frontend/backend communication and production-like setups.

What I Learned

Building POS Lite helped me improve in several areas:

Designing REST APIs
Working with authentication
Structuring a full stack project
Connecting frontend and backend
Managing database entities
Deploying applications to the cloud
Thinking about software from a product perspective

The biggest lesson was that building a complete project teaches things that isolated tutorials usually do not cover.

What I Will Share Next

This is the first post in a small series about building POS Lite.

In future posts, I want to write about:

How I designed the backend with Spring Boot
How I handled authentication with JWT
How I built the frontend with React / Next.js
How I deployed the app with AWS EC2, Docker, Vercel and Cloudflare
What I learned from building a real full stack project

Final Thoughts

POS Lite is still evolving, but it has already helped me practice many important parts of full stack development.

I am using this series to document the process, share what I learn and continue improving the project over time.

Thanks for reading.

From “Overqualified” to IT Jr: 6-month update on my career pivot #webdev #career #programming #productivity

Guadalupe Rosas — Mon, 01 Dec 2025 18:19:19 +0000

A few months ago I wrote about a really uncomfortable experience inside my own company:

I applied internally to grow as a developer and ended up being called “overqualified” and even “unable to code” — without anyone ever seeing me write a single line.

If you haven't read that story yet, here it is:
👉 Am I really overqualified… or just uncomfortable for others?

That post generated more reactions than I expected.

Some people related to the story, others shared their own toxic experiences and career doubts.

This is the 6-month update.

Same company, new role

I’m still in the same company, but now I work as a Junior IT Engineer instead of a Test Engineer Jr.

On paper it might look like a small change, but for me it was a big shift:

I’m closer to infrastructure and support instead of just testing.
I help people solve real problems every day.
I get to touch networking, printers, servers, databases and internal tools.
I still code small scripts and tools whenever I can.

Most importantly: I feel less like a threat and more like someone who actually adds value.

What my day as an IT Jr looks like

Some examples of what I handle now:

Troubleshooting printers (including industrial label printers) and drivers.
Managing IP reservations and DHCP entries when new devices appear on the network.
Helping users with Windows issues, performance problems and basic automations.
Using tools like DBeaver and SQL queries to support other areas that need data.
Checking connectivity, VPN problems, and general “why is this not working?” tickets.

It’s not glamorous. There’s no “big framework” or fancy buzzwords.

But it’s real work that keeps a factory moving. Every ticket is an opportunity to learn something new.

My “POS-lite” side project

Even though my daily job is more IT-focused, I didn’t want to lose the dev side of me.

So I’m building a personal project: a Point of Sale (POS) system.

The idea is to use it in small businesses and gyms (and to keep learning modern tools):

Stack:

Backend: Java + Spring Boot
Frontend: React
Database: MySQL / PostgreSQL
Other pieces: Docker, Git, GitHub, CI/CD
Future ideas: barcode scanner integration, product packs, stock alerts, and deployment on the cloud

I’ve been working on features like:

Creating and editing products
Handling stock and packs of products
Scanning codes to add items quickly
Basic reporting

This project helps me stay up to date with clean architecture, REST APIs, error handling, Git flow, and deployments.

Inside the company I may be “IT Jr”, but outside I’m still pushing myself as a developer.

What I’ve learned in these months

Looking back, here are a few lessons that stayed with me:

Being called “overqualified” or “too much” usually says more about the environment than about you.
You can be in the wrong team inside the right company.
It’s possible to pivot internally to a role where your curiosity is seen as an asset, not a threat.
Side projects can keep your motivation and skills alive, even when your day job is not perfect.

What’s next

I’m currently focusing on:

Growing in my IT Jr role, understanding more about infrastructure and operations.
Improving my English to open more international opportunities.
Pushing my POS-lite project forward and polishing it enough to use as a real portfolio piece.

If you read my first article and felt something similar, this is for you:

You are not “too much”. You might just be in a place that doesn’t know what to do with everything you bring.

Thanks for reading — and if you have any advice, experience or questions, I’d love to read your comments.

Am I really overqualified... or just uncomfortable for others?

Guadalupe Rosas — Wed, 28 May 2025 01:21:11 +0000

I applied to grow

I applied internally for two open positions in my company: one as a Software Developer and another as a Junior Web Developer. I wanted to move toward a field more aligned with my interests and skills, and I was genuinely excited.

However, my manager offered me a spot on his own team, since they had an internal web development team. He mentioned they used PHP—which I don’t deeply master—but also said I could use ChatGPT as needed, so I accepted with a positive attitude and willingness to learn.

Day one: a red flag

On the first day, I was paired with the only developer on the team. During our conversation, he bluntly told me I was “overqualified,” and that he didn’t agree with the tech changes I had “suggested.”

To clarify: I never suggested any changes. I just asked if he knew any PHP frameworks, since the internal website they built was running quite slowly, and I wanted to understand its architecture.

What I found was extremely complex and messy code: files with over 10,000 lines, PHP mixed with HTML, no clear separation of concerns, and zero documentation. A textbook case of spaghetti code in production.

A hostile environment

The conversation started turning hostile. When I asked him directly if something about me bothered him, he said yes: I was overqualified. It was clear my presence was uncomfortable to him.

He constantly tried to make me look bad, possibly due to insecurity or ego—I honestly don’t know.

Later, the same developer confronted me about having a personal consulting gig (which is public), insinuating that I shouldn’t have one if I didn’t know how to set up a physical server. I’ve never claimed to be an expert in that, and I made it clear from the beginning.

The manager: vision or contradiction?

I also spoke with the manager, who eventually didn’t approve my transfer request out of the team. But before that, when I asked to talk, it turned into a direct confrontation.

He ended up saying I didn’t know how to code—without ever seeing me write a single line in context. That comment threw me off completely. It was a shallow and unfair judgment of my work and profile.

He also told me he could build websites himself using ChatGPT. He said it in a condescending tone, as if using modern tools was a sign of weakness or laziness, when in reality, they are a valid part of today’s development workflow.

Minimum tools… barely offered

The technical setup was also discouraging:

I was given a laptop with no internet access.
I couldn’t install VS Code or configure my preferred tools.
Despite being told I could use ChatGPT, I had no access to it.
They expected me to know how to set up physical servers and SSL certificates—skills I’m open to learning, but which require guidance and proper environments to practice.

I researched it, yes, but couldn’t try it due to the restrictions.

I tried to adapt: even after hours

Despite all this, I understood the vision the manager wanted: a more modern, robust, scalable environment. That aligned with my interests, so I took initiative. After work hours, I started building a demo using PHP, Laravel, and MySQL.

I tried to propose a more modern structure, aiming to solve many of the issues I had observed: better architecture, improved loading speed, maintainable code. I didn’t get to finish it, but I did it with commitment and respect for the work.

However, instead of opening the conversation or valuing the effort, the environment grew more hostile. It wasn’t about building together—it was about control.

Am I a developer or just a copy-paster?

This experience left me confused. It made me question myself and my skills. I felt judged, undervalued, even humiliated.

I started wondering: do I really code—or just copy and paste?

The truth is: I do code. With mistakes, and with constant learning, like everyone in this field. But I also know how to listen, research, verify my sources, and ask for help when I need to.

Final thoughts

What hurt the most wasn’t the rejection—but the treatment. The hostility. The way I was made to feel "less than" for trying to do things right or for thinking differently.

My intention was never to replace anyone or impose anything. I simply wanted to contribute through my strengths, as anyone with technical vocation would.

What do you think?

Have you ever gone through a similar experience?
How do you handle situations where your knowledge or willingness to improve is seen as a threat?
Is it fair to demand technical work without providing basic tools?
Do you think it's reasonable to tell someone they can't code just because they don’t know how to set up a physical server?
Should I leave this company? (Open to offers 😅)

I'd love to hear your thoughts.

And if you made it this far: thank you 🙌

Books of interest

Guadalupe Rosas — Tue, 14 Dec 2021 20:05:29 +0000

short post to share books in pdf I hope they are useful greetings !!!!

enjoy!

My first freelance job part 3

Guadalupe Rosas — Sat, 11 Sep 2021 07:19:46 +0000

As I have been telling in previous posts I had a bad experience in my first job as a freelancer and this was because the deal with the client was led by a third party (a girl who contacted me on facebook).
To put it in context:
The story starts when this girl contacts me to help her with a school project, I non-profit helped her in her project.
A month later she contacts me offering me to do a real project for the company on which she had based her school project, because they liked the design.
So I started with the project but I never got any economic remuneration ... a month after the delivery (about three days ago) I decided to send mail to the company to tell them why his page had never been published and the delay of the same emphasizing the lack of economic remuneration.
The next morning I received a call from the company where they informed me that they had already covered 80% of the project for a month ago (what I had charged from the beginning), because this girl had charged even more (so the company still owed her money), that's right ! the girl had already charged and had not paid me !!!.
I reported the situation to the person at the company and they decided to sue the girl for breach of contract, I received a call from her claiming that I had communicated with the company and she offered to pay me the amount that I had charged (even knowing that she charged more, she never told me).
But well I no longer wanted to have any contact with her so I told her that I was aware of the fraud she had done and that I wished her good luck in her legal process, stressing that there was no rancor on my part because they were difficult days for me (eating only once a day for lack of money because I lost my job and my apartment as a result of being able to finish this project in a timely manner).
-----THE GOOD NEWS.-------
After talking with the representative of the company they offered me to pay the page and today I received MY FIRST PAYMENT FOR A WEBSITE made by me !!! and they also offered me a possible second project (this is waiting for authorization).
Now I have direct contact with the company and I am happy to work in what I like in a "formal" way, for the first time !!! !!!
For the hiring of my services I have relied on a contract and I hope that everything goes well.
PS; This is undoubtedly a clear example that your quality of personal values can lead you to a good job or to a legal problem from which you will not get out well.
I hope you like this experience that I am glad to share with all of you !
greetings and blessings to all of you !!!!

My first freelance job

Guadalupe Rosas — Sat, 28 Aug 2021 02:36:30 +0000

This is the continuation of my experience in my first freelancer job, I'll be brief.... after they had not paid me and I lost total contact with the client they called me yesterday 26-08-21 to tell me that they would pay me this Saturday (they said they had financial problems and that's why they had not made the payment) and that they would like to continue working with me but they would like to add two other programmers (without experience) to make an e-commerce which I don't see so convenient.
I answered them that yes, I will continue working with them but it will be under a contract previously signed by me, (after the bad experience I decided to make a contract to avoid that bad taste in my mouth again).
What do you think? should I continue working with these people?
yes, no, why?
Thank you in advance for your comments !
Greetings!

My first freelance job

Guadalupe Rosas — Mon, 23 Aug 2021 07:59:42 +0000

I thought a lot about writing this ...
I don't know how beneficial it will be for my professional development, but I don't want to be left with the desire to share this first experience.
It all started helping a girl to develop a website for a company (as a school project), after that she contacted me to propose me a business.
The design that I had implemented in her project they had liked and she needed my help to make another similar and improved one and this time paid because the first time I supported this person I didn't charge anything.
I decided to implement a landing page with a minimalist style, intuitive, and full contact with the customer through messenger (my first proposal was an e-commerce) but they found it too expensive...
so I elaborated the design and presented it with an estimated delivery time of 1 month to 1 month and a half always sticking to spring methodology.
The first mistake was not to generate a contract with the specifications that the client should test and respect during the delivery time because the person I was supporting assured me that they were totally trustworthy and that she had already worked with them before.
Anyway ... once the design was presented and approved I got down to work but the client constantly delayed me with changes he wanted at the last minute and it should be noted that I shortened the delivery time to about 3 weeks or 2.
So I decided to see it as a challenge and not as an abuse by this company....
In the first instance I asked for 50% of the total payment in advance but they refused, they said that since it was the first time they would work with me the payment would be made until the final delivery of the project (at least that's what this person told me) since being their clients they did not allow me to have any contact with them.
So well ... I delivered in time and form and surprise ... the payment did not arrive as agreed .... I told them that there was no problem and that I would wait no problem ... the day arrived .... and the payment ... still did not arrive .... then they told me that next week I would have my money now that they had had economic problems and that now it was a fact but what do you think?
Exactly. the payment never arrived ....
in the last contact I had with them....
they told me that they already had a SECOND PROJECT haha but they didn't mention anything about the money they owed me ...
so I decided to unsubscribe the page ...
and well ... I am left ... with the code .... and my time invested ... and yes .... without money ....
I guess this has happened to more than one of you, I would like to read your opinions about it.
at the moment I am trying to join Workana ... but ... my profile is still pending review ....
if you have any suggestions for freelancer sites I would appreciate it.
and again leave your comments
thank you very much and best regards !

DEV Community: Guadalupe Rosas

Inbox Zero for Devs: How I Built a JavaScript Script to Destroy Gmail Spam

🛠️ The Solution: Google Apps Script + JavaScript

⚙️ How to Set It Up in 3 Steps:

🏥 A Personal Note from the Author

Lessons Learned Building POS Lite: From Idea to Full Stack Application

Introduction

Building a Real Project Is Different from Following Tutorials

Start Simple, Then Improve

Backend Structure Matters

Authentication Is More Than Just Login

Frontend Is Not Just About UI

Deployment Changes Everything

Environment Variables Are Critical

Small Bugs Teach Big Lessons

Documentation Helps You Think Clearly

What I Would Improve Next

What I Would Do Differently

Advice for Other Developers

Final Thoughts

Deploying POS Lite with AWS EC2, Docker, Vercel and Cloudflare

Introduction

Deployment Goals

Architecture Overview

Why I Used Vercel for the Frontend

Why I Used AWS EC2 for the Backend

Preparing the EC2 Instance

Dockerizing the Spring Boot Backend

Building and Running the Backend Container

Environment Variables

PostgreSQL Database

Cloudflare for Domain, DNS and SSL

Connecting Frontend and Backend

Common Issues I Faced

What I Learned

Key Takeaways

What’s Next

Building the Frontend of POS Lite with React, Next.js and Material UI

Introduction

Frontend Goals

Tech Stack

Main Frontend Modules

Authentication

Dashboard

Products

Categories

Sales

Inventory

Reports

Application Structure

API Communication

Authentication Flow

UI/UX Decisions

Forms and Validation

Barcode Scanner Support

Challenges

What I Learned

What’s Next

How I Designed the Backend for My Point of Sale System with Spring Boot

Introduction

Backend Goals

Tech Stack

High-Level Architecture

Main Backend Modules

Authentication

Products

Categories

Inventory

Sales

Reports

API Design

Authentication with JWT

Database Design

Challenges

What I Learned

What’s Next

Building POS Lite: A Full Stack Point of Sale System with Spring Boot, React and AWS

Introduction

Tech Stack

What POS Lite Does