The Story of Alloggiati.pro: A Tool To Simplify Italian Bureaucracy

The software industry is obsessed with the scale problem. We’re told to build for a million users before we have one. To architect for planet-wide distribution when our first customer is down the street. It’s a venture-backed fever dream that results in bloated, over-engineered solutions to problems that barely exist.

We chose a different path. A simpler and more efficient path. We solved a real, expensive, soul-crushing problem for one person first.

The person was my friend, Lorenzo. The problem was the complexity of the Italian bureaucracy.

Lorenzo runs RomeLoft, a company that manages over 150 beautiful holiday homes and apartments across the city. He’s a master of hospitality, but the Italian state had turned him into a master of data entry. His nemesis: the Portale Alloggiati, the state police’s web portal. By law, he had to manually register every single guest from every single apartment, within 24 hours of their arrival.

For one or two properties, this is a headache. For 150? It’s a nightmare. It’s a full-time job. Lorenzo had an employee, maybe two on a busy week, whose entire days were spent in data-entry: chasing guests for photos of their passports, deciphering handwritten forms, and feeding the insatiable bureaucratic beast, one text field at a time. Every typo was a potential fine. Every delayed entry a risk.

The “modern” tech playbook would have you assemble a SWAT team to tackle this. Pitch VCs, hire a front-end team to build a React SPA, a back-end team for a constellation of Go microservices, and an AI/ML team to build a custom OCR pipeline. You’d burn a million dollars before the first user account was even created.

I didn’t write a business plan. I wrote a rails new command instead.

The goal was simple: build a blade sharp enough to cut through this specific knot of red tape for RomeLoft. One business, one problem. I reached for the most productive tool for the job: Ruby on Rails.

The first version was brutally pragmatic. I used Devise for authentication, and simple scaffolds to get the structure in place. I built a clean, fast interface for managing properties and adding guest registrations. It was already better than the government portal, but it wasn’t the solution. It was just a nicer UX for the same nightmare.

The first real breakthrough came from looking at how RomeLoft actually worked. Their bookings were already organized, living in calendars on Airbnb, Booking.com, and their own system. The data was there, just not in my app. The answer wasn’t a complex integration; it was a 25-year-old standard: iCal.

I wrote a simple solid_queue job. It polls the iCal feeds for all 150+ properties every hour. It finds new bookings, creates placeholder registrations, and populates the check-in and check-out dates. Just like that, 80% of the manual labor evaporated. The endless task of “creating a new record for the family in the Trastevere apartment” was gone. The system now knew who was coming and when.

But the final, most painful 20% remained: getting the personal data from the guest’s ID document into the form fields. This was the chokepoint. The land of blurry photos, strange foreign IDs, and endless copy-pasting.

This is where the AI hype machine usually goes off the rails. “You need a custom-trained model! An MLOps pipeline!”

We’ve been working on a gem called RubyLLM. It’s not some grand AI platform; it’s a simple, elegant Ruby interface for talking to Large Language Models. It lives right inside the monolith. No Python, no separate service, no operational circus. It’s just another tool in the Rails toolbox.

The workflow we built in the RegistrationsController is so simple it feels like cheating:

1. RomeLoft’s staff uploads a guest’s passport photo.
2. Active Storage handles the file beautifully, as always.
3. We use RubyLLM to send the image to a vision-capable LLM with a dead-simple, direct prompt:

   “You are a data extraction robot for Italian legal compliance. This is an image of a government ID. Extract these specific fields and return them as a valid JSON object: firstName, lastName, dateOfBirth, nationality, documentType, documentNumber, issuingAuthority. Do not hallucinate. Do not add commentary. Just the JSON.”

4. A moment later, we get back a clean JSON object. We parse it and pre-fill the form.

The employee’s job transforms. They’re no longer a data entry clerk. They’re a supervisor. They glance at the pre-filled form, confirm the data is correct, and hit “Submit”. A ten-minute, error-prone task becomes a five-second act of verification.

Lorenzo called me a week after they started using it. The employee who used to do this full-time was now handling guest communications and organizing local experiences. We hadn’t just saved him money on data entry; we’d unlocked a person’s potential. The ROI wasn’t in efficiency; it was in humanity.

That’s when the lightbulb went off.

The code sitting on that server wasn’t just a bespoke tool for RomeLoft. It was a product. Every B&B owner, every person renting out their spare room on a lake, every farm stay in Tuscany—they all had this exact same problem, just at a different scale.

We spent another few weeks adding multi-tenancy, integrating Stripe for subscriptions, and polishing the onboarding. The core logic, the blade itself, barely had to change. That’s the beauty of starting with a monolith. It’s a solid block of marble you can carve, not a pile of pebbles you have to glue together.

And so, Alloggiati.pro was born.

It wasn’t born from a pitch deck or a market analysis report. It was forged in the fire of a real, pressing, and expensive business problem. It’s a testament to the idea that you don’t need to build a spaceship to cross the street. You just need a solid vehicle.

For us, and for thousands of others, that vehicle remains Ruby on Rails. Find someone’s spreadsheet hell and go build them a happy place.