- WEBSITES
- APPLICATIONS
- INTERNAL TOOLS
- AUTOMATION
No templates, no page builders: every piece answers to how your business actually works.
Tell me what you need and I’ll tell you how I would build it, no strings.
WORKS
In this UNESCO project, I collaborated with the team at DeuSens Hiperexperiencia on an interactive web application that lets users explore cultural heritage through scroll-guided navigation in a 3D environment. My contribution focused on implementing functional components on the frontend, integrating a multilingual support system, creating custom overlays with Google Earth and incorporating them into the web, plus performance optimisation and debugging. All of it in close collaboration with the team’s UX/UI designers, developers and 3D modellers.
View live site ↗A financial literacy game built to teach personal finance and investment strategy. Players work through interactive scenarios, make financial decisions and see the consequences play out in a simulated environment. Each player gets their own 3D character: the avatars come from Ready Player Me through its React SDK, and Needle Engine puts them in the scene and runs it in the browser. React on the frontend and Node.js on the backend, with the database storing player progress and game state.
View live site ↗An operations platform for a logistics yard that moves reusable transport equipment, meaning cages, boxes, pallets and separators, from unloading through cleaning, repair and stock all the way to dispatch. Two front ends off one Svelte Kit codebase: an admin panel covering production stats, stock exports, clients, repairs and shift assignments, and an offline-first PWA for the warehouse PDAs, with generated barcode labels for the equipment on the floor.
Private app, no public URLAn Odoo-style business platform that keeps several departments working inside one system rather than a scattering of disconnected tools. A dozen modules hang off a single admin panel: projects and the tasks under them, a CRM for the commercial side, services and subscriptions, hours and absences, a shared inbox, users and permissions, and analytics and reporting that read across all of it. Each department gets the modules it actually uses instead of a generic install nobody fully adopts.
Private app, no public URLABOUT
I am Richard, a developer based near Lleida, in Spain. Most of what I work on did not exist before someone needed it: a logistics yard that needed its own flow tracked from unloading through repair to dispatch; a department that needed its own module inside the ERP it already runs on; a heritage collection meant to be walked through in 3D, built with the team at DeuSens. No theme, no template, the tool itself.
Professionally I started in April 2024, on the front end. Then full stack at DeuSens: Angular, Svelte and Node, 3D in the browser and realtime, including Dive Into Heritage for UNESCO with the team there. After that, eight months of Odoo modules in Python, migrating invoices and sales orders between versions, with the client on the other end of the call.
Now I build operations platforms from nothing, and two of them run other people's working days: ten modules an office lives in, and a logistics system about twenty operators carry around a warehouse on a PDA. The data model, the architecture and the stack get decided before a line exists, and the code is written fast against decisions already made.
The newer end of it is data and AI, which I am studying formally. On your project you talk to the person building it, and one person is accountable from the scope to the last deploy. Fast. Structural. Built to order.
Two platforms in production, both built from nothing
SERVICES
I build lightning-fast web applications completely from scratch. No bloated themes, no messy page builders, just clean custom code tailored precisely to how your business operates.
That choice pays off the longer you own it. Nothing here is inherited from someone else's product, so there is no plugin to break on the next update and no vendor deciding your roadmap for you. When you need a new flow six months from now, I add it in days instead of working around a framework that was never built for your case.
You and I agree what earns its place before anything gets built, so the budget goes where it moves the business.
You see working software every week rather than a status report. Course corrections happen while they are still cheap.
You get the code, the deploy pipeline and the documentation. No lock-in, no retainer you cannot walk away from.
Turn passive visitors into active customers. I weave subtle, high-performance 3D elements and smooth animations that make your brand memorable without sacrificing loading speed.
The hard part is not making it look good, it is making it run. Every model gets a polygon and texture budget before a single frame is rendered, and I test on mid-range phones instead of the machine it was authored on. If an effect cannot hold its frame rate there, it does not ship.
I decide what the 3D is actually for, so it carries the message instead of competing with it.
A rough interactive version early, in front of real people, before the expensive modelling starts.
A hard ceiling on file size and frame time, agreed up front and measured on real devices.
Design that starts with your customers instead of a template. I map the routes people actually take through your product, then shape screens that feel obvious to use, so fewer people get stuck and more of them finish what they came to do.
Design decisions are engineering decisions too, so I make them in one pass. Every screen ships as a reusable component with its states already defined, which means the next feature builds on what exists rather than adding another one-off. Your product stays coherent as it grows and your team stops rebuilding the same button.
I follow the real paths, including the messy ones, before drawing a single screen.
Screens that read on first use, with the empty and error states designed rather than discovered.
Components and rules your developers can build against, so the product scales without drifting.
A slow site loses people before they ever see what you offer. I find what is genuinely holding your pages back, fix it at the source rather than papering over it, and hand you the numbers from before and after so you can see exactly what changed.
The weight is rarely your own code. It is the third-party scripts nobody audited, the fonts loading in the wrong order and the images shipped at four times the size they render at. I cut what is not earning its keep and load the rest when it is actually needed, which is usually the difference between a page that feels instant and one people abandon.
Real visitor data first, not a single lab score, so I fix what affects the people actually using it.
I remove the cause instead of stacking a cache on top of the problem.
Plain numbers you can show anyone, plus what to keep an eye on as the site grows.
Before you spend a budget on AI, find out whether it belongs in your business. I take one process your team repeats every week, test whether a model beats plain code at it, and settle the question with something you can actually run.
The model is the small part. What holds it up is the plumbing: orders between systems, automation inside an ERP people have open all day. Integration work like that is what I get paid for, and the data and AI degree is in progress. If it cannot beat what your team does by hand, that is a result too, and cheaper than finding out after launch.
I cost out the work your team repeats by hand, so the case for a model comes back as a number.
A small version running on your own data within weeks, so you decide on results instead of a demo video.
Build it, park it, or do it in plain code, with the cost of running it written down either way.
I map the whole product before anyone starts building it. What you need it to do becomes an architecture, a data model and an order of work, so the expensive decisions get made on purpose instead of by whoever opens the editor first.
I plan the way I build, because I have done both ends of it alone: a logistics platform from first sketch to the server it runs on, and a dozen modules inside one system. That is where you learn which decisions stay cheap and which ones you live with. You leave with a plan plain enough that the next developer you hire starts on Monday.
How the pieces fit, written so a new developer can follow it without you in the room.
A straight answer on every piece, including the ones where buying someone else's product beats paying me to write it.
What to build first so something is live and earning early, and the risks named while they are still cheap.
