Notes along the way.

Deleted something by mistake? No worries, RedCheck now has a Recycle Bin. 🗑️

Accidental deletions are incredibly common and a surefire way to ruin the UX. That’s why the latest feature I’ve been working on is a complete soft-delete and recycle bin system.

On paper, it sounds like just adding a new column to the database and calling it a day. But implementing this robustly broke our initial entity contracts, which meant some deep refactoring:

🛠️ Backend & database

• Migrated the data model to include soft-delete flags (deleted).
• Refactored queries and endpoints to ensure deleted items don’t pollute the main views.
• Updated stored procedures and MySQL events so the new entity constraints wouldn’t break background automation.

🎨 Frontend

• Designed a dedicated view with smooth transition animations so restoring or permanently deleting tasks feels fluid.
• Created friendly empty states and global actions like “Empty trash”.

What’s the main takeaway from this iteration? No feature, no matter how trivial it seems, is ever just a quick fix. Simply modifying the base entity contracts forced a rethink of a large part of the architecture just to keep the database consistent and the frontend spotless.

Feel free to check it out at redcheck.es! Any feedback or suggestions for improvement are more than welcome.

Saying goodbye to manual deployments is one of the most satisfying milestones in software engineering. 🚀

Manual deployments are a bottleneck. To scale RedCheck efficiently, I needed to eliminate them entirely. I’ve just overhauled our deployment architecture, transitioning from a traditional manual setup to a fully automated CI/CD pipeline, and the architectural leap is massive.

Here’s a quick breakdown of the new stack:

• GitHub Actions orchestrating the entire pipeline (testing, building, and deploying).
• Docker Hub acting as our registry for immutable images.
• Clean server architecture. Production now strictly acts as an execution environment. No source code, no build tools, and no manual .jar handling; just pure Docker containers orchestrated securely via SSH.

Automating this infrastructure ensures that the focus remains entirely on writing clean, SOLID Java and Spring Boot code, knowing that our pipeline acts as an uncompromising gatekeeper for quality and stability.

Building a productivity platform is great, but a solid automated infrastructure is what actually keeps it stable in the long run. 💻⚙️

There is a huge gap between code working on localhost and a live application in production. Over the weekend, I decided to cross that line and deployed RedCheck on its own domain: redcheck.es. 🚀

It started as a standard task manager, but I wanted to take it a step further by integrating SmartCheck AI to analyze workload. Bringing this to production was a solid technical challenge:

• ⚙️ The backend & deployment: getting the app out of my local environment meant containerizing with Docker, setting up the server from scratch, and handling the infrastructure.
• 🧠 AI token optimization: honestly, the hardest part wasn’t the AI itself, but designing the backend architecture to handle asynchronous LLM requests and optimize token usage without burning through resources.
• 🎨 A nod to UX: I’m definitely more of a backend guy, but I believe in reducing cognitive load. Instead of raw dates, deadlines show up as “Today” (pastel red), “Tomorrow” (pastel yellow), or “The day after tomorrow” (pastel green). A tiny frontend detail, but it saves the user from having to calculate days.

Feel free to play around with it, test the AI, or try to break the server! Feedback on the architecture or performance is super welcome. 🏗️

Update: RedCheck now lives at redcheckapp.com — the old redcheck.es address redirects there.