DEV Community: Palks Studio

Static websites don’t limit features. They redefine where complexity lives

Palks Studio — Fri, 17 Apr 2026 15:10:23 +0000

Static Websites Are Not Limited Websites

Static websites are often associated with simple projects: landing pages, fixed content, or minimal websites without advanced functionality.

This perception largely comes from earlier stages of the web, where “static” meant limited interaction and little or no logic.

Today, that association no longer reflects reality.

A static website does not define what a project can do, but how it is structured.

Static does not mean minimal

A static website can integrate many modern features:

secure download systems
payments handled through external services
interactive interfaces
local chatbots
client-side animations and dynamic behavior

The difference is not in visible capabilities, but in where complexity is placed.

Instead of concentrating logic in a permanent server or database, functionality is isolated into specific components only where it is needed.

Moving complexity instead of spreading it

In many projects, a full backend is introduced by default, even when actual needs remain limited.

This often increases complexity:

continuous server maintenance
additional dependencies
larger error surface
constant updates

A static approach keeps the website itself simple while delegating only necessary parts to specialized services or scripts.

Complexity is not removed.

It is moved to controlled areas.

Performance and structural clarity

Static websites also provide structural advantages.

Content is directly accessible, structure remains readable, and behavior stays predictable. The absence of server-side generation on each request reduces potential failure points and simplifies hosting.

This structural simplicity makes long-term maintenance and project handover easier.

The project remains understandable without requiring complex infrastructure.

Most real-world needs

In practice, many web projects do not require a fully dynamic system.

Presentation websites, documentation, digital products, educational content, or information platforms can operate efficiently on a well-designed static foundation.

Advanced functionality can be added selectively without turning the entire project into a complex application.

An engineering choice

Choosing a static architecture is not about limiting a project.

It is often about defining a clear scope, reducing maintenance, and achieving more predictable behavior.

Static websites do not replace dynamic applications where they are necessary.

But in many cases, they provide a more stable result with less complexity.

This is not a step backward.

It is a structural decision.

At Palks Studio, websites are built as static, dependency-free systems. Bases are available here: https://palks-studio.com/en/static-site

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Palks Studio — Static site + digital storefront

This repository contains the public website of Palks Studio, which combines:

a clean, tracking-free static HTML website
a lightweight server-side digital storefront
an autonomous PDF invoicing system
and secure token-based delivery of downloadable files

The system operates without a CMS, without a database, and without unnecessary SaaS dependencies,

relying solely on flat files (JSON/CSV) and minimalist PHP scripts.

The repository includes:

the public website (pages, styles, images, content)
payment and digital delivery components
as well as publicly accessible documentation with the aim of clarity, readability, and transparency

This repository is not a turnkey product, a framework, or a software library.

It serves as a reference artifact to understand the approach,

tools, and technical choices carried by Palks Studio.

About Palks Studio

Palks Studio designs technical tools, documentation structures,

and working environments intended to be:

readable
understandable
autonomous
maintainable over time

The emphasis is placed on:

functional simplicity
control of dependencies
transparency of technical choices
durability rather than trends

Project structure

/palks-studio-website/
│
├── fr/
│   ├── index.html                            → Accueil principal
│   ├── services.html                         → Page de présentation des services
│   ├── facturation-sans-saas.html            → Système de facturation autonome
│   ├── facturation-batch-facturx.html        → Service de facturation batch Factur-X
│   ├── facturation-sans-saas.html            → Service de facturation autonome sans SaaS (devis, factures, paiements)
│   ├── sans-abonnement.html                  → Approche sans abonnement
│   ├── systemes-techniques-autonomes.html    → Développement backend sur mesure
│   ├── studio.html                           → Présentation de Palks Studio
│   ├── approche.html                         → Approche et principes de travail
│   ├── ressources.html                       → Ressources techniques
│   ├── generateur-devis.html                 → Générateur de devis PDF gratuit
│   ├── static-site.html                      → Socle de site statique
│   ├── chatbot-flask.html                    → Chatbot Flask auto-hébergé
│   ├── framework-documentation.html          → Framework de documentation
│   ├── pack-environnement-vscode.html        → Pack environnement VS Code
│   ├── liens.html                            → Liens, ressources, produits
│   ├── mentions-legales.html                 → Mentions légales (FR) / Legal notice (EN)
│   ├── contact.html                          → Page de contact
│   ├── notes-techniques.html*                → Notes techniques
│   ├── cgv.html                              → Conditions générales de vente
│   ├── faq.html                              → Foire aux questions
│   └── politique-confidentialite.html        → Politique de confidentialité (FR) / Privacy policy (EN)    facturation-sans-saas
│
├── en/
│   ├── index.html                            → Home page
│   ├── services.html                         → Services page
│   ├── invoicing-without-saas.html           → Autonomous invoicing system
│   ├── batch-invoicing-facturx.html          → Factur-X batch billing service
│   ├── invoicing-without-saas.html           → Autonomous invoicing service without SaaS (quotes, invoices, payments)
│   ├── no-subscription.html                  → No-subscription approach
│   ├── autonomous-backend-systems.html       → Custom backend development
│   ├── studio.html                           → Studio overview
│   ├── approach.html                         → Method & principles
│   ├── ressources.html                       → Technical resources
│   ├── generateur-devis.html                 → Free PDF quote generator
│   ├── static-site.html                      → Professional static foundation
│   ├── flask-chatbot.html                    → Self-hosted Flask chatbot
│   ├── documentation-framework.html          → Documentation framework
│   ├── vscode-environment-pack.html          → VS Code environment pack
│   ├── links.html                            → Links & resources
│   ├── contact.html                          → Contact page
│   ├── technical-notes.html*                 → Technical notes
│   ├── faq.html                              → Frequently Asked Questions
│   └── terms.html                            → Terms and Conditions
│
├── assets/
│   ├── css/
│   │   └── style.css                         → Global stylesheet (FR) / Feuille de styles globale (EN)
│   └── img/                                  → Images et visuels (FR) / Images and visuals (EN)
│
├── robots.txt                                → Règles pour moteurs de recherche (FR) / Search engine directives (EN)
├── sitemap.xml                               → Plan du site pour indexation (FR) / Sitemap for indexing (EN)
│
├── LICENCE.md                                → Conditions d’utilisation et cadre légal (FR)
├── LICENSE.md                                → Terms of use and legal Framework (EN)
│
├── generate-contract.php                     → Backend génération PDF (FR) / PDF generation backend (EN)
├── upload-batch.php                          → Moteur de traitement du formulaire CSV (FR) / CSV upload form processing engine (EN)
│
├── downloads_tokens/
│   ├── downloads.log                         → Journal des téléchargements réels (FR) / Download activity log (EN)
│   ├── security.log                          → Journal des accès sécurisés aux fichiers (FR) / Secure download access log (EN)
│   └── tokens.json                           → Stockage des tokens de téléchargement (FR) / Download token storage (EN)
│
├── config/
│   └── download.php                          → Configuration centrale des téléchargements (FR) / Central download configuration (EN)
│
├── library/
│   ├── contact-contrat-fr.html               → Génération contrat + configuration client (FR)
│   ├── contact-contrat-en.html               → Contract + client configuration generation (EN)
│   ├── contrat-template-fr.html              → Template de contrat (FR)
│   ├── contrat-template-en.html              → Contract template (EN)
│   ├── upload-batch-fr.html                  → Formulaire d’envoi CSV client (FR)
│   ├── upload-batch-en.html                  → Client CSV upload form (EN)
│   ├── cancel.html                           → Page d’annulation de paiement (FR)/ Payment cancellation page (EN)
│   ├── success.html                          → Page de paiement validé (FR) / Payment success page (EN)
│   ├── counter.json                          → Compteur persistant de factures (FR) / Persistent invoice counter (EN)
│   ├── get_counter.php                       → Lecture sécurisée du compteur de factures (FR) / Secure invoice counter reader (EN)
│   ├── lib_*.php                             → Incrémentation atomique du numéro de facture (FR) / Secure invoice counter reader (EN)
│   ├── lib_*.php                             → Génération HTML des factures (FR) / Atomic invoice number increment (EN)
│   ├── lib_*.php                             → Envoi e-mails transactionnels (FR) / Transactional email delivery (EN)
│   ├── lib_*.php                             → Génération PDF via DomPDF (FR) / PDF generation via DomPDF (EN)
│   └── template_invoice.html                 → Template HTML de facture (FR) / Invoice HTML template (EN)
│
├── docs/
│   ├── VUE_D_ENSEMBLE.md                     → Vue d’ensemble du système (FR)
│   ├── OVERVIEW.md                           → System Overview (EN)
│   ├── PROJECT-OVERVIEW_FR.md                → Vue d’ensemble du projet (FR)
│   ├── PROJECT-OVERVIEW.md                   → Project Overview (EN)
│   ├── README_FR.md                          → Présentation générale (FR)
│   └── README.md                             → General Overview (EN)
│
├── products/
│   └── (store files)                         → Fichiers produits numériques (FR) / Digital product files (EN)
│
└── endpoint/
    ├── endpoint_a.php                        → Initialisation d’une session de paiement (FR) / Checkout session initialization (EN)
    ├── endpoint_b.php                        → Traitement des événements de paiement (FR) / Payment event handler (EN)
    ├── endpoint_c.php                        → Traitement post-paiement (FR) / Post-payment fulfillment handler (EN)
    └── endpoint_d.php                        → Point d’accès sécurisé aux fichiers (FR) / Secure file access endpoint (EN)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/palks-studio-website

https://palks-studio.com

Not All Complexity Is Bad — But Most of It Is

Palks Studio — Sat, 11 Apr 2026 17:12:47 +0000

Why complexity isn’t always the problem

Complexity is often seen as something to eliminate.

But not all complexity is bad.

Some of it is necessary.

Some of it shouldn’t exist.

The confusion

Most systems don’t fail because they are complex.

They fail because the wrong complexity accumulates.

The real issue

Over time, systems mix two things:

what is required
what just happened to be added

And the difference disappears.

What actually matters

Good systems don’t avoid complexity.

They make it visible and intentional.

A better way to think about it

Instead of asking:

“how do we simplify?”

Ask:

“which complexity belongs here?”

Full article → https://palks-studio.com/en/useful-vs-accidental-complexity

https://palks-studio.com

Factur-X EN16931: your invoice is probably not compliant (and you don't know it)

Palks Studio — Fri, 03 Apr 2026 17:03:31 +0000

Most invoicing solutions claim Factur-X compliance.
Few actually pass all three validation levels.

The three levels

Factur-X conformity requires passing all of these:

XSD validation — XML structure is syntactically correct
Schematron validation — EN16931 business rules are respected
PDF/A-3 validation — the PDF document is archivable with the XML correctly embedded

Where most solutions fail

PDF/A-3 is the real problem.

Common PHP PDF libraries — Dompdf, TCPDF — produce DeviceRGB without ICC OutputIntent.
The XML can be perfectly structured. The invoice is still rejected.

The combination that works

mPDF generates clean PDF/A-1b output
factur-x (Python) injects the EN16931 XML and converts to PDF/A-3

Result: XSD ✅ Schematron ✅ PDF/A-3 ✅

Full note → https://palks-studio.com/en/electronic-invoicing-compliance

https://palks-studio.com

Why real-time can unnecessarily complicate simple systems

Palks Studio — Wed, 25 Mar 2026 15:55:42 +0000

Real-time architectures are everywhere.

But not every system needs to be instant.

In many cases, real-time introduces more complexity than value.

The problem

Most systems today assume everything must update instantly.

But many business processes don’t need that.

The hidden cost

Real-time systems create multiple intermediate states.

Over time, this makes systems harder to understand and maintain.

A simpler approach

Some systems benefit from clear, step-based processing instead:

data preparation
validation
processing
output

Full article → https://palks-studio.com/en/real-time-unnecessary-complexity

https://palks-studio.com

Stop stacking tools. Build systems that run on their own.

Palks Studio — Sun, 22 Mar 2026 17:14:05 +0000

Entrepreneurs, freelancers, agencies,

A complete autonomous system running on your own hosting, without SaaS, subscriptions or external dependencies.

Are you still stacking tools to run your business?

Zapier.
Make.
Plugins.
Subscriptions.
Updates.
Dependencies.

It works…

until it breaks.

At Palks Studio, we do the opposite.

We remove dependencies.

We deploy systems directly on your infrastructure.

No SaaS.
No subscriptions.
No surprises.
No updates breaking everything.

Internal scripts.

Autonomous tools.

Systems that run on your own hosting.

For example:

quotes → signature → invoicing → payment → revenue tracking
https://palks-studio.com/en/invoicing-without-saas

CSV → batch processing → structured outputs → automated delivery
https://palks-studio.com/en/batch-invoicing-facturx

Invoicing.
Automation.
Internal tools.

One goal:

make it work.
simply.
over time.

Less tools.
Less complexity.
More control.

If your system depends on 5 external services,

it’s not a system.

It’s a fragile chain.

There’s another way to build.

Simpler.
More stable.
Fully controlled.

https://github.com/Palks-Studio/palks-studio

https://palks-studio.com

If your business depends on 5 tools, you don’t have a system

Palks Studio — Mon, 16 Mar 2026 14:11:23 +0000

Still managing quotes, invoices and payments across multiple tools?

I built a complete financial system that runs on your own domain.

Not a SaaS.
No subscription.
No critical dependencies.

The system runs on your own hosting.

Quotes → online signature → invoicing → payment confirmation → revenue journal.

Everything is semi-automated.

Quote / contract

Simple interface:

your fixed company details
client information
service lines
currency / VAT
your fixed banking details

The PDF is generated directly in the browser and sent to the client by email.

No data is sent to the server before validation.

Once the quote is sent:

a secure link is sent to the client
the client can view and sign the quote online
the quote is archived
you receive a confirmation email

The quote then becomes a signed contract.

Invoicing

The system includes a smart client lookup.

You only need to enter a single piece of information:

email
SIRET / SIREN
client name

and the system automatically retrieves:

the client’s details
their existing quotes (a list is suggested in the quote field)

The most recent quote is automatically suggested.

You simply select the correct quote from the list.

The system retrieves:

service lines
amounts
client information

If no quote exists, the invoice can be generated directly with a free service description.

Once validated, the system immediately generates:

the invoice
the stamped invoice (pre-generated)

The invoice is sent to the client and archived.

The stamped version is stored while waiting for payment.

Payment confirmation

The interface lists all pending invoices.

One click is enough to:

mark the invoice as paid
send the stamped invoice
add the entry to the revenue journal

The system also allows:

monthly invoice export (ZIP)
monthly revenue export (CSV)
annual revenue journal export

All data is stored in simple files.

No database.

This system is designed to be:

autonomous
installable on any PHP hosting
bilingual FR / EN
fully documented

The data stays with the client.

https://palks-studio.com/en/invoicing-without-saas

This is the type of systems I design at Palks Studio:

simple tools that automate complete business processes.

If you want to install this system on your own infrastructure:

contact@palks-studio.com

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Overview

Billing System is a suite of three interconnected billing tools accessible from a unified interface. It covers the full lifecycle of a service engagement: from quote generation to invoice settlement, including electronic signature and structured archiving.

The system is designed to be deployed directly on the client's server, on a standard Apache hosting environment with PHP 8.x and Composer. It requires no database, no third-party service, and no subscription.

Features

Client-side quote PDF generation (jsPDF)
Server-side invoice PDF generation (Dompdf)
Automatic pre-generation of the paid invoice at billing time
Electronic quote signing by the client (touch/mouse canvas)
Client auto-fill from archives (SIREN, SIRET, VAT, email, name)
Structured archiving by client and period
Secure sequential numbering (file lock)
Monthly export of invoices (ZIP)
Monthly export of revenue records (CSV)
Yearly export of the revenue journal (CSV)
Automatic email notifications at each stage (quote, invoice, settlement)
Cross-module navigation bar
Bilingual FR/EN interface with real-time language switch
Dark mode / light mode with persistence
No database
No SaaS dependency
Basic security: secure sessions, tokens, brute-force protection

Project Structure

billing-system-en/
│
├── billing-public/
│   │  └── assets/
│   │      ├── logo*              → User logo if provided
│   │      ├── signature.png      → User signature used on quotes and invoices
│   │      ├── favicon*           → Optional site favicon displayed in the browser tab
│   │      └── jspdf.umd.min.js   → jsPDF library used to generate PDFs in the browser
│   │
│   ├── generator-direct.php      → Quote generation endpoint
│   ├── engine-direct.php         → Invoice generation endpoint
│   ├── invoice-direct.php        → Direct invoice generation endpoint
│   │
│   ├── quote-generator.php       → Web interface for quote generation
│   ├── invoice-engine.php        → Web interface for direct invoice generation
│   ├── mark-paid.php             → Web interface used to mark an invoice as paid
│   ├── signer.php                → Web interface for quote viewing and signing
│   ├── export-invoices.php       → ZIP export of archived invoices
│   ├── export-recettes.php       → CSV export of the revenue journal
│   │
│   ├── lookup.php                → Client information lookup and auto-fill
│   ├── pdf-proxy.php             → Secure PDF access via token
│   ├── .htaccess                 → Apache security and configuration rules
│   └── quote-generator-save.php  → Generated quote saving and archiving
│
├── vendor/                       → Libraries used for PDF document generation
├── templates/                    → HTML templates used to render documents
│   └── invoice-template.php      → Document rendering template (PDF or preview)
│ 
├── config.php                    → Central configuration for issuer and bank details
├── mailer.php                    → Internal email sending script with attachments
├── engine.php                    → Main engine: document generation, calculations and archiving logic
├── LICENSE.md                    → Project license
│ 
├── contracts/                    → Archive of signed and unsigned quotes
├── counters/                     → Sequential numbering counters for quotes and invoices
├── logs/                         → System logs (optional)
├── data/
│   ├── invoices/                 → Archive of invoices awaiting payment
│   ├── invoices_state/           → Pre-generated paid invoices
│   ├── invoices_paid/            → Paid invoices archive
│   └── revenues/                 → Revenue CSV files
│
└── docs/
    ├── USER_GUIDE.md             → User guide
    ├── OVERVIEW.md               → Project overview and general system description
    └── README.md                 → Usage documentation (client version)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/billing-system

https://palks-studio.com

You don’t need a backend to generate quotes

Palks Studio — Sun, 08 Mar 2026 19:29:21 +0000

Creating a quote should be simple.

Yet most tools require:

account creation
email registration
server-side storage
sometimes even a subscription.

I wanted to try a different approach.

A quote generator that runs entirely in the browser.

No backend.

No API.

No database.

You can test it here:

https://palks-studio.com/fr/generateur-devis

The tool generates a professional PDF quote directly in the browser without sending any data to a server.

Everything runs in the browser

Everything happens client-side.

User fills the form

↓

JavaScript processes the data

↓

PDF is generated locally

↓

Browser downloads the file

No network request is required.

The only external dependency is the jsPDF library.

Generating PDFs directly in JavaScript

The generator relies on jsPDF to build the document directly in JavaScript.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jspdf/2.5.1/jspdf.umd.min.js"></script>

Once loaded, creating a PDF is straightforward.

const { jsPDF } = window.jspdf;

const doc = new jsPDF({
  unit: "mm",
  format: "a4"
});

From there, everything can be drawn directly into the document.

The form mirrors the final document

The form mirrors a real quote structure.

It contains:

issuer information
client information
quote metadata
service lines
totals
payment details

Example structure:

<div class="card">

  <div class="card-header">
    <div class="card-header-title">Your company</div>
  </div>

  <div class="card-body">
    <input name="issuer_name" required>
    <input name="issuer_email">
    <input name="issuer_phone">
  </div>

</div>

Each section of the form maps directly to a block inside the generated PDF.

Quotes need flexible line items

Quotes require flexible service lines.

Users can dynamically add or remove rows.

function addLine() {

  lineCount++;

  const row = document.createElement("div");
  row.className = "line-row";

  row.innerHTML = `
    <input name="lines[${lineCount}][desc]">
    <input name="lines[${lineCount}][qty]" type="number">
    <input name="lines[${lineCount}][price]" type="number">
  `;

  container.appendChild(row);

}

Each line contains:

description
quantity
unit price
VAT rate

Totals update instantly when values change.

All calculations happen instantly

All calculations are transparent and client-side.

function updateTotals() {

  let subtotal = 0;
  let vatTotal = 0;

  document.querySelectorAll(".line-row").forEach(row => {

    const qty   = parseFloat(row.querySelector('[name*="[qty]"]').value) || 0;
    const price = parseFloat(row.querySelector('[name*="[price]"]').value) || 0;
    const vat   = parseFloat(row.querySelector('[name*="[tva]"]').value) || 0;

    const lineHT = qty * price;

    subtotal += lineHT;
    vatTotal += lineHT * vat / 100;

  });

  const total = subtotal + vatTotal;

}

The UI immediately displays:

Subtotal
VAT
Total amount

before the PDF is generated.

Turning form data into a document

When the user confirms, the script builds the document.

const { jsPDF } = window.jspdf;

const doc = new jsPDF({
  unit: "mm",
  format: "a4"
});

Then the script draws the document:

header
issuer block
client block
service table
totals
notes
footer

Example:

doc.text("QUOTE", 18, 30);
doc.text(quoteNumber, 18, 38);

Every field comes directly from the form inputs.

Keeping the layout stable

PDF layout can break when text becomes longer than expected.

To prevent layout issues, the generator wraps text dynamically.

doc.splitTextToSize(text, maxWidth);

Each block calculates its own height before being drawn.

This prevents overlapping elements and keeps the layout stable.

Why a backend is unnecessary here

For this type of tool, a backend is often unnecessary.

Running everything in the browser provides several advantages.

Privacy.

No data is transmitted to any server.

Simplicity.

No authentication, no database, no API.

Lightweight hosting.

The entire generator is essentially a single HTML page.

It can run on:

static hosting
GitHub Pages
any simple web server

What this approach does not solve

This approach also has some limitations.

There is no:

quote history
client management
automated emailing
electronic signature workflow

But for generating quick quotes, it works extremely well.

What this tool is designed for

The goal was not to build a SaaS product.

The goal was to build a tool that is:

simple
frictionless
immediately usable

No login.

No tracking.

No data collection.

Just a form and a downloadable PDF.

Try it yourself

You can test it here:

https://palks-studio.com/fr/generateur-devis

It works on:

desktop
mobile
any modern browser

Sometimes simpler is better

Modern web tools often become unnecessarily complex.

For some use cases, a simple client-side application is more than enough.

A single HTML file with JavaScript can already provide:

a structured form
dynamic calculations
professional PDF generation

Sometimes simplicity is the best solution.

https://github.com/Palks-Studio/free-quote-generator

https://palks-studio.com

Generating Factur-X is easy. Making it valid is not.

Palks Studio — Wed, 04 Mar 2026 21:46:31 +0000

When I started working on B2B e-invoicing, I thought the technical part would be straightforward. Generate a PDF, embed an XML, follow a standard. On paper, it seemed linear.

In practice, it's something else entirely.

Here's what actually took time — not the concepts, but the details that break everything in production.

The Comfort profile is not declared — it is earned

EN16931 defines several profiles. The Comfort profile, the one that guarantees real interoperability with accounting systems, requires strict identifier completeness.

SIREN alone is not enough. SIRET alone is not enough. The combination of SIREN + SIRET + VAT number determines the profile declared in the XML. If one identifier is missing, the profile changes. And an incorrect profile means a technically invalid invoice — even if it looks perfectly fine visually.

I implemented conditional validation logic before generation. No silent correction, no approximation. Either the data is complete, or the invoice does not go out.

Multi-period invoicing is a state problem, not a calculation problem

Invoicing across multiple months in a single document seems simple. It is not.

The real issue: a period included in an issued invoice is permanently closed. It cannot be re-invoiced, partially modified, or cancelled. This is not a software constraint — it is a legal and accounting one.

I had to model an explicit state system per period and per client, using immutable archiving flags. No database — only locked, deterministic and traceable files.

Deduplication without a database

The classic question: how do you prevent issuing the same invoice twice if the process is restarted?

My answer: file-based locks. Each execution cycle checks for the existence of a lock file before generating anything. No race condition, no distributed transaction, no external dependency. One execution = one deterministic cycle. If the file exists, skip. Otherwise, generate and lock.

Simple, traceable, reliable.

The pipeline runs on cron — no background process, no service to keep alive

No persistent process running in the background, no service to maintain active, no SaaS dependency. The engine triggers, processes, archives and stops. Each execution is independent and reproducible.

This architectural choice has a direct consequence: if something goes wrong, there is nothing to restart, nothing to debug live. Logs are exhaustive, states are explicit, generated files are evidence.

What I take from this

Factur-X is not a PDF generation problem. It is a structured pipeline problem — controlled states and normalized data before production.
Tools that "generate Factur-X" are plentiful. Systems that guarantee end-to-end compliance, full traceability and zero implicit correction are far less common.

https://palks-studio.com/en/batch-invoicing-facturx

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

Overview Project

This repository presents a financial automation system designed to handle:

invoice generation (single & batch)
revenue tracking
payment reconciliation
client balances
accounting-ready exports

The system is deterministic, auditable, and explicit by design.

It operates:

without a database
without a CMS
without a SaaS dependency
without any exposed web interface

All executions run server-side, via CLI scripts and cron, with a strict separation of responsibilities.

This project is not a product, not a SaaS, and not a plug-and-play tool.

It documents a production-grade approach to financial automation.

Over time, the engine has been progressively extended

to cover real-world business cases,

without compromising its original design principles.

The billing system now supports:

multi-line invoices
multiple VAT rates per invoice
complex or extended service periods
multi-month billing scenarios
complex combinations while remaining EN16931 Comfort compliant

This functional expansion did not alter

the deterministic, auditable, and traceable nature of the system.

Electronic invoicing (Factur-X)

The system natively integrates Factur-X electronic invoicing (hybrid PDF with embedded XML),

in compliance with the European EN 16931 standard (Comfort profile):

generation of a semantically EN 16931-compliant Factur-X XML
XML validation (XSD and Schematron)
injection of the XML into the PDF
production of a single final document: the Factur-X hybrid PDF
direct integration into the run.php and run_batch.php pipelines
no parallel formats
no persistent XML storage

The system targets business compliance and e-invoicing interoperability (France / EU).

PDF/A compliance (document archiving) is not a functional objective of the project and is deliberately out of scope.

Factur-X is handled as a native component of the engine,

not as an external or optional module.

Project structure

automation_finance/
│
├── engine/
│   ├── build_facturx_xml.php         → Factur-X XML generation
│   ├── build_json.php                → Client onboarding JSON builder
│   ├── inject_facturx.py             → Factur-X XML injection into PDF
│   ├── run.php                       → Main automation engine (cron / CLI)
│   ├── run_batch.php                 → Batch automation engine for client invoicing
│   ├── billing_rules.php             → Billing rules and dynamic pricing logic
│   ├── alerts.php                    → Execution alerts and notifications handling
│   ├── import_csv.php                → Client CSV import and validation handler
│   ├── mailer.php                    → Email sender with invoice attachment
│   ├── mail_signature.php            → Palks Studio signature
│   ├── vendor/                       → PHP dependencies (e.g. DomPDF)
│   └── templates/                    → Invoices PDF template (bilingual FR / EN)
│
├── data/
│   ├── logs/                         → Execution logs per client
│   ├── onboarding/                   → JSON files generated by the client onboarding form
│   ├── onboarding_done/              → Processed onboarding JSON archived after build
│   ├── archive_batch/                → Archived client CSV
│   ├── batch_sent/                   → Zip sent
│   ├── usage/                        → Monthly client usage tracking
│   ├── revenues/                     → Cumulative revenues (internal accounting source)
│   ├── payments/                     → Payments received from the client (bank transfers, actually received amounts)
│   ├── balance/                      → Client accounting balance (invoiced vs paid, paid / unpaid status)
│   ├── invoices/                     → Invoices from the main activity (direct invoicing, internal use)
│   ├── invoices_batch/               → Invoices generated as part of the batch service (end clients)
│   ├── inbox_batch/                  → Client-provided CSV file (batch invoicing source)
│   ├── counters/                     → Annual invoice counter per client (direct invoicing)
│   └── counters_batch/               → Annual invoice counter per client (batch invoicing)
│
├── tools/
│   ├── update_balances.php           → Updates client balances based on revenues and payments
│   ├── find_client.php               → Client lookup utility
│   ├── build_client.php              → Client email index builder
│   ├── send_paid_receipts.php        → Automatic sending of paid client receipts
│   ├── purge_log.php                 → Cleanup Script
│   ├── client_project.php            → CLI script aggregating and exporting client data by identifier
│   ├── recettes_year.php             → Export actually received revenues for a full year
│   ├── recettes_month.php            → Export actually received revenues for a given month
│   └── revenues_csv.php              → Export revenues to a CSV file (accounting)
│
├── exports/
│   ├── recettes/                     → Monthly CSV exports generated on demand / Yearly CSV exports generated on demand
│   └── payments/                     → CSV generated from the received payments JSON files
│
├── downloads/                        → Monthly ZIP archives per client, containing automatically generated PDF invoices
├── clients/                          → Client configuration file (only file to edit per client)
├── batch_clients/                    → Batch configuration for an end client (monthly invoicing)
├── CONTRATS/                         → Legal documents related to the service
│
├── LICENCE.md                        → Conditions d’utilisation et cadre légal (FR)
├── LICENSE.md                        → Terms of use and legal Framework
│
└── docs/
    ├── README_FR.md                  → Documentation générale du système (FR)
    ├── README.md                     → General system documentation
    │
    ├── SERVICE_MEMO_FR.md            → Note interne de positionnement du service (FR)
    ├── SERVICE_MEMO.md               → Internal Service Positioning Memo
    │
    ├── README_DEPLOY_FR.md           → Guide d’installation et d’exploitation (FR)
    ├── README_DEPLOY_EN.md           → Installation and Production Guide
    │
    ├── VUE_DENSEMBLE_AUTOMATION.md   → Vue d’ensemble du système d’automatisation de facturation (FR)
    └── SYSTEM_OVERVIEW_AUTOMATION.md → Billing Automation System Overview

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/automation-finance

https://palks-studio.com

Your e-invoicing stack isn’t broken — your architecture is

Palks Studio — Fri, 27 Feb 2026 16:57:58 +0000

It is an architecture problem.

For months, e-invoicing has been discussed as if it were just another digital upgrade.

As if the topic could be reduced to:

switching software
converting PDFs
automating documents
plugging in a new tool
adding a technical component

This reading is misleading.

E-invoicing is not a format modernization.
It is a structural shift.

What many people assume

Today, many organizations approach e-invoicing as:

a software issue
a tooling issue
an automation issue
a conversion issue
a digitization issue

So they keep stacking:

PDFs
tools
connectors
platforms
automations
scripts
third-party services

…without ever addressing the core problem.

The real issue

An e-invoice is not a digital document.
It is a structured object.

It contains:

a human-readable PDF
a machine-readable XML structure
a European standard (EN16931)
strict semantic rules
machine interoperability

This is not just a file.
It is normalized data.

Where systems break

Today, many “solutions” still produce:

unstructured PDFs
non-exploitable conversions
heterogeneous formats
inconsistent flows
non-standardized data
manual reprocessing
dependencies on third-party tools
invisible operational debt

This is not digital transformation.
It is structural debt.

Automation is not the problem

Automation is not the enemy.
Tools are not the enemy.
Platforms are not the enemy.
AI is not the enemy.

The problem is the order of operations.

When you automate poorly structured data,
you don’t create performance —
you industrialize disorder.

The business reality

E-invoicing requires:

structured flows
normalized data
format consistency
processing traceability
pipeline readability
architectural thinking
system continuity
process stability

This is not a software project.
It is a data architecture project.

Tool vs system

A tool:

executes
produces
automates
transforms

A system:

structures
controls
validates
secures
guarantees
traces
normalizes
organizes

Tools do the work.
Systems make it reliable.

What e-invoicing actually changes

It transforms:

how data is produced
how flows are designed
how information circulates
how systems communicate
how companies interoperate

This is not an interface change.
It is a logic shift.

Conclusion

E-invoicing is not:

a tool
a software product
an API
a platform
an automation layer
a connector
an improved PDF format

It is an architecture.

Those who treat it as simple document conversion will build fragile systems.
Those who treat it as a structural problem will build durable ones.

At Palks Studio, our approach is simple

We don’t patch things after generation.
We structure before production.

Because compliance is not something you fix.
It is something you build.

Because reliability is not something you add.
It is something you design.

Because interoperability is not something you enable.
It is something you organize.

E-invoicing is not a digital transformation.
It is a structural transformation.

And in the end, systems will last.
Not hype.

https://palks-studio.com

Most SaaS tools create noise. I built my own assistant instead.

Palks Studio — Wed, 18 Feb 2026 18:14:45 +0000

Building a Local Personal Assistant Instead of Using SaaS Tools

Most developers use dozens of tools every day.

Notes apps, documentation tools, AI assistants, reminders, knowledge bases…
Everything lives somewhere else, often online, often fragmented.

At some point, I realized the problem wasn’t missing tools.
It was the lack of structure.

So I built my own personal assistant.

Not as an AI experiment.
Not as a product.
Just as a tool I could rely on every day.

The Problem

When working on multiple projects, information tends to mix:

project summaries
technical details
quick notes
meetings and reminders

Traditional assistants try to merge everything into a single conversation.
That sounds convenient, but in practice it creates noise.

The same keyword can mean different things depending on context.

I needed separation instead of intelligence.

The Idea: One Role Per Window

My assistant, called Jason, is based on a simple idea:

one window = one role.

Overview → project summaries
Technical → internal details and configuration
Memory → quick notes, meetings, reminders

Each conversation has its own history.
No cross-context interference.
No confusion.

The goal is predictability.

Local First

The assistant runs locally.

The knowledge base is just files.
Readable, editable, versionable.

No external platform.
No vendor lock-in.
No hidden behavior.

Internet is optional.

This keeps the system fast and under control.

Why Not Use Existing Tools?

Because most tools optimize for features.

I wanted something optimized for clarity.

no automatic restructuring
no unexpected behavior
no dependency on external services

Just a reliable assistant that reflects how I actually work.

The Result

Jason starts with my system and stays available in the background.

It can answer multiple conversations at the same time,
each with a different purpose.

It’s not impressive from a marketing perspective.
But it’s extremely useful in daily work.

And that’s the point.

Final Thought

Sometimes the best developer tools are not the most powerful ones.

They’re the ones that remove friction.

This is the kind of tooling I build for my own workflow at Palks Studio.

https://palks-studio.com

If your editor changes your code without asking, it’s broken

Palks Studio — Sat, 14 Feb 2026 15:39:40 +0000

For years, my VS Code environment kept getting more complex.

More extensions, more automation, more tools supposed to make development easier.

On paper, everything looked efficient. In practice, I spent more and more time fixing side effects.

Files reformatted themselves on save.

Indentation changed unexpectedly.

Two projects could look different simply because an extension behaved differently.

The tools were supposed to help.

Instead, they took control away.

The problem with automatic tooling

Automatic formatting is convenient — until it stops being predictable.

Some extensions rewrite code structure without real context.

Others apply different rules depending on language or local configuration.

Nothing is necessarily wrong, but the environment becomes unstable:

invisible changes appear in commits
code readability changes between projects
and it becomes harder to understand what actually changed

At some point, I realized I was spending more time supervising my editor than writing code.

What I actually wanted

I didn’t want more automation.

I wanted fewer surprises.

A simple and predictable environment:

no automatic changes without intent
consistent rendering across projects
formatting executed only when necessary

The goal was not to make the editor smarter,
but to make it more reliable.

Moving back to control instead of automation

I gradually removed everything that modified code automatically.

No format-on-save.

No extensions rewriting files in the background.

No hidden actions.

Instead, I adopted a simpler approach:

cleanup actions are manual
scripts run locally
every modification is intentional

The code is never modified unless I explicitly decide to do it.

At first this feels less modern, but it has an immediate benefit:
everything becomes predictable again.

What changed in practice

The biggest change wasn’t technical — it was mental.

Less friction.

Fewer broken files caused by unexpected formatting.

A more stable and readable codebase over time.

My editor stopped making decisions for me.
It became a tool again.

All my projects started behaving the same way, regardless of system or context.

Local backups changed how I work

Another important change was how I handled file safety.

Instead of relying on extensions or external tools, I added a simple local backup system: every time a file is saved, a timestamped copy is created locally.

It’s not complex, but it removes unnecessary stress.

A file can be modified, broken, or even deleted by mistake — a previous version still exists.

This kind of local safety changes the way you work.

You experiment more freely because losing a stable version of your code becomes much less likely.

Conclusion

Over time, this setup became reusable because I wanted the same stability across projects.

But the real change wasn’t the configuration itself.

It was the mindset behind it:

tools should never modify code without intent.

Eventually, this environment evolved into a reusable setup at Palks Studio, but the main benefit remains the same — clarity, control, and predictability.

https://palks-studio.com/en/vscode-environment-pack

If you're interested in how it works under the hood:

Here’s a technical breakdown of the system architecture.

VS Code – Environment Pack

A configured working environment for Visual Studio Code.

This pack provides a clear and consistent framework for formatting, cleanup, and normalization

of common file types (.py, .html, .css, .js, .json, .txt),

using VS Code settings and locally executed Python scripts.

The goal is not blind automation,

but a controlled set of tools

that lets you keep full control over code structure, readability, and consistency,

regardless of the operating system.

Why this environment exists

Most editors automatically reformat code when saving files.

While convenient, this can introduce unexpected changes,

inconsistent formatting, or conflicts between extensions.

This pack takes the opposite approach:

no automatic formatting
no hidden actions
manual tools executed only when needed

The goal is to keep code stable, readable and predictable,

while giving full control to the developer.

Pack Structure

vscode_environment_pack_v1.1/
│
├── .vscode/
│   ├── extensions.json                 → Local disabling of conflicting extensions (Prettier, RunOnSave)
│   ├── launch.json                     → Quick execution of the active Python script
│   ├── settings.json                   → Complete VS Code settings (indentation, LF, UTF-8, editor comfort)
│   ├── keybindings.json                → Shortcuts: Alt + M (minimap), Alt + R (re-indentation)
│   └── tasks.json                      → VS Code tasks (manually executable):
│                                           - Python Formatting + Margin Cleanup
│                                             (autopep8 + clean.py, active file)
│                                           - Margin Cleanup (clean.py — global / active file / custom selection)
│                                           - Margin Detection (space.py — read-only analysis)
│                                           - CRLF → LF Conversion (convert.py — global / active file / custom selection)
│
├── clean.py                            → General margin and whitespace cleanup
├── convert.py                          → Line ending normalization (CRLF → LF)
├── space.py                            → Margin analysis (read-only)
├── backup.py                           → Timestamped backup of the file on save (Ctrl + S)
│                                         via the Auto-Backup task
│ 
├── LICENSE.md                          → Terms of use and legal framework
│ 
└── docs/
    ├── TECHNICAL_README.md             → Technical documentation and internal structure
    ├── README_COMMERCIAL.md            → Project overview and public presentation
    ├── INSTALL.md                      → Installation and usage guide
    │
    └── examples/
        ├── before.py                   → Dirty / unstructured example files
        ├── after.py                    → Clean, formatted versions generated by the pack
        ├── convert_lf.mp4              → CRLF files automatically converted to LF
        ├── indent_clean.mp4            → Broken indentation/margins fixed instantly
        ├── indent_python.mp4           → Badly indented Python file auto-corrected
        ├── backup.mp4                  → Demonstrates automatic file backup on each save (Ctrl + S)
        │                                 and how to restore a deleted file from the backup folder
        └── space_clean.mp4             → Broken file analyzed and margins detected (read-only)

If you want to explore the technical implementation, you can find it here:

https://github.com/Palks-Studio/vs-code-environment-pack

https://palks-studio.com