DEV Community: Anthony Leignel

What Happens When Electronic Invoicing, Digital Identity and Payments Become Interconnected?

Anthony Leignel — Fri, 04 Sep 2026 15:12:27 +0000

Electronic invoicing is usually presented as an accounting and tax reform.

Structured invoices.

Automated reporting.

Standardized data.

New obligations for businesses.

But while working on electronic invoicing systems, I started looking beyond the invoice itself.

What happens to the data once transactions become structured?

What other European digital infrastructures can connect to it?

And how far do those connections actually go?

That question led to a much larger investigation.

Electronic Invoicing Is Only One Piece

Electronic invoicing does not exist in isolation.

At the same time, Europe is developing or deploying other digital infrastructures around products, identity and payments.

Taken separately, they look like different projects.

But their interfaces matter.

A transaction can identify a product.

A product can be connected to a Digital Product Passport.

A Digital Product Passport can contain structured information about that product, including environmental information.

Digital wallets can carry electronic credentials.

Payment infrastructures can interact with external systems and conditions.

The interesting question is therefore no longer whether each system exists independently.

It is whether they can communicate.

Following the Data Changes the Picture

The first chain examined in the investigation looks like this:

Electronic invoicing
   ↓
Transaction data
   ↓
Product identification
   ↓
Digital Product Passport
   ↓
Environmental data

None of these steps, considered individually, demonstrates the existence of a larger unified system.

But the connections themselves are important.

They show how structured transaction data can progressively be associated with increasingly detailed information about what was purchased.

Identity and Payments Form Another Chain

A second group of infrastructures develops around identity and payments.

Digital identity / wallet
   ↓
Electronic credential
   ↓
Payment
   ↓
External conditions

This is where the distinction between technical capability and actual use becomes essential.

The digital euro, for example, must not simply be described as "programmable money."

The European framework explicitly distinguishes programmable money from conditional payments.

A conditional payment can depend on predefined conditions without turning the currency itself into programmable money.

That distinction matters.

The Bridges Are No Longer Entirely Theoretical

This was one of the most interesting results of the investigation.

I started with a question:

Could these systems eventually be connected?

After examining official documentation, standards, technical architectures and experiments, the question changed.

Several bridges already exist, are standardized, planned or have been experimented with.

So the investigation moved from:

**HYPOTHESIS**

These systems might
one day be connected

to:

**OBSERVATION**

Several connections already exist,
are standardized,
planned
or have been experimented with

That does not mean everything is already connected.

It means the documentary boundary is further down the chain than it initially appears.

And This Is Where the Evidence Stops

There is a final chain that the investigation does not establish.

Environmental data
   ↓
Individual profile
   ↓
Imposed rule
   ↓
Economic or monetary restriction
   ↓
NOT ESTABLISHED

This distinction is fundamental.

Technical possibility is not the same thing as actual use.

Actual use is not the same thing as legal authorization.

And interoperability between infrastructures does not prove that they were designed for one common purpose.

The investigation therefore does not claim that an environmental score is currently being used to restrict an individual's payments.

It does not establish the existence of a centralized system controlling individual consumption.

And it does not attribute an undocumented intention to the institutions involved.

But the Opposite Conclusion Would Also Be Wrong

Saying that such a unified system exists today would go beyond the evidence.

But saying that the different infrastructures are completely isolated would also ignore documented technical connections.

The reality is more interesting.

Separate projects
   ↓
Structured data
   ↓
Standardized interfaces
   ↓
Increasing interoperability
   ↓
?

Electronic invoicing, product identification, environmental information, digital identity and payment systems remain separate projects.

But several of the technical bridges between them are real.

And as interoperability increases, studying each infrastructure independently becomes less useful.

The architecture has to be examined as a whole.

Why I Published the Investigation

I wanted the distinction between facts and deductions to remain visible.

So every major element of the investigation is classified according to its level of evidence.

ESTABLISHED

TECHNICALLY DEDUCIBLE

HYPOTHESIS

TO BE ESTABLISHED

The objective is not to prove a predetermined conclusion.

It is to determine exactly where the documentation takes us.

And where it stops.

The complete investigation is public, including the sources, individual chapters and methodology.

Read the Investigation

English version

Version française

GitHub repository — complete investigation and sources

The GitHub repository contains the complete investigation, the seven individual chapters and the source register.

Everything is public so the connections can be verified, challenged or explored further.

One Question Remains

Electronic invoicing is arriving now.

Digital Product Passports are developing.

European digital identity infrastructure is developing.

Payment infrastructure is evolving too.

Each project has its own purpose, legal framework and timeline.

But their ability to exchange structured data is increasing.

So perhaps the most interesting question is no longer:

What does electronic invoicing change?

It is:

What becomes technically possible when systems capable of identifying a transaction, a product, its characteristics, an identity and a payment become interoperable?

That is the question this investigation tries to document.

https://palks-studio.com

Turning Google Search Console Exports Into Actionable SEO Data

Anthony Leignel — Wed, 02 Sep 2026 00:44:12 +0000

Google Search Console provides the data. The challenge is knowing where to look.

Google Search Console already provides a significant amount of information about how a website performs in search.

Clicks
Impressions
CTR
Average positions
Queries
Pages
Countries
Devices

The data is there.

But exporting it often produces several CSV files containing hundreds or thousands of rows.

At that point, the problem is no longer accessing the data.

The problem is turning it into something that can be examined quickly.

Raw data is useful, but structure matters

A Search Console export can answer many questions.

Which queries generate impressions but few clicks?

Which keywords are already close to the first positions?

Which pages receive visibility?

How has performance changed during the selected period?

Which countries and devices account for the traffic?

All of this information exists in the export.

But examining separate CSV files manually makes relationships between those metrics harder to see.

A useful analysis layer does not need to invent new data.

It needs to organize the existing data in a way that makes patterns and potential priorities easier to identify.

Building an analysis layer instead of another SEO score

This was the idea behind SEO Lens.

SEO Lens is a small browser-based tool I built to transform a Google Search Console ZIP export into a structured visual report.

The objective was deliberately limited.

It does not attempt to assign an arbitrary SEO score such as:

SEO score: 87/100

A single number would hide most of the information that actually deserves investigation.

Instead, the report keeps the underlying Search Console metrics visible and organizes them into several analytical views:

performance overview
performance evolution
ranking distribution
opportunities
page performance
countries and devices
diagnostic
SEO priorities

The goal is not to decide whether a website is "good" or "bad".

The goal is to make the available data easier to inspect.

Keeping the architecture simple

The processing pipeline is intentionally straightforward:

IMPORT
  ↓
PARSER
  ↓
NORMALIZATION
  ↓
ANALYSIS
  ↓
INSIGHTS / PRIORITIZATION
  ↓
RENDERING

The user exports data from Google Search Console as a ZIP file.

The ZIP is opened directly in the browser.

The CSV files are identified, parsed and normalized before the different analyses are calculated.

The resulting report is then rendered in the same page.

There is no backend involved in the analysis.

Handling different Search Console exports

One interesting implementation detail is that Search Console exports are not necessarily identical depending on language.

For example, a French export can contain files such as:

Graphique.csv
Requêtes.csv
Pages.csv
Pays.csv
Appareils.csv
Filtres.csv

The analyzer therefore needs a normalization layer.

Instead of making the analysis logic depend directly on a specific filename or language, aliases are used to identify equivalent datasets.

Once the files and columns have been normalized, the rest of the analysis can operate on a consistent internal structure.

This keeps localization concerns separate from analytical logic.

Finding opportunities without inventing information

The analysis is deterministic.

SEO Lens does not use AI to interpret the export.

For example, the tool can identify situations such as queries receiving significant impressions but relatively few clicks, or queries already ranking within ranges where further investigation may be useful.

The important distinction is that these are signals derived from the provided Search Console data.

They are not claims about the entire website.

A query with a low CTR may deserve investigation, but the export alone cannot explain why its CTR is low.

A page losing clicks may deserve attention, but Search Console data alone cannot diagnose every possible technical or content-related cause.

The tool can identify where to look.

It should not pretend to know what the data cannot establish.

Privacy as an architectural property

Another requirement was that importing Search Console data should not require sending it somewhere else.

SEO Lens therefore performs the analysis locally in the browser.

There is:

no account
no Google API connection
no remote database
no AI service
no upload of the Search Console export to Palks Studio

The selected ZIP remains on the user's device while it is being processed.

This is not an additional privacy layer added around the application.

It is a consequence of the architecture itself.

If the server never needs the data, there is no reason to transmit it.

Why no direct Google Search Console API?

Connecting directly to the Search Console API could make importing data more convenient.

But it would also change the nature of the project.

OAuth, permissions, tokens, API configuration and server-side infrastructure would introduce additional dependencies and additional responsibilities.

For this use case, the existing Search Console export already contains the necessary input.

The workflow remains simple:

Google Search Console
        ↓
     ZIP export
        ↓
     SEO Lens
        ↓
   Visual report

It requires one manual step, but removes several architectural ones.

That trade-off is intentional.

What the tool does not do

Defining the limits of an analysis tool is as important as defining its features.

SEO Lens does not perform:

website crawling
complete technical SEO audits
backlink analysis
HTML content analysis
website modifications
direct Search Console synchronization

It only analyzes the information contained in the Search Console export provided by the user.

The resulting report should therefore be considered a structured reading of Search Console data, not a complete SEO audit.

Small tools can solve narrow problems well

Not every technical problem requires a platform, an account system or a large application architecture.

Sometimes the useful part is simply the transformation between an existing input and a more understandable output.

In this case:

raw Search Console data
        ↓
structured information
        ↓
points worth investigating

The implementation can remain relatively small because the scope remains explicit.

There is no attempt to replace Search Console.

There is no attempt to automate every SEO decision.

The tool sits between the export and the person analyzing it.

SEO Lens

SEO Lens is available for free and runs directly in the browser.

No account is required and the Search Console export is processed locally.

Try SEO Lens

The project also has a GitHub repository containing its technical presentation and documentation:

SEO Lens on GitHub

https://palks-studio.com

How Many Obsolete Dependencies Are You Using Without Knowing It? An Open Source Checker

Anthony Leignel — Sun, 16 Aug 2026 15:50:57 +0000

Security also starts with what we install

We install Python packages, VS Code extensions, tools that help us save time, test an idea, or simply improve our development environment.

Then we move on.

A few months or years later, some of those projects have been deprecated, archived, renamed, or are simply no longer maintained.

And they are still installed.

That is exactly the problem I wanted to address with Dependency Security Checker, an open source tool that locally scans installed Python packages and VS Code extensions, then compares them against documented alert databases.

The project is open source and available here:

Dependency Security Checker, GitHub

An alert before a vulnerability becomes your problem

The goal is not to claim that a dependency is vulnerable simply because it is no longer maintained.

That would be incorrect.

The goal is much simpler: to warn you.

If an installed package has officially been deprecated, you should be able to know about it.

If a VS Code extension you still use has been archived, you should be able to know that too.

And if a project has been renamed or its maintainers now recommend an alternative, that information should be easy to find.

A tool that does not make decisions for you

Dependency Security Checker does not uninstall anything, disable anything, update anything, or modify your projects.

It scans, detects, and displays the available information:

[!] package-name 1.0.0
    Status / Statut: DEPRECATED / DÉPRÉCIÉ

    Reason:
    ...

    Raison :
    ...

    Suggested replacement / Remplacement suggéré: ...

    Source: ...

From there, the decision is yours.

You can check the source, understand why the project was flagged, review how you use it, and decide whether it should be kept, replaced, updated, or removed.

This approach matters because a security-related tool should not create another problem by automatically modifying an environment it does not fully understand.

Deprecated does not mean vulnerable

This is probably the most important distinction behind the project.

An abandoned dependency is not automatically vulnerable.

Likewise, the absence of an alert does not mean a dependency is secure or free from vulnerabilities.

But when a project is no longer maintained, one question becomes legitimate:

Who will fix the next vulnerability if one is discovered?

This is where dependency maintenance becomes directly relevant to security.

Vulnerabilities do not only come from the code we write ourselves, they can also exist in the different components we add to our environments and projects.

With the number of packages, libraries, extensions, and development tools a modern environment can accumulate, it becomes increasingly difficult to remember exactly what is still installed and whether every component is still maintained.

Why is it open source?

Because when it comes to security, I prefer being able to see what a tool actually does.

Dependency Security Checker runs locally, its alert databases are visible, its sources can be checked, and its behavior can be inspected directly in the code.

It does not need to send your list of packages or VS Code extensions to a remote service to perform the scan.

Today, with software failures, compromised dependencies, abandoned projects, and supply-chain security issues becoming increasingly difficult to ignore, security should not be treated as something we think about only after a problem occurs.

Making the project open source also means something important:

You do not have to simply trust the tool.

You can inspect it.

You can verify its data.

You can contribute.

You can report incorrect information or submit another officially deprecated or abandoned dependency with a public source.

You do not need to be a developer to understand the result

I also wanted to avoid building something that only makes sense to someone who spends every day working in a terminal.

A developer can use it as a quick check of their environment, but a less technical user can also run the checker and understand the essential result.

No known alert found, nothing installed matched the current database.

An alert appears, something deserves your attention.

Then you get the status, the reason, a suggested replacement when one exists, and most importantly, the source.

No mysterious score.

No invented risk level.

No automatic decision.

The information remains understandable.

A database designed to evolve

The first version already contains hundreds of documented alerts across Python packages and VS Code extensions.

But the database is not intended to pretend it is exhaustive.

New projects will be abandoned.

Others will be archived.

Some libraries will be renamed or replaced.

The project can therefore evolve over time with one simple principle:

An alert should be backed by a source.

The objective is not to build the biggest list possible, but to maintain a database reliable enough for an alert to actually mean something when it appears.

A few seconds to look at what we are using

Software security can become extremely complex.

Here, the principle is intentionally simple.

You run the checker.

It looks at what is installed.

It compares it against its local database.

If it finds something, it tells you.

Then you investigate.

Because before deciding whether a dependency should still be part of your environment, you first need to know that it deserves your attention.

The project is available here:

Dependency Security Checker, GitHub

https://palks-studio.com

Comparing PDF and XML Data Locally with Python, Open Source

Anthony Leignel — Sat, 15 Aug 2026 20:40:01 +0000

A lightweight open source tool for detecting differences between two representations of the same document

A PDF and an XML file can represent the same document while containing different information.

A value may have been modified in one representation, a reference may be missing, a number may use a different format, or some information may simply exist in one file but not the other.

When both files become part of the same workflow, checking them manually can quickly become tedious.

This is why I built PDF / XML Comparator, a small open source Python tool designed to perform a first comparison locally.

View PDF / XML Comparator on GitHub

The problem

PDF and XML serve very different purposes.

The PDF provides a human-readable representation of a document, while XML provides structured data that can be processed by software.

Even when both representations originate from the same process, having two files does not automatically guarantee that every value represented in one can also be found in the other.

For example, you may encounter situations where:

a reference differs between the PDF and XML
an amount was changed in one representation
a value exists only in the XML
information visible in the PDF cannot be found in the XML
equivalent values use different formatting

Opening both files and searching for every value manually works for a single document, but it quickly becomes inefficient when repeated.

A deliberately simple approach

PDF / XML Comparator does not try to understand the business meaning of every field.

Instead, it performs a bidirectional comparison.

The process can be summarized as:

PDF ──► Text extraction ──► Search values in XML
                              │
                              ▼
                         Differences
                              ▲
                              │
XML ──► Data extraction ──► Search values in PDF

https://palks-studio.com

Compare Two PDF Files Locally with Python, Open Source

Anthony Leignel — Wed, 12 Aug 2026 19:41:42 +0000

A lightweight open-source tool for detecting textual differences between PDFs

Comparing two versions of a PDF should not necessarily require uploading documents to an online service.

This is especially true when working with internal documentation, reports, invoices, technical files, or documents that simply should not leave your machine.

I built PDF Comparator, a small open-source Python tool designed for exactly that purpose.

It compares the textual content of two PDF files locally and shows what changed between them.

No AI, no external API, no account, and no document upload.

How it works

The principle is intentionally simple:

PDF A → Text extraction
PDF B → Text extraction → Lightweight normalization → Comparison → Differences

The first PDF is considered the reference version, while the second is the new version.

The tool extracts text from all pages, performs lightweight normalization, then detects added and removed lines.

For example:

--- old.pdf
+++ new.pdf

-Address: 12 Example Street
+Address: 24 Example Street

-Total: €1,200
+Total: €1,350

Instead of manually checking two documents line by line, the differences are immediately visible in the terminal.

Running it

The project only requires Python 3 and pypdf.

Clone the repository and install the dependency:

git clone https://github.com/Palks-Studio/pdf-comparator
cd pdf-comparator

python -m pip install -r requirements.txt

Then compare two PDFs:

python pdf-compare.py old.pdf new.pdf

If no textual difference is found, the tool simply reports that no difference was detected.

Otherwise, the differences are displayed directly in the terminal.

Local by design

One of the main reasons I built this tool was to keep the workflow simple and local.

The PDFs are processed directly on your machine.

There is:

no file upload
no remote server
no external API
no AI processing

For documents containing internal or sensitive information, avoiding an unnecessary external transfer can be just as important as the comparison itself.

What it can be useful for

PDF Comparator can help when reviewing different versions of:

technical documentation
reports
invoices
specifications
administrative documents
generated PDFs
archived documents

It can also be useful during development when a system generates PDFs and you want a quick way to check whether textual content changed between two outputs.

What it does not do

PDF Comparator is deliberately focused on textual differences.

It does not compare:

images
fonts
colors
graphical layout
visual rendering

It also does not interpret the meaning of a change.

If a value changes from 1200 to 1350, the tool detects the difference, but it does not try to determine whether that change is correct.

The quality of the comparison also depends on the text layer available inside the PDF. A scanned document containing only images cannot be reliably compared without OCR.

Keeping this distinction explicit makes the tool predictable: it does one job and stays focused on it.

Open source

PDF Comparator is available as an open-source project under the MIT License.

The repository contains the Python script, requirements, documentation in English and French, and installation instructions.

Repository

View PDF Comparator on GitHub

Contributions, feedback, issues and improvements are welcome.

Sometimes a useful tool does not need a platform, an account, or another service in the middle.

Two files, one local script, and the differences.

https://palks-studio.com

What if we stopped explaining technology only through text?

Anthony Leignel — Sun, 09 Aug 2026 19:16:07 +0000

I created interactive experiences to show what really happens behind actions that seem simple

A cookie accepted with one click, two systems connected through an API, a task to automate, user authentication, or even a Factur-X invoice.

From the outside, many technical actions look simple.

And that's perfectly normal.

Users see the result, not necessarily everything that needs to happen behind the scenes for that result to work properly.

Of course, these mechanisms can be explained through articles, documentation, or diagrams, but not everyone wants to read several pages to understand a topic, some simply don't have the time, while others understand things better when they can visually follow what is happening.

That's why I started creating a series of interactive experiences.

Understand in just a few clicks

The principle is intentionally simple.

Each experience starts with an action or idea that seems straightforward, then gradually reveals what is actually happening behind the scenes.

Let's take automation.

A request can start with something as simple as:

"Could we automate this task?"

For the person making the request, it really is just one task.

But integrating it properly into a system may require analyzing the existing process, defining business rules, validating data, anticipating errors, securing execution, handling repeated runs, testing different scenarios, and making sure the system remains stable over time.

The experience isn't designed to turn visitors into developers, it simply makes this part of the work visible.

Showing what the interface doesn't show

That's the common thread throughout the collection.

An API can make it look like two systems are simply exchanging data, yet behind a single request there may be authentication, validation, processing, response codes, errors, timeouts, and retries.

A user login may look like nothing more than an email address and a password, while a properly built application needs to perform several checks before granting access.

A Factur-X invoice looks like a PDF, but it also contains structured XML data, and both representations need to tell the same story.

A cookie may seem insignificant, yet it can become the starting point of a much larger chain involving data collection and profiling.

The goal isn't to make these topics seem artificially complicated or alarming, but to show that between a visible action and its result, there is often an entire system the user never sees.

Another way to talk about technology

I like technical articles and documentation, and I publish those too, but I wanted to add a different format.

Something you can explore quickly, without requiring any particular technical background, where a few clicks are enough to understand an idea.

The experiences are therefore intentionally short, visual, and progressive.

Today, the collection covers several areas:

systems and architecture, with from-scratch development, APIs, and automation
security and data, with application authentication, cookies, and personal data
electronic invoicing, with Factur-X

More experiences will be added to the collection, because there are still plenty of technical mechanisms worth making visible this way.

Explore the interactive experiences

If you'd rather experience something than read a long explanation, or if you simply want to discover what happens behind some of the mechanisms we use every day, the full collection is available here:

Explore the interactive experiences

A few clicks are enough, then it's up to you to decide how far you want to follow the journey.

https://palks-studio.com

The Palks Studio Approach

Anthony Leignel — Tue, 04 Aug 2026 14:03:24 +0000

Why Palks Studio exists

Palks Studio was created around a simple observation: many software projects become more complex than they need to be.

New tools are added to solve problems introduced by previous tools. External services become permanent dependencies. Business data is scattered across multiple platforms. Over time, maintenance becomes more expensive than development itself.

I chose a different approach.

The goal is not to build software with the largest possible technology stack. The goal is to build systems that remain understandable, maintainable, and reliable years after they are deployed.

Every project starts with the same question:

How can this problem be solved with the fewest moving parts while remaining robust, secure, and easy to maintain?

Sometimes that means using an existing library. Sometimes it means writing a component from scratch. The decision is driven by long-term stability rather than short-term convenience.

This philosophy shapes every system developed at Palks Studio, from electronic invoicing and business automation to internal tools and backend infrastructures.

Simplicity is an engineering choice

Simple software is often perceived as limited.

In reality, simplicity is usually the result of deliberate engineering decisions.

Every additional service, dependency, framework, or external platform increases the number of components that must be deployed, monitored, updated, secured, and maintained over time.

Keeping an architecture simple is not about avoiding technology. It is about avoiding unnecessary complexity.

At Palks Studio, each component must have a clear purpose. If a feature can be implemented without introducing another layer of abstraction or another external dependency, that option is considered first.

The objective is not to build the smallest application possible. It is to build systems that remain understandable, predictable, and maintainable long after the initial development phase.

A simple architecture is easier to document, easier to audit, easier to debug, and easier to evolve.

Complexity should come from solving business problems, not from the technical stack itself.

Own the infrastructure

Software should not require handing over control of a company's data or infrastructure.

Whenever possible, the systems developed at Palks Studio are deployed directly on the client's own hosting, whether it is a shared server, a VPS, or dedicated infrastructure.

This approach gives the client full ownership of their environment. Their data remains under their control, backups stay on their infrastructure, and the system continues to operate independently of any specific software vendor.

It also simplifies long-term maintenance. There is no proprietary platform to migrate away from, no subscription required to keep the software running, and no dependency on a third-party service that could change its pricing, features, or availability.

The objective is not to avoid cloud services at all costs. It is to ensure that the client remains in control of the software they rely on every day.

Data belongs to the client

Collecting data is easy. Deciding not to collect it requires a different mindset.

At Palks Studio, systems are designed to keep only the information that is necessary for their intended purpose. If a piece of data has no operational value, it should not be stored.

The same principle applies to the public website. It operates without advertising trackers, analytics scripts, or unnecessary cookies. Visitors are not profiled, and browsing does not generate data that serves no purpose.

Keeping less data has practical benefits. It reduces storage requirements, simplifies compliance with privacy regulations, limits the impact of a potential data breach, and makes systems easier to understand and maintain.

Data should help users achieve their goals. It should not become a product in itself.

This principle guides every project developed at Palks Studio.

Security starts with architecture

Security is often associated with encryption, firewalls, or authentication.

These are important, but they are only part of the picture.

A system also becomes more secure by reducing what it exposes.

Fewer external services mean fewer communication channels.

Fewer dependencies mean fewer components that require security updates.

Fewer stored data mean less information that could be compromised.

Whenever possible, systems are designed with a clear separation between public and private components. Configuration files, business logic, and sensitive data remain outside the public web root, while only the elements intended to be accessed by users are exposed.

The objective is not to eliminate every risk. It is to reduce the attack surface before the software is even deployed.

Good security is not only something added to a system.

It is something built into its architecture from the beginning.

Business rules before automation

Automation is often presented as the solution.

In reality, it only amplifies the quality of the process it executes.

Automating a poorly designed workflow does not make it better. It simply allows the same mistakes to happen faster and more consistently.

Before introducing automation, the business rules must be clearly defined:

What should happen?
Under which conditions?
What data is required?
What makes a process valid?

Only when these questions have clear answers does automation become valuable.

This principle applies to every project developed at Palks Studio. Whether generating a Factur-X invoice, processing job applications, or orchestrating a business workflow, the objective is always the same: understand the business logic first, then automate its execution.

Automation should execute decisions.

It should not replace them.

Systems instead of tools

A tool solves a task.

A system supports a workflow.

This distinction shapes every project developed at Palks Studio.

A billing system is more than invoice generation. It also manages quotations, signatures, payments, structured archives, compliance rules, and future interoperability.

A recruitment system is more than a form. It evaluates candidates, applies business rules, ranks profiles, manages campaigns, and keeps the recruitment process consistent.

An automation system is more than a script. It validates data, executes predefined workflows, handles errors, produces traceable outputs, and remains predictable over time.

The objective is never to automate a single action in isolation.

It is to build systems that remain coherent as they grow.

Good software is not defined by the number of features it contains.

It is defined by the reliability of the workflow it supports.

A philosophy that guides every project

Technologies evolve.

Libraries are replaced.

Standards change.

Business requirements grow.

The principles behind a well-designed system should remain the same.

Build only what is necessary.

Keep the architecture understandable.

Reduce unnecessary dependencies.

Protect the client's data.

Design business rules before automating them.

Create systems that can still be understood, maintained, and trusted years after they are deployed.

Every project developed at Palks Studio follows these principles.

They are not constraints.

They are the foundation.

https://palks-studio.com

I Built a Local VS Code Environment That Puts Me Back in Control

Anthony Leignel — Wed, 01 Jul 2026 17:27:54 +0000

Why I Built It

For years, I kept adding new tools to my development environment because every extension, formatter, or utility promised to make development faster. At first it worked, but over time my workflow became harder to understand. Files were modified automatically, formatting changed from one project to another, and some actions happened in the background without me even noticing.

The problem wasn't Visual Studio Code, and it wasn't the extensions themselves. The real problem was that I had gradually stopped controlling my own development environment.

Instead of installing even more tools, I started removing them. I replaced hidden automation with explicit actions and built a lightweight local environment around a simple principle:

Nothing should modify my code unless I decide it.

Over time, this approach evolved into what is now my VS Code Environment Pack. Rather than trying to automate everything, it provides a collection of local tools that help me create projects, maintain codebases, generate documentation, keep timestamped backups, and automate repetitive tasks while keeping every action predictable and under my control.

Every Project Starts the Same Way

One of the first repetitive tasks in any project has nothing to do with writing code.

Creating folders.

Creating empty files.

Reproducing the same directory structure again and again.

It doesn't take long, but after dozens of projects it becomes unnecessary work.

Instead of creating everything manually, I describe the project structure once in a simple structure.txt file. Running a single task generates the complete hierarchy, including every folder and file exactly where it belongs.

my_project

    README.md

    app

        app.py

    static

        css

            style.css

The goal isn't to generate code.

It's to start every project from a clean, consistent structure, so I can focus on solving the actual problem instead of rebuilding the same foundation every time.

Documentation Should Never Be Manual

Understanding a project often starts with a simple question:

How is it organized?

When a codebase grows, answering that question manually becomes surprisingly time-consuming. Taking screenshots, writing folder structures, or listing files by hand quickly becomes outdated.

That's why I built tree.py.

With a single task, it scans the entire project and generates a PROJECT_TREE.txt file representing the complete directory structure.

my_project/
├── app
│   ├── app.py
│   └── controllers
├── static
│   ├── css
│   └── js
├── README.md
└── requirements.txt

I use it to document projects, share their architecture, review existing codebases, and quickly understand how a project is organized.

Like every other tool in this environment, it performs one task, does it locally, and produces a result that is easy to read, reuse, and version.

Every Change Is Intentional

One of the principles behind this environment is that no script should modify more files than necessary.

That's why most maintenance tools can run in three different modes.

Sometimes I want to clean an entire project before committing it.

Sometimes I only want to work on the file I'm editing.

And sometimes I need to target a small selection of files without touching anything else.

Instead of forcing a single workflow, the environment adapts to the situation.

The same approach applies to cleaning whitespace, converting line endings, and other maintenance tasks. Every operation can be executed on the whole project, the active file, or a custom selection.

Nothing runs automatically in the background.

Nothing changes unless I ask for it.

That level of control makes maintenance safer, especially on large projects where a single unintended modification can affect hundreds of files.

Every Save Creates a Safety Net

Making changes is part of development.

Deleting the wrong block, trying a different implementation, or restructuring a file happens every day. Most of the time, version control is enough. Sometimes, it isn't.

I wanted something much simpler.

Every time I save a file, a timestamped copy is created automatically inside a local backup directory. Nothing is uploaded, nothing is synchronized, and nothing depends on an external extension or service.

If I realize a mistake a few minutes later, I don't need to search through Git commits or recover a deleted file. The previous version is already there.

More importantly, this changes the way I work.

I can experiment more freely because I know every saved version still exists. Refactoring becomes less stressful, trying a new approach becomes easier, and recovering from a mistake takes seconds instead of minutes.

The backup system isn't just about protecting files.

It's about giving me the confidence to change them.

Small Tools, One Responsibility

One design decision guided the entire project: every tool should solve one problem, and solve it well.

Instead of building one large application responsible for formatting, backups, project generation, documentation, and file maintenance, I chose to keep every feature independent.

create.py creates projects.

tree.py documents them.

clean.py removes unnecessary whitespace.

space.py reports formatting issues without modifying anything.

convert.py normalizes line endings.

backup.py keeps timestamped copies of every saved file.

Each tool can evolve independently, remain easy to understand, and be reused in other projects without bringing along features that aren't needed.

The result isn't just easier to maintain.

It's easier to trust.

When a tool has one responsibility, you always know why you're running it and exactly what it will do.

Conclusion

This project didn't start as a VS Code pack.

It started with a simple question:

How can I build an environment that stays predictable, even as my projects become larger and more complex?

Over time, the answer became a collection of small local tools designed to solve everyday problems without introducing unnecessary complexity.

Creating projects.

Documenting architectures.

Maintaining codebases.

Keeping local backups.

Cleaning and formatting files.

Every tool has a single responsibility, every action is explicit, and every modification remains under my control.

Today, this environment is part of every project I build.

Not because it automates everything, but because it automates the right things while letting me decide when and how they happen.

For me, that's what a good development environment should do.

It shouldn't write code for the developer.

It should help the developer write better code with confidence.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I Built a Local Data Collection System in Python

Anthony Leignel — Thu, 04 Jun 2026 17:13:36 +0000

Why I Built It

Most data collection and lead generation tools are delivered as SaaS products.

You create an account, subscribe, send your data to a third-party platform and keep paying every month to continue using the tool.

I wanted a different approach.

I built a fully local data collection system that runs on the user's machine, without subscriptions, without paid APIs and without relying on external platforms.

The goal was simple:

Create searches
Collect data from multiple sources
Clean and validate the results
Export usable data
Keep everything under the user's control

What the System Does

The application allows users to create and manage searches from a web interface.

For each search, users can define:

A search name
A keyword
A city
A country
The search engines to use

The system currently supports:

DuckDuckGo
Bing
Qwant

Once a search is executed, the collection engine starts gathering information from the selected sources.

Data Processing Pipeline

The system follows a structured workflow.

Load Configuration
↓
Initialize Environment
↓
Load Searches
↓
Run Collectors
↓
Clean Data
↓
Normalize Data
↓
Validate Records
↓
Remove Duplicates
↓
Generate Exports
↓
Save Results

Each component has a single responsibility.

Collectors collect data.

Processors clean and validate it.

Exporters generate output files.

The main engine orchestrates the workflow.

Extracting Business Information

The system doesn't stop at search engine results.

When a website is discovered, the application can visit the site and extract useful information such as:

Website URL
Email addresses
Phone numbers
Company name
Location information

The collected data is then normalized and validated before being added to the final dataset.

Managing Contacted Leads

One feature I wanted from the beginning was lead tracking.

Users can mark prospects as contacted directly from the interface.

The information is stored locally and remains available after closing the application.

This makes it easy to distinguish:

New prospects
Already contacted prospects

without relying on an external CRM.

Exporting Data

Once processing is complete, results can be exported as:

CSV
JSON

The exported files are ready to be imported into other systems or used for further analysis.

Local First

One of the main design goals was independence.

The system runs locally.

There is:

No SaaS
No subscription
No third-party account
No paid API dependency

The user owns the software and the collected data.

Technical Stack

The project is built with:

Python
Flask
Playwright
BeautifulSoup
Requests

The interface is served locally through Flask and can be accessed from a browser.

Final Thoughts

This project started as a simple data collection tool and gradually evolved into a complete workflow capable of collecting, processing and exporting structured business data.

Building it locally introduced some interesting challenges around browser automation, data normalization, validation and architecture design.

The result is a modular system that can be extended with new collectors, processors and export formats without changing the overall architecture.

For me, the most important aspect remains simple:

The software belongs to the user and the data never has to leave the machine.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I Built a Full Recruitment System in PHP: No Database, No SaaS, No Subscription

Anthony Leignel — Fri, 15 May 2026 19:53:59 +0000

Automatic candidate scoring, recruiter dashboard, multi-campaign management. Deployed on any standard Apache hosting.

After building a complete invoicing system the same way, I applied the same philosophy to recruitment: no SaaS dependency, no monthly subscription, no data leaving the client's server.

The result is CANDIDATE_SYSTEM, a self-hosted recruitment engine that automatically scores applicants against a job profile, ranks them by matching score, and lets the recruiter focus on the top profiles instead of reading through dozens of CVs.

The Problem With Existing Tools

Most recruitment platforms follow the same model: you pay monthly, your data sits on their servers, and the day you stop paying, everything disappears.

For small companies, DSIs, and independent recruiters, this makes no sense. They don't need a 300€/month SaaS. They need a simple, reliable tool that works on their own hosting.

How It Works

The system is split into two parts:

Public: the application form (/candidat/)
Private: configuration, scoring engine, candidate data (outside the webroot)

When a candidate submits the form, the scoring engine calculates a final score based on three nested levels:

contribution = scores[answer] × (weight / 100) × (global_weight / 100)

Level 1: global_weight, how much a section counts in the final score.

Level 2: weight, how much a question counts within its section.

Level 3: scores, the raw value assigned to each possible answer (0 to 100).

Every candidate gets a score on submission. The dashboard displays them ranked from highest to lowest.

The Scoring Engine

The scoring logic lives in a single $coring class. It reads the campaign configuration files, questions with their weights and scores, and the job profile, then runs the calculation across all sections.

public function calculate(array $reponses): array
{
    foreach ($this->questions as $question) {
        $score_brut   = $this->getScoreBrut($question, $reponses[$question['id']]);
        $contribution = $score_brut * ($question['weight'] / 100);
        $detail[$question['section']]['score_section'] += $contribution;
    }

    foreach ($detail as $section_id => &$section) {
        $section['contribution'] = $section['score_section'] * ($section['global_weight'] / 100);
        $score_final += $section['contribution'];
    }

    // Apply penalties
    foreach ($this->profil['malus'] ?? [] as $question_id => $penalties) {
        if (isset($penalties[$reponses[$question_id]])) {
            $malus += $penalties[$reponses[$question_id]];
        }
    }

    return ['score_final' => round(max(0, $score_final + $malus), 1), ...];
}

The tech stack question (checkbox type) is scored differently, each selected technology is matched against the scores defined in the question itself. No hardcoded list, fully configurable from the admin interface.

Multi-Campaign Architecture

Each campaign is completely independent: its own questions, its own job profile, its own candidate data.

campaigns/
└── [slug]/
    ├── config/          → questions, scores, job profile
    └── data/            → applications, uploads, lock file

Creating a new campaign from the dashboard copies the templates, generates the folder structure, and redirects immediately to the new campaign. One click, ready to use.

A campaign.lock file controls whether the form is open or closed. The recruiter can close a campaign (which purges all candidate data and sends a closure email to every applicant), then reopen it later from the dashboard.

The Admin Interface

The recruiter configures everything from the admin panel, no file editing required:

Job profile: position title, mission type, location, salary range
Questions: edit labels, answers, scores, section weights; add or delete questions
Section weights: real-time total indicator (must reach 100%)
Penalty rules: attach negative scores to specific answers on specific questions
Settings: sender name, email, site URL, dashboard password

The section weight total updates in real time as you type. If it doesn't add up to 100%, the indicator turns red.

No Database: Just JSON Files

Every application is stored as a flat JSON file:

{
    "id": "20260514_143000_abc123",
    "date": "2026-05-14 14:30:00",
    "score_final": 74.5,
    "score_label": "Good fit",
    "score_detail": {
        "terrain": { "score_section": 68.0, "contribution": 40.8 },
        "classic": { "score_section": 75.0, "contribution": 15.0 }
    },
    "reponses": { ... },
    "trigger_fields": { ... }
}

No ORM, no migrations, no connection pooling. The dashboard loads all JSON files from the applications/ folder, sorts them by score_final, and renders the list.

It's fast enough for the volumes this tool is designed for, typically 20 to 200 applications per campaign.

Security

A few things worth noting:

CSRF token on the application form, generated per session and validated on submission
Strict public/private separation, no configuration file is accessible via the web
Duplicate prevention, one email per campaign, checked on every submission
Upload validation, PDF only, 5 MB max, with extension and MIME type verified
HTTP security headers on every page (X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
Session required for the dashboard, exports, application viewing, and campaign closure

Conditional Form Fields

Some questions trigger additional fields depending on the answer. For example, answering "Yes" to "Do you have a portfolio?" reveals a required URL field. Answering "Yes" to "Any certifications?" triggers a PDF upload.

The trigger configuration lives in the questions config file:

{
    "id": "portfolio",
    "trigger": {
        "value": "Oui",
        "field_id": "portfolio_url",
        "field_type": "url",
        "field_label": "Portfolio URL",
        "required": true
    }
}

On the frontend, a small JS handler watches radio inputs and toggles the conditional field visibility. On the backend, handler.php only validates the conditional field if the triggering answer was given.

What Gets Delivered

When deployed for a client:

Full system installed on their hosting
First campaign configured with their job profile
Admin interface ready to use
Technical documentation + user guide
Color customization included

No recurring cost. No dependency on external infrastructure. One flat fee.

Stack

PHP 8.x: no framework, no Composer
Apache + .htaccess: URL rewriting, security headers, directory protection
Vanilla JS: form validation, clipboard API, accordion UI
JSON flat files, zero database

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

I built a fully automated Factur-X EN16931 batch pipeline in PHP: no SaaS, no agent, just cron and strict business logic

Anthony Leignel — Wed, 13 May 2026 14:04:09 +0000

How a Monthly Cron Cycle Replaces an Entire Invoicing Platform

The goal wasn't to automate individual tasks.

It was to automate an entire monthly invoicing cycle.

From CSV import to Factur-X generation, payment tracking, secure delivery, and revenue reporting, every step runs through the same deterministic pipeline.

No SaaS.

No database.

No background service.

Just PHP, cron, and business rules.

Why I built it this way

The requirement was simple on paper: take client data every month, generate Factur-X EN16931 compliant invoices, track payments, and deliver everything securely.

The constraint was harder: no SaaS dependency, no shared infrastructure, no implicit processing. Every step had to be explicit, traceable, and stoppable.

That constraint shaped every architectural decision.

The monthly cycle

Onboarding

Before the first invoice is ever generated, every client is initialized automatically from a form submission. A unique identifier is generated, configuration files are created, archiving folders are structured, and payment tracking is prepared. No manual intervention required. The system is ready to process.

D1 to D7: CSV deposit and batch generation

Each client deposits their billing data via a secured form. The system validates structure and formats strictly, with no implicit tolerance and no silent correction. A malformed field stops the entire client batch, isolates it, and triggers an automatic notification for correction before reprocessing.

If valid, batch generation runs daily via cron. Invoice composition is driven entirely by business rules, including rates, VAT zones, service periods, and multi-line and multi-month billing. The output is a Factur-X EN16931-compliant PDF/A-3 document with embedded XML, making it both human-readable and machine-readable.

D8: B2B invoice and automatic pricing tier

On day 8, the system detects the volume of invoices generated during the period and derives the applicable pricing tier automatically. The monthly B2B invoice is then generated and sent by email with the PDF attached. No manual input. The cron runs, the logic decides.

D13 to D14: The only manual step

This is the single human touchpoint in the entire cycle: recording received bank transfers. Everything else is automated. This separation is intentional, because payment validation is a business decision, not a technical one.

D15: Balance recalculation and payment control

Two operations run on day 15. First, client balances are recalculated from recorded payments. Unpaid clients are automatically deactivated, blocking any further send operations until the situation is resolved. Second, paid receipts are sent to clients with confirmed payment status via cron.

D16: Secured delivery

The monthly ZIP is sent once. A deduplication guard ensures nothing can be sent twice, regardless of cron retries or manual triggers. Delivery uses a temporary token, making the file accessible only through a time-limited secured link. The archive is retained independently.

What makes it deterministic

Every processing decision is explicit. There is no magic, no silent fallback, no implicit correction.

If a CSV is invalid the client batch stops.

If a client is unpaid sends are blocked.

If a ZIP was already sent the guard refuses the duplicate.

Every operation is timestamped in technical logs. Client state is controlled via explicit flags. The revenue journal is updated on every confirmed payment.

The system is designed to be readable by anyone who picks it up. Not clever. Predictable.

Stack

PHP 8: backend logic and cron execution
mPDF: PDF generation
factur-x (Python, Akretion): Factur-X XML injection and PDF/A-3 conversion
Flat-file storage: contracts, invoices, counters, logs, revenues
No database. No SaaS. No external API dependency

What I Learned

Building this pipeline wasn't about automating invoice generation.

It was about designing a system where every execution produces the same predictable result.

Once the business rules were defined, cron simply became the engine that executes them.

Automation wasn't the goal.

Reliability was.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

How I Integrated Factur-X EN16931 into an Existing PHP Billing System

Anthony Leignel — Mon, 11 May 2026 10:17:35 +0000

Integrating Factur-X into an Existing PHP Application

As the French e-invoicing reform (RFE) moved closer to implementation, I needed to make my billing system compliant without replacing the existing application. Rather than switching to a SaaS platform or adopting an ERP, I chose to integrate the Factur-X standard directly into an existing PHP application running on a standard Apache server.

This article explains the architecture I built, what the standard actually requires, and the technical challenges I encountered along the way.

What is Factur-X?

Factur-X is a Franco-German standard for structured electronic invoicing that combines two elements into a single document:

A human-readable PDF/A-3 invoice
An embedded XML document compliant with the EN16931 European standard

Both are required. The PDF is intended for people, while the XML is intended for accounting software and automated processing. Together, they form a single electronic invoice.

Although Factur-X originated in France and Germany, it aligns with the European EN16931 standard and is part of the broader transition toward mandatory e-invoicing across Europe.

The VAT Legal Mentions, the Part Most Developers Miss

Generating a valid Factur-X file is only part of the job. The invoice itself must also include the correct VAT legal mention according to the client's location. Getting this wrong isn't a formatting mistake, it's a fiscal compliance issue.

When the issuer is based in France, there are three possible situations.

French client

The issuer is a micro-enterprise or is not subject to VAT. The invoice must include the following legal mention:

TVA non applicable, art. 293B du CGI

No VAT is applied, no VAT column appears on the invoice, and the legal mention is mandatory.

EU client (B2B with a VAT number)

The transaction falls under the reverse charge mechanism, meaning the customer declares the VAT in their own country. The invoice must include:

Autoliquidation – TVA due par le preneur, art. 283-2 du CGI

VAT is set to 0% and the legal mention replaces the usual VAT information.

Non-EU client

The service is exported outside the European Union. VAT exemption applies under the French tax code, and the invoice must include:

Exonération de TVA – art. 262 I du CGI

Again, VAT is set to 0%, but the legal mention remains mandatory.

These aren't optional notes added for convenience. They explain why VAT is absent or transferred, and using the wrong one can become a compliance issue during a tax audit.

In my billing system, the correct legal mention is selected automatically from the client's ISO country code and VAT number. The developer doesn't choose it manually. The business rules do.

The Technical Chain: How Factur-X Is Actually Generated

Generating a Factur-X invoice is split into two distinct phases, each handled by a dedicated component. This separation is intentional because XML generation and PDF/A-3 conversion solve different problems and have different technical requirements.

Phase 1: Building the XML

The first step is handled by a PHP component responsible for generating the EN16931-compliant XML document.

It reads the invoice data, including issuer and client details, service lines, VAT amounts, totals, and payment terms, then maps every value to its corresponding EN16931 business term. The generated document follows the Factur-X Comfort profile, covering the information required for standard B2B invoicing.

Several business rules must be respected during this phase:

Amounts use strict decimal formatting with no implicit rounding
VAT is aggregated by rate rather than by invoice line
Seller and buyer identifiers (SIREN, SIRET, VAT number) are placed in the appropriate XML elements according to the client's location
The VAT legal mention determined earlier is written as structured XML data, not only as visible text in the PDF

The generated XML is stored temporarily before the second phase begins.

Phase 2: Injecting the XML into the PDF

The second step is handled by a Python component using the Factur-X library developed by Akretion, one of the organizations behind the standard.

Its role is straightforward:

Read the PDF generated by the PHP billing engine using mPDF
Embed the EN16931 XML document
Convert the final document to the PDF/A-3b format required by Factur-X

I chose Python for this stage because the Factur-X library provides reliable PDF/A-3 conversion and XML embedding without introducing heavy PHP dependencies. It also validates the generated XML against the EN16931 schemas before embedding it, providing an additional compliance check.

The result is a single PDF/A-3 document containing the embedded XML, fully compliant with the Factur-X EN16931 Comfort profile.

Temporary Files

The XML only exists for as long as it is needed.

It is written to a dedicated temporary directory, embedded into the PDF during the second phase, then deleted automatically once the final document has been generated. Only the completed Factur-X invoice is retained.

What This Architecture Delivers

The result of this pipeline is a single document that is both human-readable and machine-readable: a Factur-X EN16931-compliant PDF/A-3 containing its embedded XML, ready for transmission to a French Partner Dematerialization Platform (PDP) or direct exchange with a client.

Beyond compliance, this architecture provides several practical advantages.

Self-Hosted by Design

The entire generation pipeline runs on the same server as the billing system. No external API is called during invoice generation, and no financial data leaves the infrastructure.

For organizations that require full control over their accounting data, this removes the dependency on third-party cloud services during document generation.

Independent from an ERP

The system doesn't rely on an ERP or existing accounting software.

Invoices are generated directly from the billing workflow, using the client information, service lines, VAT rules, and payment terms already managed by the application.

This makes the solution suitable for businesses that need Factur-X compliance without replacing their existing processes.

Compliance Built into the Workflow

Compliance isn't added at the end of the process.

VAT rates, legal mentions, and business rules are determined before the document is generated, then represented consistently in both the visible PDF and the embedded XML.

The result isn't simply a document that looks compliant.

It's a workflow designed to produce compliant invoices by construction.

Conclusion

Integrating Factur-X into an existing billing system isn't only about generating XML or converting a PDF to PDF/A-3.

The real challenge is translating business rules into structured data before the invoice is created.

The architecture described here, PHP for XML generation and Python for PDF/A-3 conversion and XML embedding, has allowed me to integrate Factur-X into an existing application without introducing an ERP, a SaaS platform, or unnecessary complexity.

If you're working on a similar integration, I hope this overview helps clarify where the real challenges lie.

Once the business rules are modeled correctly, generating a compliant Factur-X invoice becomes the easiest part of the process.

Go Further

Explore more technical articles

Read more technical notes

https://palks-studio.com

DEV Community: Anthony Leignel

What Happens When Electronic Invoicing, Digital Identity and Payments Become Interconnected?

Electronic Invoicing Is Only One Piece

Following the Data Changes the Picture

Identity and Payments Form Another Chain

The Bridges Are No Longer Entirely Theoretical

And This Is Where the Evidence Stops

But the Opposite Conclusion Would Also Be Wrong

Why I Published the Investigation

Read the Investigation

One Question Remains

Turning Google Search Console Exports Into Actionable SEO Data

Google Search Console provides the data. The challenge is knowing where to look.

Raw data is useful, but structure matters

Building an analysis layer instead of another SEO score

Keeping the architecture simple

Handling different Search Console exports

Finding opportunities without inventing information

Privacy as an architectural property

Why no direct Google Search Console API?

What the tool does not do

Small tools can solve narrow problems well

How Many Obsolete Dependencies Are You Using Without Knowing It? An Open Source Checker

Security also starts with what we install

An alert before a vulnerability becomes your problem

A tool that does not make decisions for you

Deprecated does not mean vulnerable

Why is it open source?

You do not need to be a developer to understand the result

A database designed to evolve

A few seconds to look at what we are using

Comparing PDF and XML Data Locally with Python, Open Source

A lightweight open source tool for detecting differences between two representations of the same document

The problem

A deliberately simple approach

Compare Two PDF Files Locally with Python, Open Source

A lightweight open-source tool for detecting textual differences between PDFs

How it works

Running it

Local by design

What it can be useful for

What it does not do

Open source

Repository

What if we stopped explaining technology only through text?

I created interactive experiences to show what really happens behind actions that seem simple

Understand in just a few clicks

Showing what the interface doesn't show

Another way to talk about technology

Explore the interactive experiences

The Palks Studio Approach

Why Palks Studio exists

Links

Simplicity is an engineering choice

Own the infrastructure

Data belongs to the client

Security starts with architecture

Business rules before automation

Systems instead of tools

A philosophy that guides every project

I Built a Local VS Code Environment That Puts Me Back in Control

Why I Built It

Links

Every Project Starts the Same Way

Documentation Should Never Be Manual

Every Change Is Intentional

Every Save Creates a Safety Net

Small Tools, One Responsibility

Conclusion

Go Further

I Built a Local Data Collection System in Python

Why I Built It

Links

What the System Does

Data Processing Pipeline

Extracting Business Information

Managing Contacted Leads

Exporting Data

Local First

Technical Stack