Questions,
no detours.

Java back end with a data problem behind it, and automation with AI: a model that enters a real process and returns something useful at the end of the batch. The part that interests me most is the ugly one, the dirty data, the retries and what happens when the model falls over. And if the ground where it is going to run has to be built, count me in: it is the part the fewest people know how to do and the one that gives the most margin.

I am on staff and I stay open to commissions. What I do not do is promise availability in writing without knowing what we are talking about: the scope, the deadline and whether it fits in my time are things you see in a conversation, and from the start, not once you have already budgeted.

Yes. If you are looking for someone for a Java back-end team, to maintain a system that has been alive for years, or to put generative AI where the work is still done by hand, I fit. The CV is linked on the start page and in the experience section, with the education and the certifications.

Those with an identifiable problem and an ending. A lead-generation pipeline in six weeks is worth the same as a two-year joining of a product. What I do not get through is an indefinite project where it is not clear who the result serves: there the code gets written but nobody decides, and I have been in that place.

I live in Barcelona. Remotely I work without problem and I need to be there in person on very rare occasions: deploying something on a physical machine or setting up a server. Precisely for that reason I have the habit of documenting what I do on the machine, because nobody is going to ask me over a table.

With two questions that are not technical: what is the data that comes in and what is the result that someone is going to use. With that written down you see straight away whether it needs a language model, a SQL query or a spreadsheet. The first two sheets of the archive are projects that started exactly like that.

Private repository from the first commit and a README that is written at the same time as the code, not at the end to show it off. At my job I come in through agile methodology with JIRA. In my own work, the order is the data model first and the interface after: if the table is wrong, everything above it is going to spend the time correcting itself.

Yes, and I write it where it can be read without me. Every tool of mine leaves a run log and a summary when it finishes: the batch downloader says how many links went through and how many did not, the compressor says which combination of eleven it had to use to fit inside the limit. Progress that only lives in a meeting evaporates by Thursday.

As a decision, not as a favour. A scope that grows changes the date or changes the price, and I say it at the moment it grows, not at the end. The only thing I do not do is take it on quietly to look good; that ends up costing me weekends and it costs the project quality.

README with what it does, what it does not do, how it is run and what has to be configured, plus the comments put where they are going to be read in a year's time. The READMEs of my repositories are long on purpose: they are the only part of my work I can show without anybody's permission, so they also serve me as proof.

When it is called for and without fooling myself. The CRM carries one hundred and thirty-five tests. This same year I decided which ones to write before starting on two small projects, and there are two sheets of the archive where I say plainly that they must have them and they do not, instead of keeping quiet about it. I would rather say where I owe money than pretend the project is closed.

In the CV, which you have in English and in Spanish linked from the start page and from the experience section, and on LinkedIn. Quality in Zeelo between 2021 and 2022, and development in NTT DATA since 2024 on insurance projects, with migration of IBM Mainframe environments and back end for generative AI. Formal qualifications: a CFGM in systems (intermediate vocational training) and a CFGS in multiplatform application development (higher vocational training), plus a Java full-stack certificate.

Languages, Java, Python and PHP. Back end, Spring Boot and Spring AI. In front, React with TypeScript, and I defend hand-written CSS when the project does not need a framework. Data, MySQL, MariaDB, PostgreSQL and SQLite. AI, local language models, RAG with a vector index, agents and MCP tools. Systems, Linux, Windows, Docker and network administration. Testing, Cypress and JUnit. Unity, the time necessary.

Back end. My site is the data model, the contract of the endpoints, the multi-tenant and what happens when a batch of thirty thousand items fails at the four thousand. I use React and TypeScript in production and I get them done, but I am not going to sell you that I am an interface designer.

Just what is necessary, and I do it by hand. This portfolio is laid out in HTML and CSS with no framework and no build process, with a light and a dark theme, and all the text and background combinations measured with a script so that they meet level AA of accessibility. It is a small piece of craft, but it is mine and it can be checked with the inspector.

Because the repositories are private: those of my company by contract, and mine because they contain business rules and third-party data. Each sheet of the archive says how many endpoints, entities, tests and lines there are, counted over the repository, and the code can be seen in a conversation if it is needed. It seems to me a better proof than a public repository with four commits of a library that nobody maintains any more.

Seven cases with a sheet in the archive. A multi-tenant CRM with local AI, subtitles and translation that never leave the device, three lead-generation pipelines, a game engine with an AI mode and its deterministic version, a shift planner and two servers of my own. Plus five loose tools, a PDF compressor among them, which I show in one line because they are worth what they do, not what their architecture is.

By email or by phone: both are inside the CV, linked in the contact section of the start page. Also on LinkedIn. I prefer email for anything long, because details get lost in a chat.

Open to project work and to hiring, as the front page says. The concrete availability depends on the month and on what is taking up my free time, so it is confirmed when you write, not here, so that you do not read an out-of-date figure.

I do not publish a reply time that I have not measured. If you have no news in two working days, write again or say something to me on LinkedIn: sometimes the email from a stranger goes to the bottom of a box and it is not a lack of interest.

Barcelona, Spain. Central European time zone, which covers any European client and half of Latin America without effort.

Yes, and it is probably the best way to start. A first conversation serves to order the problem, and sometimes the result is that no code needs to be written. I will tell you in that conversation, not once I have already written it.