It’s been a while since my last update — and the past month hasn’t been all about Fidely.
Between studying for a project management course 📚 and other work commitments, time has been tight.

But I still managed to make progress on one crucial piece: the first version of the Fidely landing page!

The First Landing Page is Live!

The landing is focused on shop owners, as they are my primary target customers.
It’s based on the mockup I shared last month, and I’m happy to finally have something concrete online:
👉 fidely.pulbasso.dev

For the tech stack, I used:

• Next.js

• React

• TailwindCSS

I deployed the landing on Netlify. Technically, it could be fully exported as a static site, but for now I decided to skip this step to keep things simple.

Is it perfect? Absolutely not.
But I strongly believe it’s way better to launch an imperfect first version and improve iteratively, rather than chase perfection and risk getting stuck.

Why Small Wins Matter

Even though Fidely is still small, it’s surprisingly complex:
So many moving parts, from the app logic to the business aspects.

With limited time available, I need incremental results to stay motivated and keep pursuing my goal.

Seeing the landing live, even in its raw form, gives me a sense of progress and something tangible to build upon.

🤖 Evolving My AI Workflow

Lately, I’ve been integrating AI more and more into my development process — and I’m slowly finding my own balance.

A few personal thoughts:

• “Vibe coding” with AI is dangerous:
  Sure, it gives you a quick solution, sometimes even working code. But it often hides key implementation details, which leads to a shallow understanding of your codebase.
  Without that deep knowledge, evolving your app later becomes a nightmare.

• Guided AI usage is key:
  Using AI purposefully, with focused prompts, while maintaining control over the architecture and code structure, has proven the most effective path for me.
  It dramatically speeds up development without sacrificing code quality or maintainability.

• AI for brainstorming:
  Having your codebase in context and using AI to discuss architecture or design choices is a game-changer. What used to take hours of solo research can now be condensed into a few minutes of collaborative ideation.

Currently, my tools of choice are:

✅ Cursor + Claude for personal projects
✅ GitHub Copilot for work

Early Comparisons

My initial impression?

• Cursor + Claude 3.5 feels ahead in quality and reasoning, especially on complex tasks.

• GitHub Copilot with GPT-4o seems a bit behind, but I’ve used it less intensively, so the comparison may not be entirely fair.

• In personal testing, I’ve noticed better answers from OpenAI’s GPT-4o on ChatGPT compared to the same model used via Copilot.

For now, I find myself leaning heavily on Claude inside Cursor — but I’ll keep testing.

That’s it for this month.
It may not have been the most productive period for Fidely, but even small steps like launching the landing keep the momentum alive.

Stay loyal 😄

Market Research: not as simple as it sounds

With very limited time (as usual), I’ve finally carved out some evenings to work on a proper market analysis for Fidely — with special focus on Italy and my initial target area: Liguria 🇮🇹.

Instead of just relying on random Google searches, I’ve tried to build something a bit more structured and robust:

• ✅ Searched for reliable sources (official reports, studies, government data)

• ✅ Used Perplexity AI and OpenAI Deep Research to find resources I hadn't initially discovered

• ✅ Processed the data inside Google NotebookLM to organize, analyze and double-check sources to minimize hallucinations and mistakes

The goal?
👉 Collect solid, validated data that I can use for future marketing material, landing pages, and potentially to test actual ads and demand.

🎯 Some quick takeaways

• The Italian loyalty market is growing fast: estimated €3.5 billion in 2023, with 11–12% annual growth

• Around 1 million micro & small businesses in Italy could be potential Fidely clients: shops, restaurants, salons, bars, etc.

• In Liguria specifically (my initial focus), there are roughly 10,000–15,000 micro B2C businesses with good adoption potential.

• Despite these numbers, the digitalization level is still very low: only ~46% of Ligurian SMEs have basic digital skills

• Consumers are fully mobile-first:

  • WhatsApp usage: 89% of Italians

  • Mobile payments are exploding: +53% YoY in 2024

  • Digital loyalty apps (Stocard, Klarna, Apple Wallet) are now mainstream.

💡 Why Fidely might fit here

• Many businesses still rely on manual loyalty cards or very fragmented tools.

• Existing loyalty platforms often feel too complex, too expensive, or too generic for very small shops.

• There's room for a "lightweight, easy-to-use, hyperlocal" SaaS focused on helping micro-businesses go digital — without scaring them with CRM jargon, big data dashboards or enterprise software.

One of my favorite stats from this research:

"Acquiring a new customer costs 5 to 25 times more than retaining an existing one."
(Harvard Business Review)

Exactly why loyalty programs can make a huge difference for small local businesses — and exactly why Fidely exists.

The First Landing Page Mockup

With the research done, I started designing the first version of the landing page.

My direct clients are the shop owners, so the landing is fully targeted at them.

I'm not a designer, but I tried to keep it minimal, focused, and clear about:

• The pain points (low return customers, high acquisition costs)

• The solution (easy digital loyalty tools)

• The local focus (Liguria first!)

Here’s a preview of the mockup:

🎯 Landing Page Tech Stack

Unlike the main Fidely app, the landing page will be its own separate project for better flexibility:

• ✅ Next.js 14

• ✅ TailwindCSS

• ✅ Full static export possible → deployable on a CDN like Cloudflare.

In the next days/weeks, I’ll start actually building the landing and running the first real-world market tests.

What's Next?

• 🚀 Build & deploy the landing page

• 📊 Start testing Italian ads to validate real demand

• 🤝 Prepare early onboarding for local shop owners

• 💻 Resume app development with:

  • Reward redemption flow

  • Customer-facing app interface

  • More detailed analytics for business owners

That's it for now!
Slow evenings, but steady progress.

Stay loyal 😄

Back again with another update on Fidely, the loyalty app I’ve been building in my spare time as part of The 10-Minute Company series. I’ve been making steady progress, and I’m super excited to share what’s new—because this time, there’s more polish, more insight, and a better experience.

If this is your first time hearing about Fidely, check out the first post in the series to catch up on what it’s all about.

📊 Home Dashboard Gets Analytics

One of the key selling points of Fidely is helping small business owners understand their customers better. To make this real, I’ve added a basic analytics section on the home dashboard.

This gives the shop owner some quick insights about:

• How many cards are active
• Which campaigns are running
• Key stats from recent activity

The current dashboard acts as a preview—eventually, these metrics will be expanded into a dedicated analytics section with proper filters, charts, and detailed views. But it’s a good first step!

⚡ A Faster Operator Dashboard

Let’s talk about speed. The Operator Dashboard now feels snappier, smarter, and more helpful.

The new flow is designed for real-world usage:
Operators are often juggling customers, so every click matters.

Here’s how it works:

• Search for a card quickly
• Get instant results under the search bar

• If there’s a single match, the app auto-selects the card and shows this view:

  

From here the operator can:

✅ View card details
✅ Join a campaign if the card hasn’t yet
✅ Assign points/stamps immediately
✅ See campaign progress

Once points are added, the app brings the operator back to the search view—so they can help the next customer quickly.

But wait—there’s more!

If the customer unlocks a reward, the app throws a confetti animation (yes, for real 😄), and the workflow pauses, giving the operator time to ask if the customer wants to redeem it.

It’s small stuff, but it matters for UX and flow.

🐛 Bug Fixing Time

I also spent time cleaning up annoying bugs that were dragging the user experience down.

From navigation glitches to weird reloads—many small fixes that, together, make the app feel smoother and more consistent.

💳 A New Card Layout

Inspired by credit cards, I gave the customer card UI a little makeover.

Not sure if this will be the final look, but it’s a fun experiment—and it makes cards feel more "real".

🔔 Global Notification System

Last but not least: I’ve added a toast notification system.
Whenever a user takes an action—like assigning points, joining a campaign, or redeeming a reward—they’ll now get instant visual feedback.

It’s a small feature, but it adds a lot of clarity.

What’s Next?

• More detailed analytics
• Campaign creation wizard
• Customer view and reward redemption flow
• Localization (yes, Fidely is still mostly in Italian 😅)

That’s it for now. As always, I’m building Fidely a few evenings at a time—progress is slow but steady.
If you're working on a microSaaS or playing around with loyalty mechanics, I’d love to hear from you!

Let’s keep building!

In this post, I’ll walk you through what I’ve been building lately. Lots of progress, especially on the frontend, but also a good amount of refactoring under the hood.

If this is your first time hearing about Fidely, I recommend checking out the series to understand the context and the problem I'm trying to solve.

What's New?

Right now, I’m mostly focused on the shop owner’s point of view.

Here’s what a shop owner can now do:

✅ Register/Login
✅ Create and manage one or more companies
✅ Set up loyalty campaigns (both points collection and stamps)
✅ Create customer cards
✅ Assign points or stamps to customer cards from the Operator View
✅ View and manage their user profile

All features are working in the app already — still mostly in Italian, but internationalization is on my radar for the next releases!

🔐 Login & Register

Straightforward login and signup flow. Nothing fancy, but it works!

🏠 Home Dashboard

The app now includes a sidebar with different sections (some are still under construction).

Let’s break it down:

• Company Switcher at the top: if the user manages multiple companies, this dropdown lets them switch between them or create a new one.

  

• Operatività: this section is all about speed. It’s designed for quick actions like:

  • Viewing recent transactions

  • Creating a new customer card

  • Launching the operator interface for assigning points/stamps

• Attività / Campagne / Carte: classic CRUD sections where shop owners can edit their business info, loyalty campaigns, and customer cards.

  

Wizard Engine

One of the coolest things I’ve added recently is a custom wizard engine.

I noticed that multiple flows in the app follow a “step-by-step” pattern—like onboarding, campaign setup, card creation, and more.

So instead of repeating the same logic all over, I built a tiny abstract wizard engine. It handles step navigation and state management, so I can reuse it for any future wizard.

First implementation? The card creation flow:

It’s basic but working! And adding new wizards should now take a fraction of the time.

What's Next?

In the upcoming evenings and weekends (aka my dev time), I’ll be working on:

🔧 Completing more wizards (e.g., for campaign creation)
🪲 Fixing annoying bugs
🛠 Starting to polish the operator flow and customer-side logic
🌍 Adding support for multiple languages

That’s all for now! If you're building something similar or have questions about my tech stack or structure, let’s chat!

I'll keep you posted.
Until next time—stay loyal 😄

Today’s rabbit hole starts with a simple question:

"How to build a basic CPU monitor using Rust and a terminal UI?"

The real goal here is to create a simple and visual example to practice using threads in Rust. It’s a small playground to explore shared memory, concurrency, and synchronization.

For this little project we will use the following:

• Cursive: a powerful TUI (Text-based UI) library in Rust

• sysinfo: a system stats collector

• Threads + Arc<Mutex<T>> for safe shared state

Project Setup

Create a Cargo project, add the Cursive and Sysinfo dependency…

cargo new threads-cursive-sysinfo-example
cd threads-cursive-sysinfo-example
cargo add cursive
cargo add sysinfo

The Code

// main.rs
use std::{sync::{Arc, Mutex}, thread, time::Duration};

use cursive::{
    view::Nameable,
    views::{LinearLayout, TextView, Panel, DummyView},
    Cursive, CursiveExt,
    theme::{Theme, ColorStyle, PaletteColor, Color},
    align::HAlign,
};
use sysinfo::System;

struct AppState {
  system: Mutex<System>,
  usage_data: Mutex<Vec<f32>>
}

impl AppState {
  fn new() -> Arc<Self>{
    let sys = System::new_all();
    let core_count = sys.cpus().len();
    Arc::new(Self {
      system: Mutex::new(sys),
      usage_data: Mutex::new(vec![0.0; core_count])
    })
  }

  fn refresh_cpu_usage(&self) {
    let mut sys = self.system.lock().unwrap();
    sys.refresh_cpu_all();

    let mut data = self.usage_data.lock().unwrap();
    for (i, processor) in sys.cpus().iter().enumerate() {
      data[i] = processor.cpu_usage();
    }
  }
}

fn create_ui(state: &Arc<AppState>) -> LinearLayout {
    let mut layout = LinearLayout::vertical();

    // Title
    layout.add_child(TextView::new("CPU Monitor")
        .style(ColorStyle::title_primary())
        .h_align(HAlign::Center));
    layout.add_child(DummyView);

    // CPU Cores Panel
    let mut cores_layout = LinearLayout::vertical();
    let core_count = state.system.lock().unwrap().cpus().len();

    for i in 0..core_count {
        cores_layout.add_child(
            TextView::new(format!("Core {}: |", i))
                .style(ColorStyle::primary())
                .with_name(format!("core_{}", i)),
        );
    }

    layout.add_child(Panel::new(cores_layout)
        .title("CPU Usage"));

    // Footer
    layout.add_child(DummyView);
    layout.add_child(TextView::new("Press 'q' to quit")
        .style(ColorStyle::secondary())
        .h_align(HAlign::Center));

    layout
}

// thread for updating the UI
fn start_update_thread(ui_handle: cursive::CbSink, state: Arc<AppState>) {
    thread::spawn(move || {
        while let Ok(()) = ui_handle.send(Box::new({
            let state = Arc::clone(&state);
            move |s| {
                state.refresh_cpu_usage();
                let data = state.usage_data.lock().unwrap();

                for (i, usage) in data.iter().enumerate() {
                    let bar = generate_bar(*usage);
                    s.call_on_name(&format!("core_{}", i), |view: &mut TextView| {
                        view.set_content(format!("Core {:2} : {}", i, bar));
                    });
                }
            }
        })) {
            thread::sleep(Duration::from_secs(1));
        }
    });
}

// Simple ASCII progress bar
fn generate_bar(usage: f32) -> String {
    let total_blocks = 50;
    let filled_blocks = (usage / 100.0 * total_blocks as f32).round() as usize;
    let bar = "█".repeat(filled_blocks);
    let empty = " ".repeat(total_blocks - filled_blocks);
    format!("[{}{}] {:.2}%", bar, empty, usage)
}

pub fn main() {
    let mut siv = Cursive::default();

    // Customize theme
    let mut theme = Theme::default();
    theme.palette[PaletteColor::Background] = Color::Rgb(30, 30, 30);
    theme.palette[PaletteColor::View] = Color::Rgb(40, 40, 40);
    theme.palette[PaletteColor::Primary] = Color::Rgb(0, 150, 150);
    theme.palette[PaletteColor::Secondary] = Color::Rgb(100, 100, 100);
    siv.set_theme(theme);

    let state = AppState::new();
    let layout = create_ui(&state);
    siv.add_fullscreen_layer(layout);
    siv.add_global_callback('q', |s| s.quit());
    start_update_thread(siv.cb_sink().clone(), Arc::clone(&state));

    siv.run();
}

How It Works

The code is ~100 lines and does the following:

1. Initializes a struct AppState that holds a shared System instance and an array of CPU usage data, protected with mutexes.

2. Builds a UI layout using Cursive, showing:

   • A title

   • A dynamically updating panel of all your CPU cores

   • A quit hint at the bottom

3. Spawns a background thread that:

   • Updates the CPU usage data every second

   • Sends updates to the UI thread via cb_sink

   • Draws a simple ASCII progress bar for each core

Let’s break down a few key pieces.

Shared App State

struct AppState {
  system: Mutex<System>,
  usage_data: Mutex<Vec<f32>>,
}

All core CPU data is shared across threads using Arc<Mutex<T>>, allowing the update thread and UI thread to read/write safely.

The UI Layout

TextView::new("CPU Monitor")
  .style(ColorStyle::title_primary())
  .h_align(HAlign::Center);

Each core gets a TextView with a name like core_0, core_1, etc., so we can update it dynamically later.

s.call_on_name(&format!("core_{}", i), |view: &mut TextView| {
    view.set_content(format!("Core {:2} : {}", i, bar));
});

The Update Loop

while let Ok(()) = ui_handle.send(Box::new({...})) {
  thread::sleep(Duration::from_secs(1));
}

Inside this loop, the AppState is refreshed and each core’s usage is rendered as a bar using the generate_bar helper:

fn generate_bar(usage: f32) -> String {
    let total_blocks = 50;
    let filled_blocks = (usage / 100.0 * total_blocks as f32).round() as usize;
    format!("[{}{}] {:.2}%", "█".repeat(filled_blocks), " ".repeat(total_blocks - filled_blocks), usage)
}

Understanding Arc and Mutex in Rust

This whole project revolves around safely sharing and updating data across threads. That’s where Arc<Mutex<T>> comes into play.

• Mutex<T> lets us mutate shared data safely. It ensures that only one thread at a time can access the data inside.

• Arc<T> (Atomic Reference Counted pointer) allows multiple threads to hold ownership of the same value.

Together, Arc<Mutex<T>> means:

"Hey Rust, let multiple threads own this data, but make sure only one thread at a time can actually mutate it."

Here’s what that looks like:

let data = Arc::new(Mutex::new(vec![0.0; num_cores]));

Each thread that needs access clones the Arc:

let data_clone = Arc::clone(&data);

Then locks the mutex before using the data:

let mut usage = data_clone.lock().unwrap();
usage[i] = new_value;

The lock gives you a mutable reference inside a Result, hence the unwrap() (or better: proper error handling).

Run The Example

It’s time to see the result!! 😱

cargo run

You should see something similar.

It’s been a while since my last update in The 10-Minute Company series. I originally thought I’d be able to share progress sooner, but the holiday season (and a few unexpected projects) absorbed much of my free time. Nevertheless, I made some good progress—both on Fidely and on a smaller side project that popped up in early January.

A Quick Detour: Building a Landing Page with Next.js

During the first two weeks of January, I helped a friend who offers online consultations by building a simple landing page for her services. The project was straightforward but fun, and it gave me a chance to work with:

• Next.js for the frontend,

• Brevo (formerly Sendinblue) for handling newsletter subscriptions and automated emails,

• Brevo Meeting for scheduling online consultations,

• Clerk.com for authentication and an admin dashboard,

• Stripe for handling payments and checkout.

One of the most interesting parts of the project was setting up an automated workflow: when someone subscribes to the newsletter and completes the double opt-in, they receive a welcome coupon code via email. This ensures only verified users get access to the special offer, adding an extra layer of engagement and trust.

Now, back to Fidely.

Returning to Fidely: Cleaning Up the Backend

With the side project wrapped up, I finally got back to working on Fidely. The focus of the last few days has been restructuring the backend to improve maintainability and scalability. Here’s what I worked on:

1. Refactoring API Routes

I split API endpoints more logically, ensuring that different resources and functionalities were correctly separated. This cleanup makes the backend easier to navigate and will help with future expansions.

Here’s a quick look at the updated routing system:

import { Router } from "express";
import authenticate from "../../middlewares/authenticate";
import authRoutes from "./auth";
import companiesRoutes from "./companies";
import campaignsRoutes from "./campaigns";
import cardCampaignsRoutes from "./card-campaigns";
import cardsRoutes from "./cards";
import transactionsRoutes from "./transactions";
import campaignBuildersRoutes from "./campaign-builders";

const v1Routes = Router();

// Public routes (no auth required)
v1Routes.use("/auth", authRoutes);

// Protected routes
v1Routes.use("/companies", authenticate, companiesRoutes);
v1Routes.use("/campaigns", authenticate, campaignsRoutes);
v1Routes.use("/card-campaigns", authenticate, cardCampaignsRoutes);
v1Routes.use("/cards", authenticate, cardsRoutes);
v1Routes.use("/transactions", authenticate, transactionsRoutes);
v1Routes.use("/campaign-builders", authenticate, campaignBuildersRoutes);

export default v1Routes;

2. Creating a Simple Seeding System

Manually setting up test data was becoming a hassle, so I implemented an automated seeding script that:

• Clears the database,

• Inserts fake data for testing and demo purposes.

Here’s the updated seed system:

import { SeedContext } from './types';
import { seedUsers } from './users';
import { seedCompanies } from './companies';
import { seedCampaigns } from './campaigns';
import { seedCards } from './cards';

async function main() {
  const context: SeedContext = {
    users: {},
    companies: {},
    campaigns: {},
    cards: {},
    catalogs: {}
  };

  try {
    console.log('🌱 Starting seed...');

    // Seed users
    console.log('Seeding users...');
    await seedUsers(context);

    // Seed companies
    console.log('Seeding companies...');
    await seedCompanies(context);

    // Seed campaigns
    console.log('Seeding campaigns...');
    await seedCampaigns(context);

    // Seed cards
    console.log('Seeding cards...');
    await seedCards(context);

    console.log('✅ Seed completed successfully!');
  } catch (error) {
    console.error('❌ Seed failed:', error);
    process.exit(1);
  }
}

main();

One of the key advantages of using SQLite for both seeding and testing is the ability to spin up different databases for development and testing. This also allows for testing database migrations with Drizzle in a controlled environment.

3. Introducing Automated Testing

Fidely now has its first batch of automated tests! I’ve added both:

• Unit tests for core logic,

• End-to-end (E2E) tests using Mocha and SuperAgent.

This is just the beginning, but having a testing framework in place will make future development smoother and more reliable.

Struggles with Monorepos

One of the biggest challenges I’ve encountered (and still haven’t solved) is setting up a monorepo for both frontend and backend. Since the whole project is in TypeScript, a monorepo could help share code between them.

Yesterday, I spent several hours trying to migrate to pnpm workspaces, but I ran into issues with better-sqlite3 during compilation. The new setup fails to find the compiled drivers—even after trying a postinstall recompilation, nothing changed. 😫

I haven’t figured out a solution yet, and for now, I don’t want to get stuck on this problem. If anyone has dealt with similar issues, I’d love to hear your thoughts! 🤔

Next Steps

I’m really happy with the backend refactor, and my next focus will be the frontend. The plan for the upcoming weeks includes:

• Enhancing the UI/UX,

• Continuing to add automated tests,

• Abstracting the transaction management system to allow for different transaction sources (currently, only operators can generate transactions).

The overall goal remains the same: keeping the codebase clean and flexible so that Fidely can evolve naturally.

That’s it for this update! If you’ve worked on similar refactors, monorepos, or pnpm workspace issues, I’d love to hear your experiences. Let’s chat in the comments or via email!

Until next time! 🚀

Welcome to the first blog article of The 10-Minute Company series! Today, I’m excited to introduce Fidely, a simple digital loyalty app born from a conversation with a friend who owns a shop near my hometown.

He showed me his printed stamp cards—those small cards that reward customers after they make a certain number of purchases. You’ve probably seen these before; they’re a straightforward way to build customer loyalty.

Fidely (a “spaghetti-English” twist on the word “Fidelity”) is essentially a digital version of these loyalty campaigns. It aims to make the process more modern and efficient.

What Does Fidely Do?

Fidely supports two types of loyalty campaigns:

• Points Collection: Shop owners can create a catalog where each reward requires a specific number of points to redeem.

• Stamp Campaigns: Similar to traditional stamp cards, where customers receive a reward after a set number of purchases.

The system generates a unique virtual card for each customer, which they can use to collect points or stamps. What’s even better? The same card works in any shop using Fidely, creating a seamless loyalty experience.

Why Did I Build This?

I started this project about a month ago, but with limited free time—just a few evenings and weekends. My goal is to provide an easy and affordable tool for shop owners to create customized loyalty campaigns. Beyond that, I hope Fidely fosters a local network of offers, connecting shops and their loyal customers.

With Fidely, shop owners can:

• Easily create virtual loyalty cards.

• Engage customers through marketing emails or app notifications (future feature).

• Build a community of interconnected businesses.

Let’s take a closer look at where I’m at with the app.

The Web App: Current Features

At this super early stage, Fidely is not even yet a proof of concept (PoC). Here’s what it can do so far:

1. Shop Owner Features:

   • Sign in with a pre-registered account.

   • View a basic dashboard with insights and quick links.

   • Create virtual cards for customers.

   • Launch two types of campaigns: points collection and stamp-based rewards.

   • Subscribe customer cards to campaigns.

   • Assign points to cards, track progress, and display rewards.

2. Customer Features:

   • Collect points or stamps on their virtual card.

   • Redeem rewards when reaching campaign goals.

Here’s a glimpse of the app in action:

Login Page

Home Dashboard

As you can see, the app is pretty unstyled and basic at this point. Localization is also missing, so enjoy some Italian text sprinkled in. :D

Operator Dashboard

One feature I’m working on is the operator view. This allows shop employees to:

• Retrieve customer cards.

• Assign points based on the current campaign.

• Notify customers when they’ve earned a reward.

Here’s a quick look at the operator’s workflow:

Campaign Builder

Shop owners can currently create stamp campaigns using this interface:

Here, they can:

• Name the campaign.

• Set the number of stamps required for a reward.

• Assign values to stamps for easy tracking.

• Define specific rewards for reaching milestones.

My Development Approach

At this early stage, the app feels rough around the edges: bugs, inconsistent layouts, and no styling. But that’s intentional. Here’s how I approach side projects like Fidely:

1. Build a Dirty Prototype:

   • Focus on selecting the tech stack and setting it up.

   • Implement basic features to validate the idea.

This phase helps me:

• See results quickly, keeping motivation high.

• Identify design challenges early.

• Understand which code modules are essential.

2. Refactor the Backend:

   • Review and clean up the codebase.

   • Organize routes and logic.

   • Write tests for stability.

3. Polish the Frontend:

   • Improve UX and layout consistency.

   • Refactor the frontend codebase for maintainability.

This incremental approach allows me to shift focus as needed, ensuring progress without getting overwhelmed. The key is identifying the minimal viable features to validate the idea while keeping the project flexible for future iterations.

What’s Next?

Now that the basic functionality is in place, I’ll focus on:

• Refactoring and structuring the backend.

• Adding test coverage for reliability.

• Organizing and improving the user interface.

I’ll share updates as I go, though my free time varies, so posts may be sporadic.

I’d love to hear your thoughts! Have you tackled similar side projects? What development methodologies do you use? Let’s chat in the comments or via email!

For some reason, working with Azure Identity is never straightforward for me. Don’t get me wrong—Microsoft Azure’s documentation can be excellent for many services. For example, setting up a basic Vision API project was a breeze, and I’d even say the .NET Core documentation is top-notch.

But Azure Identity? That’s a different story.

The Challenge

I’ve worked with Microsoft Entra (the new branding for Azure Identity services) numerous times, and setting up an App Registration is something I’ve come to expect in my day-to-day tasks. Today, however, the goal was to explore Azure B2C.

What Is Azure B2C?

In simple terms, Azure B2C is a Microsoft service that allows you to create a white-labeled user management platform.

Think of it as an offshoot of Entra ID (formerly Azure Active Directory), tailored specifically for managing users who are external to your organization. While Entra ID is designed to handle internal users—employees, contractors, etc.—Azure B2C is aimed at customers or other external users.

With Azure B2C, you can:

• Create sign-up and sign-in flows

• Customize the UI to match your brand

• Handle password reset flows automatically

• Integrate third-party identity providers like Google, Facebook, or Apple

If you’re familiar with Auth0 or Clerk, the concept is similar.

My Goal

Here were the requirements for my project:

1. Frontend: A React-based SPA (preferably with Vite).

2. Authentication: Trusted user management using Azure B2C.

3. Backend: Node.js or .NET Core API with bearer token authentication.

It sounded simple enough. But the moment I started looking at the documentation, I found myself buried under outdated repositories, scattered information, and broken links.

The Struggle

It’s a common scenario: a React SPA talking to a Node.js backend, secured with Azure B2C. Yet, the docs felt like a treasure hunt. I kept opening new tabs—at one point, I had over 20 Chrome tabs trying to piece everything together.

After hours of tinkering, I managed to get a basic example working:

• A React app (using Create React App, not Vite, unfortunately).

• A Node.js backend (Express-based).

Resources That Finally Worked

If you’re attempting the same setup, here are the key resources that worked for me:

Frontend:

• MSAL React B2C Sample

Backend:

• Node.js Web API with Azure B2C

Azure B2C Configuration:

• Create User Flows

Looking at these three links now, it feels so obvious. But finding and connecting them wasn’t easy.

Observations

Azure B2C and Microsoft Identity Platform are incredibly powerful, but navigating the documentation is challenging. Part of the issue seems to be the sheer breadth of features—combined with the need to support legacy systems like Active Directory.

In fairness, maintaining updated documentation while evolving services like Entra ID is no small feat.

What’s Next?

To streamline future projects, I’m building a small boilerplate using:

• React + Vite + Tailwind + Shadcn

• Azure B2C (or… maybe something else?)

• Node.js (Express + Passport)

Once it’s ready, I’ll update this article with the boilerplate.

The Plot Twist

Every good rabbit hole has a twist, and this one’s no different.

Just as I wrapped my head around Azure B2C, I stumbled upon Microsoft Entra External ID—which, they claim, is even better.

Apparently, Azure B2C will eventually be replaced by Entra External ID. So, if you’re starting fresh, it might be worth exploring this newer option.

The rabbit hole continues…

As I mentioned in a previous article, I’ve embarked on a new series called The 10-Minute Company. This idea has been on my to-do list for years. Now that it’s finally happening, I can’t decide whether to feel thrilled or terrified—probably a mix of both! Over the next few months, I’ll be dedicating significant effort to this project.

In short, the concept behind this series is simple: pick an idea (ideally a small one), develop it, and journal the process publicly. It aligns closely with the “build in public” philosophy but on a smaller, more approachable scale.

I’m fully aware this won’t be an easy journey. Creating software is already challenging, and doing it in public adds a whole new layer of difficulty—at least for me.

Why This Series?

This is a challenge, no doubt about it, especially because it requires consistency. However, I believe the potential benefits make it worthwhile.

Before diving into my goals and expectations, let me share some context about my life and why I think this series could be beneficial, both for me and for others in my field.

A Few Facts About Me

• I love learning about tech-related topics, often after my daily work hours.

• I rarely create tangible examples or demos for the challenges I explore.

• My interests span various domains beyond software, which often spark ideas for my projects.

• I enjoy designing software to solve specific problems.

• My free time is limited.

• I need a structured way to stay focused on my side projects.

Since I began working in the field in 2011, I noticed that many job opportunities in the Italian tech scene came from consultancy firms that typically handle diverse projects and tech stacks. This led me to focus on broadening my knowledge across multiple topics, as it provided a more straightforward path to staying relevant and valuable in such a dynamic environment.

As a result, I adopted the habit of learning outside work, focusing on topics unrelated to my current job. This strategy has shaped my professional journey.

The Pros and Cons of My Approach

Pros

• Expanding knowledge while staying updated on trends and concepts.

• Participating in developer meetups to learn from peers working on diverse projects.

• Practicing coding and mastering new technologies.

• Reducing job-related risks by broadening my skill set.

• Connecting dots between technologies, architectures, and methodologies.

• Discovering better solutions by knowing more options.

• Identifying recurring patterns and requirements across different projects and tech stacks, which helps prioritize learning.

Cons

• Time constraints: The day is still only 24 hours, and this approach has forced me to sacrifice other passions.

• Surface-level engagement: While I value adaptability, I sometimes feel that “use the right tool for the job” oversimplifies reality. Learning a new framework or language should be a necessity that arises after maximizing the tools already at your disposal.

• Misaligned perceptions: Some employers—especially those outside the tech core business—fail to recognize the value of this knowledge. This can lead to undervaluing professional expertise and bypassing important processes like documentation, skill development, and fostering innovation.

A Shift in Perspective

While my focus on continuous learning has served me well, it’s time to shift gears. I want to channel the skills I’ve built over the years into concrete projects. Instead of just expanding my knowledge, I’ll now prioritize applying it to bring my ideas to life.

This blog and the 10-Minute Company series are tools to keep me focused and accountable. Turning an idea into a working example requires a mix of skills—not just coding—which will push me to explore new perspectives.

I’m excited about the opportunity to grow, not only technically but also in terms of communication and networking.

I’d love to hear your thoughts! Any constructive feedback or support you can offer would make a huge difference in keeping this series alive and thriving.

Living in a small town on the Ligurian west coast has its perks—better quality of life, stunning views, and a slower pace—but networking opportunities for developers are rare. Most of the time, I rely on online communities to stay connected. That’s why, when I stumbled across this conference on Eventbrite, I didn’t think twice before grabbing a ticket (which, by the way, was free!).

The event was held in Milan, attracting a mix of local developers, students, and even attendees from abroad. It was wonderful to experience such an inclusive and welcoming atmosphere.

A Spotlight on AI

The conference heavily focused on artificial intelligence, which makes perfect sense given its prominence in tech over the past few years. Here are the talks I attended:

• Dealing with GenAI agents and rapid-fire messaging

• Da Documenti Statici a Risposte Immediate: La Rivoluzione AI nel Settore Industriale

• Dagli atomi ai template: Come sviluppare un design system senza perderci la testa!

• Gemini Functions Calls in Flutter

• SLSA on GCP: Let's Mitigate Supply Chain Threats

• Pretotyping in the Real World - Quickly Iterating Between Good and Bad Startup Ideas

• Generative AI Unveiled: From Fundamentals to Real-World Applications

• Bringing Fictional Characters to Life with Open Source LLMs

The conference was well-organized, and every talk I attended was engaging and informative. Let me share some highlights from my favorite sessions.

Highlights from the Talks

Dealing with GenAI Agents and Rapid-Fire Messaging

This talk by Danilo Trombino explored a fascinating aspect of AI chatbots that I hadn’t considered before: managing user interactions in real-time.

Different users communicate differently—some send fully detailed messages in one go, while others prefer a “chatty” style, breaking their thoughts into multiple short messages. Adding to the complexity, the time users take to type their messages can also vary significantly.

Danilo introduced a clever solution to handle these challenges using Redis. By assigning an expiring key to each user’s message, Redis tracks activity in real-time. If no new messages are sent within a specific time frame, the expiration triggers a request to the AI. This approach not only minimizes unnecessary calls to the AI service but also supports scalability by using Redis as a centralized system across multiple application instances.

The insights were practical, and Danilo’s clear explanations made it one of the standout talks for me.

Da Documenti Statici a Risposte Immediate: La Rivoluzione AI nel Settore Industriale

This was easily my favorite talk of the conference. While the topic—building a retrieval-augmented generation (RAG) system for internal documentation—might not sound glamorous, Christian and Andrea brought it to life by sharing real-world challenges they faced while implementing the system for a large client.

Their use of Haystack pipelines to process and integrate data with ChatGPT-based assistants was inspiring. It was a reminder of what I love most about my work: solving real problems. A system like this can genuinely improve a company’s efficiency, and the way they tackled these challenges was nothing short of impressive.

Gemini Functions Calls in Flutter

Though I’ve never worked with Flutter, Carlo Lucera made this talk highly accessible. He walked us through a practical example of using Gemini function calls in a Flutter app to retrieve real-time information about DevFests worldwide.

It was a well-structured session, and Carlo’s clarity in explaining the integration made me curious to try Flutter in the future.

Generative AI Unveiled: From Fundamentals to Real-World Applications

Yonatan Levin delivered a thought-provoking talk on optimizing search results in RAG systems using graph databases for embeddings. The ideas were advanced yet presented in a way that was easy to follow.

Unfortunately, the session ended before there was time for Q&A. I’d love to see a sequel to this talk in a future conference—it definitely left me wanting more!

Conclusion

Attending DevFest Milan 2024 was a refreshing experience. While the topics weren’t overly advanced, they struck the right balance for a community-driven event that aims to engage developers of all levels.

If you’re a developer looking for inspiration, networking, or just a reason to step away from your screen, I’d highly recommend keeping an eye out for the next DevFest near you. And if you’re lucky enough to live close to Milan, don’t miss it!

Here’s a list of links and resources I’ve come across that seem particularly valuable. Some are comprehensive collections, so it’ll take a bit of time to figure out which ones to follow deeply.

As a general rule, I don’t want to learn Rust by watching endless tutorials. Instead, I prefer a hands-on approach: reading interesting codebases and experimenting directly.

As a Node.js developer, I find Deno fascinating. It’s a project that offers so much to learn, from low-level programming concepts to building finished products.

Here’s a list of the best resources I discovered today:

Recommended Resources

• Comprehensive Rust
  A very well-written “book” by the Android Team at Google.

• Rust Resources List
  An “awesome” list with tons of useful links, especially the blog section.

• Rust 101
  Covers topics from basics to advanced. It’s concise—maybe too concise—but that could be a plus if you don’t want to spend too much time on tutorials.

• LearnRust
  A highly curated list for all expertise levels.

• Internals of Deno
  At the moment, this is the most interesting one for me. It dives into Deno’s architecture and internals.

I’ve decided to start with the last one since I’m really curious about how Deno works behind the scenes (at least at a high level). Over the past few days, I’ve particularly enjoyed learning about V8 isolates.

I’ll keep you updated if I discover more interesting resources!

When Rust and Deno Take Over Your Side Projects

Okay, the title might be a bit long and clunky, but it perfectly sums up my current situation. I’m enjoying learning about V8, Rust, and Deno, but it’s eating up way too much of my free time.

I’m sure I’m not alone in struggling to find the right balance between work, life, side projects, and study.

Last month, I started a new side project—simple enough for a solo developer (at least in its early stages) but interesting enough to eventually grow into a real product.

For me, one of the best parts of my job is creating software or products that can improve people’s daily lives.

I don’t think you need a groundbreaking idea to create a good product. Often, just listening to people or friends is enough to uncover small niches where you can build something useful.

This process is a great way to improve all the skills related to product development—and I’m not just talking about coding. It’s also about system design, writing good requirements, documentation, choosing the right tools, testing the market, gathering feedback, finding early adopters, and so much more.

In the next few days, I’ll write a blog post to introduce my new side project. My goal is to keep it alive, at least until I have a working proof of concept.

Introducing The 10-Minute Company

To stay focused on developing my project, I’ve decided to share my journey in a new series called “The 10-Minute Company”. I’ll document my side projects, starting from scratch and working toward a functional PoC.

Stay tuned for all the details! 🚀

I managed to review the fantastic article by Matouš Dzivjak, where he explains how to build a runtime using Rust V8.

The code from the article is a bit outdated and doesn’t run with the current version of Rust. I managed to get it working somehow, even though I don’t actually know Rust yet (so it’s either an easy task or I just got really lucky).

Below is the updated code with minor tweaks and some comments to help with understanding. All credits, of course, go to Matouš.

Quick Breakdown

This code demonstrates how to build a minimal JavaScript runtime using Rust and the V8 engine:

• Platform and V8 Initialization: The main.rs file initializes the V8 engine and platform, preparing it to execute JavaScript code.

• Runtime Setup: A global object (globalThis.workerHandler) is exposed in the runtime using JavaScript, enabling a Rust function to be callable from JavaScript.

• Script Compilation: The build_worker function compiles and evaluates the JavaScript code, combining the runtime script and a worker_script that defines a handler function.

• Global Context Binding: Rust functions, such as sayHello, are exposed to the V8 runtime by binding them to global object properties.

• Function Execution: The run_worker function calls the JavaScript handler function from Rust, passing parameters and printing the result (Hello World) to the console.

// runtime.js
globalThis.workerHandler = (x) => { 
  return handler(x);
}

// main.rs
use v8;

fn main() {
    // Platform and V8 initialization
    let platform = v8::Platform::new(0, false).make_shared();
    v8::V8::initialize_platform(platform);
    v8::V8::initialize();
    // `include_str!` is a Rust macro that loads a file and converts it into a Rust string
    let runtime = include_str!("runtime.js");

    let worker_script = r#"
    export function handler(y) {
        return sayHello(y);
    };
    "#;
    // The runtime.js file exposes the `handler` function as a global object
    let script = format!(
        r#"
        {runtime}
        {worker_script}
        "#
    );

    {
        // Create a V8 isolate with default parameters
        let mut isolate = v8::Isolate::new(v8::CreateParams::default());
        let global = setup_runtime(&mut isolate);
        let worker_scope = &mut v8::HandleScope::with_context(isolate.as_mut(), global.clone());
        let handler = build_worker(script.as_str(), worker_scope, &global);
        run_worker(handler, worker_scope, &global);
    }

    unsafe {
        v8::V8::dispose();
    }
    v8::V8::dispose_platform();
}
// Set up the global runtime context
fn setup_runtime(isolate: &mut v8::OwnedIsolate) -> v8::Global<v8::Context> {
    // Create a handle scope for all isolate handles    
    let isolate_scope = &mut v8::HandleScope::new(isolate);
    // ObjectTemplate is used to create objects inside the isolate
    let globals = v8::ObjectTemplate::new(isolate_scope);
    // The function name to bind to the Rust implementation
    let resource_name = v8::String::new(isolate_scope, "sayHello").unwrap().into();
    // Expose the function to the global object
    globals.set(
        resource_name,
        v8::FunctionTemplate::new(isolate_scope, say_hello_binding).into()
    );
    // Create a context for isolate execution
    let context_options = v8::ContextOptions {
        global_template: Some(globals),
        ..Default::default()
    };
    let global_context = v8::Context::new(isolate_scope, context_options);
    // Create and return the global context
    v8::Global::new(isolate_scope, global_context)
}
// Define the Rust binding for the sayHello function
pub fn say_hello_binding(
    scope: &mut v8::HandleScope,
    args: v8::FunctionCallbackArguments,
    mut retval: v8::ReturnValue,
) {
    let to = args.get(0).to_rust_string_lossy(scope);
    let hello = v8::String::new(scope, format!("Hello {}", to).as_str())
    .unwrap().into();
    retval.set(hello);
}
// Build the worker by compiling and instantiating the script
fn build_worker(
    script: &str,
    worker_scope: &mut v8::HandleScope,
    global: &v8::Global<v8::Context>,
) -> v8::Global<v8::Function> {
    let code = v8::String::new(worker_scope, script).unwrap();
    let resource_name = v8::String::new(worker_scope, "script.js").unwrap().into();
    // The source map is optional and used for debugging purposes
    let source_map_url: Option<v8::Local<'_, v8::Value>> = Some(v8::String::new(worker_scope, "placeholder").unwrap().into());
    let mut source = v8::script_compiler::Source::new(
        code,
        Some(&v8::ScriptOrigin::new(
            worker_scope,
            resource_name,
            0,
            0,
            false,
            i32::from(0),
            source_map_url,
            false,
            false,
            true,
            None
        )),
    );
    // Compile and evaluate the module
    let module = v8::script_compiler::compile_module(worker_scope, &mut source).unwrap();
    let _ = module.instantiate_module(worker_scope, |_, _, _, _| None);
    let _ = module.evaluate(worker_scope);
    // open a global scope associated to the worker_scope
    let global = global.open(worker_scope);
    // create and assign the handler to the global context
    let global = global.global(worker_scope);
    let handler_key = v8::String::new(worker_scope, "workerHandler").unwrap();
    let js_handler = global.get(worker_scope, handler_key.into()).unwrap();    
    let local_handler = v8::Local::<v8::Function>::try_from(js_handler).unwrap();
    v8::Global::new(worker_scope, local_handler)
}

// Run the worker and execute the `handler` function
pub fn run_worker(
    worker: v8::Global<v8::Function>,
    scope: &mut v8::HandleScope,
    global: &v8::Global<v8::Context>,
) {
    let handler = worker.open(scope);
    let global = global.open(scope);
    let global = global.global(scope);

    let param = v8::String::new(scope, "World").unwrap().into();
    // call the handler and get the result
    match handler.call(scope, global.into(), &[param]) {
        Some(response) => {
            let result = v8::Local::<v8::String>::try_from(response)
                .expect("Handler did not return a string");
            let result = result.to_string(scope).unwrap();
            println!("{}", result.to_rust_string_lossy(scope));
        }
        None => todo!(),
    };
}

I strongly encourage you to read Matouš Dzivjak’s excellent article for a deeper dive into the code and its concepts. This was just a summary—his detailed explanations are essential for understanding the technical nuances!

JavaScript Petition!

By the way, I had completely forgotten that Oracle owns the JavaScript trademark—something I already knew but slipped my mind. This week, Deno’s petition to cancel the trademark served as a reminder of this curious fact.

If you're interested in learning more, check out:

• https://javascript.tm/

• https://deno.com/blog/deno-v-oracle

Today’s rabbit hole started with Deno Deploy, which powers serverless functions for services like Supabase and Netlify.

Unlike traditional serverless environments such as AWS Lambda, which rely on micro-VMs (via Firecracker) or containers, Deno Deploy uses V8 Isolates. Intrigued, I decided to dive deeper into Rusty V8—the Rust bindings for V8—and learn more about how isolates work.

Here’s the repo: github.com/denoland/rusty_v8

I’m learning Rust alongside many other interests, and I’ve found that reading codebases I’m genuinely curious about is one of the best ways to pick up a new language, explore concepts, and understand technologies.

That said, this is a rough overview of my findings so far. There might be errors, but consider this post a starting point for your own rabbit hole! 😄

Exploring the Codebase

I started exploring the rusty_v8 codebase and was impressed by how closely it mirrors the original V8 implementation. This alignment makes it easier to find relevant documentation and examples online.

The code is well-organized, and I focused on how the bindings reference the underlying V8 code.

BackingStore: Memory Behind the Scenes

One interesting discovery was the ArrayBuffer, a contiguous block of memory used to store binary data. What caught my attention was the BackingStore—an abstraction that manages the raw memory backing the ArrayBuffer.

In simpler terms, the BackingStore represents the memory area (allocated by the operating system) where the data of an ArrayBuffer is stored. V8 handles this memory, including garbage collection, ensuring efficient memory management.

Inside the V8 Engine

Curious about how V8 works at a deeper level, I turned to its official documentation. Given the complexity of the project, I decided to approach it as a "black box" and started by reading how to embed V8 into an application.

A great resource was the hello world example, which demonstrates embedding V8 in a C++ application. Rusty V8 provides a similar example:

rustCopia codicelet platform = v8::new_default_platform(0, false).make_shared();
v8::V8::initialize_platform(platform);
v8::V8::initialize();

let isolate = &mut v8::Isolate::new(Default::default());

let scope = &mut v8::HandleScope::new(isolate);
let context = v8::Context::new(scope, Default::default());
let scope = &mut v8::ContextScope::new(scope, context);

let code = v8::String::new(scope, "'Hello' + ' World!'").unwrap();
println!("JavaScript code: {}", code.to_rust_string_lossy(scope));

let script = v8::Script::compile(scope, code, None).unwrap();
let result = script.run(scope).unwrap();
let result = result.to_string(scope).unwrap();
println!("Result: {}", result.to_rust_string_lossy(scope));

This example introduces four key concepts in V8:

• Platform: The environment where V8 runs. For example, a browser has a different platform implementation than Node.js.

• Isolate: A memory-isolated instance of the V8 engine, designed to run untrusted JavaScript code.

• Handles: References to JavaScript objects. A HandleScope acts as a container for these handles, allowing the garbage collector to efficiently free memory.

• Context: The execution context, including global objects and variables, for JavaScript code.

After initializing these components, the code is compiled and executed within the isolate.

One fascinating aspect of this process is the ability to expose custom runtime functionalities to the code running inside the isolate.

Expanding the Rabbit Hole

I also explored two articles that delve into building custom runtimes:

1. “Roll Your Own JavaScript Runtime” explains how to use deno_core to create a custom runtime.

2. “How Do Cloudflare Workers Work?” walks through creating a basic runtime with a single JavaScript function exposed to the isolate. Although the code is slightly outdated, it’s easy to adapt.

These resources sparked new questions about the relationship between libuv (which powers Node.js’s async functionality) and V8, and how this differs from Deno's architecture—definitely something for another rabbit hole!

Wrapping Up

I know this series might not be polished or easy to read, and I’m still learning as I go. But sharing my notes helps me stay organized and serves as a reference for my future self.

If you’re curious about these topics or have insights to share, let me know! Until the next rabbit hole, happy exploring! 🐇