The Python algorithm I built to get SEPE appointments

One of the most unusual projects I have built was a Python algorithm to help people get a SEPE appointment. It was not a polished app, a SaaS product or a large automation platform. It was something much simpler: a desktop bot designed to reduce a very real friction.

The problem was clear. Many people needed an in-person or phone appointment, but the system kept showing no availability. In that context, groups appeared that resold public appointments. My idea was the opposite: build a free and simple tool that helped detect availability windows without forcing users to click manually for hours.

The project ended up getting attention: I published the code on GitHub, shared it through thePalms and it later appeared on El Lado del Mal, Chema Alonso's blog, inside an article about getting a SEPE appointment without relying on resale groups.

The technical problem

The bottleneck was not only that the website was slow or that the user had to repeat clicks. At first, checking for new appointments seemed to require reloading the page and entering all personal data again from scratch.

While testing the flow, I found a curious behavior, almost a state bug: if you alternated between the in-person and phone options, the system refreshed the availability results without forcing a full page reload and without losing the personal data already entered in the form. That was the key insight. The new method was not to restart the form, but to alternate between those two buttons until an appointment appeared.

That kind of task has three specific traits:

1. It is repetitive.
2. It depends on preserving the form state.
3. It still needs a person to act when a real opportunity appears.

That is why I did not design the bot as a system that completed the whole process from start to finish. I designed it as an assistant: automate the repetitive clicks and leave the final decision to the user.

Why I used Python and PyAutoGUI

The solution had to be easy to run for non-technical users. That is why I used Python with PyAutoGUI and keyboard. I did not need deep integration with SEPE's backend or a complex scraper. I needed to control the mouse, record positions and repeat a sequence.

The logic was straightforward:

• The user opens the portal, enters their data and manually reaches the point where the in-person and phone options appear.
• The script records the positions of those buttons when the user presses Enter.
• When the user presses Esc, recording stops.
• After a short countdown, the bot alternates those clicks in a loop to refresh availability without restarting the form.
• If the user detects availability or wants to stop, they press Esc.

This architecture has an important advantage: it does not depend on fragile HTML selectors or small DOM changes. Because it works with screen coordinates, it behaves like a lightweight RPA automation.

The most important part: do not automate what you should not automate

A key decision was not to automate personal data, captchas or final confirmations. The user entered their data once, manually, and the bot only used the behavior of alternating between in-person and phone to refresh results. The tool helped with the repetitive part, but it did not try to bypass controls or book appointments at scale.

That mattered a lot to me. When you automate a public service, the ethical boundary matters. The goal was not to create unfair advantage or overload the system. It was to reduce unnecessary friction for people who were already trying to access a public service they had the right to use.

That is why I always understood the project as an assistance tool, not an exploitation tool.

What made it interesting

Technically, the project was not complex in an academic sense. There were no AI models, cloud infrastructure or distributed systems. But it was interesting because it solved a concrete task well.

What worked was:

• Simplicity: anyone could understand the idea.
• Product insight: the value was discovering that alternating channels refreshed results without losing the form state.
• Low cost: no servers or APIs were needed.
• Human control: the user still made the final decision.
• Adaptability: it could be used for other slow forms or portals.
• Social impact: it addressed a problem that affected real people.

This kind of project taught me something I still apply in automation: sometimes the best software is not the most sophisticated one, but the one that removes a repetitive burden at the exact right point.

Why it got attention

I think it got attention for two reasons. First, the SEPE appointment problem was easy to recognize: many people had suffered the same frustration. Second, the solution was easy to explain: a script that does the repetitive clicks for you and lets you react when an appointment appears.

The article on El Lado del Mal gave context to that scenario: the difficulty of getting an appointment, the method of alternating between channels to refresh availability without rebuilding the whole form and the use of automation to avoid relying on resale groups. It also mentioned that the original script was offered for free through thePalms.

For me, having a project like this appear in a technical media context was an interesting signal: you do not need to build something huge for it to have value. If the problem is real, a small solution can have meaningful reach.

What I learned

This project was a good lesson in practical engineering:

• Before automating, you need to understand the human flow.
• Sometimes the important discovery is not in the code, but in the product behavior.
• A slow interface can also behave like an API if you interact with it carefully.
• Automation needs clear limits.
• Documentation and legal notes matter, especially when code is public.
• A small project can communicate how you think as a developer.

It also reinforced an idea I later used in NexaVision AI projects: automation does not always mean removing the person from the process. Often it means removing the most tedious part so the person can act better when it actually matters.

If I rebuilt it today

If I rebuilt this project today, I would keep the same philosophy, but improve several things:

• A clearer interface for non-technical users.
• More robust visual detection to know when the page state changes.
• More explicit form-state checks to know whether the data is still loaded.
• Local logs to understand what happened during execution.
• Configurable pauses and limits to avoid aggressive patterns.
• More explicit documentation about responsible use.

Still, I would not lose the core idea: a small, understandable tool focused on helping, not exploiting.

You can see the repository on GitHub, read the coverage on El Lado del Mal or check the SEPE Availability Bot project page in my portfolio.