I learned to code so I could stop recommending things other people built.
Who I am
I’ve spent 20 years teaching innovation and strategy at international business schools and leading public universities in Barcelona, and 25 running marketing and digital transformation projects — most recently as a Marketing Project Manager at a Barcelona-based Industry 4.0 innovation company.
That taught me how to read an organisation: where the real bottleneck is, what will actually get adopted and what will end up in a drawer, how to explain it to the person making the decision without jargon. You don’t learn that by coding. You learn it by teaching for twenty years and sitting in the room where it gets decided which digital transformation project moves forward and which one gets cancelled.
What I didn’t have, until 2025, was the ability to build what I recommended myself. So I set out to learn to code properly, not superficially.
Today I do both at once: I think through the strategy and build the tool — the same person on both sides, with no handoff to a technical team in between, and no drift between the version that gets built and the one decided on in the first meeting. It’s an unusual combination: people who build fast have almost never spent twenty years understanding how an organisation decides; people who understand that almost never build.
What happened next
In less than a year, I went from not being able to write a line of Python to having two of my own systems running in production: a backend with real database-level data isolation, file processing, authentication, deployment on a European server and its own domain.
I’m not presenting that as a personal triumph. I’m telling you because it changes what I can offer you: twenty years of knowing what to ask and what to prioritise, applied with 2026’s development tools, without carrying how software used to get built a decade ago. That means what takes a classic consultancy six months and a team of four — discovery, proposal, handoff to development, project management — I do in weeks, on my own, because there’s no handoff: the same person who understood the problem is the one writing the code.
Why I build instead of advise
The market is full of people — myself included, for years — selling an AI assessment, a ninety-day roadmap and a report full of recommendations. I’ve written several of those reports myself. Most end up in a drawer, not because they were wrong, but because there’s a gap between the recommendation and the working tool that almost nobody crosses.
What almost nobody does is sit down and build the thing.
My bet is that a mid-sized company doesn’t need another AI strategy. It needs a concrete tool that solves a concrete problem, working, with its people using it — decided and built by the same person, in weeks, not months. And from there, decide what’s next with real data in hand, not slides.
How I work
-
I think and build at the same time. I decide scope and architecture while I build, with the same judgment I applied running digital transformation projects — not planning on one side and execution on the other, with everything that gets lost in that handoff.
-
I always start small. One department, one process, one set of documents. Never "total transformation". If the pilot doesn’t prove its value, we stop — and it is far better to discover that in three weeks than in nine months.
-
Fixed price, fixed scope. You know what it will cost before we start. I don’t charge by the hour.
-
No lock-in. You can cancel monthly maintenance whenever you want. If you stay, it’s because it works for you, not because you signed something.
-
I explain it. I work with non-technical teams. Part of the job is making sure you understand what has been built, where its limits are and what happens to your data. Twenty years of teaching are useful for something.
-
Your data, where it needs to be. I work with European infrastructure by default. When documentation is sensitive, the system can be deployed inside your own network. That is not an extra: it is an architectural decision from day one.
What I also build for myself
LowOrbits isn’t just a service business. I also build my own products, using the same tools and the same method I apply to client work.
Krakencast is the first: a private audio channel platform for organisations and universities. Reports, announcements or classes that people listen to instead of read, and only the people with permission can hear them.
This isn’t a side hobby. It is why I know what it really costs to keep a system running in production, rather than just deliver it and disappear — something very few AI consultants can say with evidence behind it.
What I no longer do
I spent years working in marketing and strategic direction, and I could keep selling that. I’ve chosen not to.
I don’t take marketing retainers or content work. It’s not that I don’t know how — they stopped interesting me, and I’d rather say that out loud than accept them half-heartedly.
What I have kept from that time is the ability to translate between business and technology. That is, frankly, where most AI projects fall apart — not in the model, but in the distance between whoever decides and whoever builds.
Let’s talk
If you have a problem you think could be solved by building something, tell me about it. Half an hour, no sales pitch and no cost. If I can help, I’ll tell you how and how much, with a fixed scope and price before we start. If I’m not the right person, I’ll tell you what you’d look for in my place — I won’t waste your time to close a sale that isn’t right for you.
LowOrbits S.L.U. Barcelona