DEV Community: S.Babas

How I migrated from GitHub to Codeberg

S.Babas — Fri, 09 Oct 2026 08:03:20 +0000

Why I migrated from GitHub to Codeberg?

I migrated from GitHub to Codeberg mainly because GitHub is a proprietary platform, which is a sovereignty issue for me (notably because their Copilot AI is trained on public code).

My main goal was to find simplicity: fewer unused features, a platform that gets straight to the point.

My steps to migrate my project from GitHub to Codeberg:

I used these commands to perform the migration:

# 1. Change the remote URL to point to Codeberg
git remote set-url origin https://codeberg.org/NuxiPro/Core.git

# 2. Push all branches and tags
git push --all
git push --tags

I could have used Codeberg's native import tool, but since the NuxiPro Core repository was private, I preferred to do the transfer manually by choice. It took a few minutes and everything went very well.

What I gain and what I lose leaving GitHub for Codeberg

What I gain:

Everyday simplicity
No overload of unused features
Sovereignty (Codeberg is hosted in Germany by a European non-profit)
Ethics: no business model based on exploiting your code
A calmer, cleaner environment, without proprietary tools

What I lose:

Less visibility than on GitHub
Fewer out-of-the-box tools, but more control over what I add

Self-hosted Forgejo runner on my personal PC

I decided to self-host my own runner on my personal machine.

I use the Docker-in-Docker (DinD) strategy: jobs run in a separate Docker daemon, without direct access to my host's Docker socket, which guarantees good isolation for my build environments.

I made this choice so I don't saturate Codeberg's shared community resources during my testing and deployment phases. Eventually, I will move this runner to a dedicated server so I no longer depend on my desktop PC.

Quick note about the demo

I kept the demo repository on GitHub for now, because it will very soon be stopped and deleted. Since it was a test version requiring unnecessary maintenance, it will be replaced directly. I will let you know before its final removal.

Building NuxiPro Cloud: What's new

S.Babas — Wed, 16 Sep 2026 08:01:00 +0000

I decided to make the Cloud version of NuxiPro secure and minimalist on a day-to-day basis, so I never have to worry about the tool itself, especially since it will store my own personal and professional data.

For now, this version of my project isn't ready or functional enough yet to handle real, critical data in production.

My backend tech stack

Here are the technologies I've added to Cloud NuxiPro:

Better Auth (for authentication)
Drizzle (ORM for PostgreSQL)
Hono (for the backend server)
Fractional indexing (for managing task position on the Kanban board)
Nginx (reverse proxy planned in front of the backend before Cloud NuxiPro launches)
TypeScript (main backend language)
Bun (runtime to run the backend)
date-fns (for date handling)
Zod / Hono validator (for validating incoming and outgoing data)
OpenObserve (for centralized log management)

Why this choice for the backend?

I chose this stack to make NuxiPro efficient, predictable, and to guarantee resilient security. Since I'll be storing my own data there, and I regularly see SaaS products get hacked, I refused to be next on that list. My goal is to build a system where users are safe thanks to a sovereign tool, hosted in Finland with UpCloud (sovereign, performant, and very appealing in terms of price).

I went with Hono and Better Auth because they're simple to use, highly efficient, and help me build solid security.

I also integrated Fractional indexing to manage card position on the Kanban board as efficiently as possible. It lets you drag and drop a task between two columns or above another one without having to rewrite the value of every other task. In short, it avoids collisions while keeping things smooth day to day.

To centralize my logs and handle errors, I use OpenObserve. The goal is to spot and fix crashes very quickly. Even before the Cloud version ships, I'm going to run a battery of intensive tests with the explicit goal of trying to crash the system. That will let me confirm it's truly robust. Of course, that won't rule out 100% of future bugs, but these crash tests will prove the tool's solidity.

My frontend tech stack

TypeScript (for simplicity and type safety)
TanStack Router / Query (for handling dynamic pages and state)
React (for building the user interface)
Zod & React Hook Form (for validating form input data)
shadcn/ui (so I don't recreate the interface from scratch and waste time on pointless UI bugs)
Tiptap (for building the Markdown editor)
dnd kit (for smooth drag & drop in the Kanban board)
Bun, Vite & Hono Client (for building, bundling, and communicating with the API)

Why this choice for the frontend?

I chose this stack because it's simple, maintainable over the long run, and built to last several years without becoming obsolete.

Why did I choose this overall stack?

I designed this stack mainly to build an efficient, simple daily work tool, free of unnecessary visual noise that wastes time.

My priority was (and still is) a tool suited to people who work solo. Nowadays, most software keeps piling on features instead of simplifying, which creates friction on a daily basis.

Being someone very demanding about security, performance, and freedom from bugs, I want my own work tool to be efficient and require zero energy to manage. NuxiPro is here to serve me every day, both in my professional and personal projects.

Sovereignty & Compliance

S.Babas — Fri, 28 Aug 2026 06:36:00 +0000

I am currently focusing on sovereignty and compliance for NuxiPro. My goal is to build a truly helpful, privacy-first tool that respects user data.

Here is the roadmap I am executing before pushing forward with NuxiPro's cloud version:

GDPR Compliance: Clearly document data storage locations, processing methods, and third-party sub-processors.
Legal Hub: Centralize all legal and compliance documents directly on the landing page.
GDPR Traceability: Implement a strategy to track user consent, permissions, and privacy preferences accurately.

Ultimately, my goal is to deliver a sovereign, privacy-respecting, minimalist alternative to Trello.

Hiding tasks instead of archiving them in their dedicated zone slows down the tool

S.Babas — Tue, 18 Aug 2026 14:36:47 +0000

I tested this approach of hiding completed tasks, similar to what most tools on the market do

However, I quickly realized that it doesn’t solve the problem of interface clutter.
By simply hiding them, these tasks remain present in the background.

As soon as you click on "show archives," the interface gets overloaded due to this pseudo-archiving system.
The result? The tool slows down progressively, and the frontend keeps trying to load data that was never actually moved to a dedicated archive zone.

This is why I created a minimalist Kanban board, stripped of unnecessary features, which truly archives completed tasks by moving them out of the main workflow.

I am currently building NuxiPro in public, sharing my journey and insights in case they can be helpful.

Have you ever encountered this slowdown issue in your daily use of productivity tools?

First days of NuxiPro's launch on Product Hunt, here's what it revealed

S.Babas — Thu, 13 Aug 2026 14:01:16 +0000

NuxiPro is a tool that automatically archives your tasks to stop the "Done" column from turning into a graveyard of completed tasks, freeing up your workspace visually and keeping the tool clean and minimalist, without it trying to load tons of tasks into the Done column and starting to slow down.

Early in the launch, I quickly noticed that NuxiPro's demo had a barrier to entry: the product tour.

A product tour is a simple guided walkthrough that shows users, the first time they land on a tool they just discovered, the value of that tool, i.e. what they gain by using it.

My mistake was leaving the NuxiPro demo raw, with no guide to help users understand the tool and reach their aha moment.

The result: a user would land on the demo, not know what to do, click around a bit, then close the tab out of frustration and leave without understanding what they stood to gain.

Even for a product that solves a real, painful problem, if there's no guide helping the user understand what they gained from using it, they just leave.

How did I spot this problem?

I integrated PostHog to analyze engagement on the demo and understand the drop-off points. On the security/GDPR side, the maskAllInputs option is pushed to the max:

`posthog.init(token, {
  session_recording: {
        maskAllInputs: true, // Blurs all input fields (inputs/forms)
 },
});`

My solution was to integrate driver.js, a lightweight library that helps people get their bearings with your product, while guiding them toward the project's main goal.

My steps were as follows:

`Start → [1: Hello] → Click "Let's go!"
       → [2: Drag task to DONE] → Drop successful
       → [3: Archives opened] → Close Archives
       → [4: Click waitlist] → Dialog opened → Tour complete`

I need beta testers and feedback on the demo before building the cloud version of NuxiPro.

I'll give you early access before the official launch, on the day the cloud version is ready.

nuxipro