alpsify

Case study

A·lfred: six years of SaaS in production

From 2020 to 2026, we designed, built and ran A·lfred, a business management application for freelancers and small businesses. Here is what we built, what we migrated, and why we stopped.

In figures

A product designed, built and run by one person.

in production, from 2020 to 2026
6 years
companies using it
~50
invoices
~3,000
quotes
~700

What we built

  • A decoupled API

    A Symfony and API Platform API on one side, a Vue.js application on the other. The interface only knows the contract of the API.

  • Asynchronous processing

    PDF generation, which is CPU-intensive, leaves the request and runs in the background.

  • Shared data, controlled access

    Several parties access the same data. Securing that access was a design topic in its own right.

  • A monorepo

    The code lives in a monorepo, organised to reuse rather than duplicate.

Two migrations in production

In six years, no notable incident. Two fundamental changes were carried out on the live product.

  • The move to FrankenPHP

    The application server was replaced by FrankenPHP during the life of the product.

  • From AWS to a VPS with Dokploy

    The infrastructure left AWS for a virtual private server, deployed with Dokploy.

Technical stack

Back
SymfonyAPI PlatformPHPRabbitMQMariaDBS3
Front
Vue.jsTypeScript
Infrastructure
DockerFrankenPHPDokployVPSCI/CD

Why we stopped

In France, since 1 September 2026, every company must be able to receive electronic invoices. The obligation to issue them extends to small and medium-sized businesses in September 2027.

For invoicing software, keeping up with this reform has a cost. It was too high for a product of this size, maintained by one person.

In this market, very large startups have far more resources and set the pace. We could not react as fast as they do.

We shut the service down on 31 January 2026, before the reform came into force.

The timeline of the reform on economie.gouv.fr (in French)

What this experience brings to our engagements

  • We lived for six years with our architecture choices, and with their consequences in operations.

  • We changed the application server and the infrastructure of a live product.

  • We know what compliance work costs, and how to recognise the moment when it is better to stop.

A product to keep alive, an architecture decision to make?

Let's talk Back to the portfolio