Hi, I'm Santiago.

I'm a software engineer and I've spent more than seven years building products. I started out in payments and lending, for fintech and telecom, and now I work on AI products and mobile apps as a software consultant.

Right now I work from Valencia, Spain, for Oddball Studios and Dozuki.

At ODD we make a Bluetooth ball that you connect to your phone to create music. I take care of the app, the Bluetooth connection and some parts of the sound engine. At the same time we're building a new product, HelloHola, which uses AI to translate calls and conversations in real time.

At Dozuki we make software that other companies use to train their employees. I take care of the mobile app.

Here's my CV in case you'd rather have the summary.

Oddball Studios

Oddball is a creative studio where we combine technology with art and creativity to bring interesting projects to life.

We have two fronts at ODD right now:

1. A Bluetooth ball we sell at oddballism.com. You buy it, connect it to your phone and install our app. With it you can play musical instruments and play music, using the ball as the "instrument". It's pretty cool.
2. A product called HelloHola, which lets you translate any conversation in real time between different languages. The idea is simple: two people who don't share a language can talk fluently, each in their own voice. Whether it's a virtual call (Google Meet style), a phone call or just putting the phone on the table while you talk to the other person, it does the job.

What I've done on ODD

• The Bluetooth connection between the ball and the app. Native integration using Java and Swift.
• Full integration with the Firebase and Google Cloud suite, including sign-in with Apple and Google, in-app purchases, notifications, Cloud Functions, Firestore, Storage and more.
• The Sound Wall: a feed where you can publish your own songs to the world, and people can listen to them and like them.
• The serverless architecture behind all of that.
• Automated tests that run the app on real phones.
• CI/CD pipelines that automatically build the app and upload it to the stores.
• Fixing bugs and adding new features.

What I've done on HelloHola

• The server that ties together telephony, transcription, translation and voice, and keeps the conversation flowing.
• The Flutter app with the three modes: In-App, Telephony and Video Call.
• The end-to-end tests that verify all 32 languages against real providers.

Dozuki

Dozuki makes the software factories use to write their work instructions and train their people. It's a company with many years of product behind it. A lot of the code was already there when I arrived.

I work in two places. On the mobile app, so operators can use Dozuki from a tablet or phone, even without internet, and on the backend, changing APIs and endpoints or adding new features to the product.

What I've done

• Closing the findings of an external penetration test.
• Migrating legacy code to a clean architecture.
• Offline functionality: operators can now use the app without an internet connection, and the content syncs automatically when the network is back.
• A tool Dozuki uses to move its customers' content. It works asynchronously and can move several terabytes of content at once.
• Fixing bugs and adding new features.

Virgin Mobile

For a year I was the only engineer Virgin Mobile had to keep its systems running in Colombia. I ended up working on almost everything: the website, the backend, the plans sold to the public, the purchase flow and payment gateway, and number portability.

What I did here

• The number portability flow, so people can move their phone lines from other carriers to Virgin.
• Colombian government rules and regulations. This includes tags for automated web scraping, transparency pages, consistency of information and more.
• Migrating the old code (JavaScript) to clean architectures and modern patterns (Node.js, TypeScript, AWS).
• Async processes on AWS using SQS and Lambdas.

Tigo Money

Tigo Money was Tigo's digital wallet in Guatemala. On the lending team I owned the financial engine of the product: interest, cut-offs, statements, refunds and automatic debit.

What I did

• Test-Driven Development methodology.
• Building AWS Lambda functions that run asynchronously and calculate the billing cut-offs (interest calculation, statements, credit notes and automatic debits). We built the whole backend on serverless AWS with Python and in-house frameworks.
• UIs in React and Flutter.
• Building the company's back office.

Quan

Quan sells vehicle insurance (among other things) in Colombia. I was hired to build the software from scratch. We sat down with the founder, gathered the requirements, talked to each of the providers and built the first version of Quan. Then we handed it over to a software consultancy that still runs it today.

What I did

• Led a team of 3 developers through this whole bootstrap.
• Requirements gathering with the founder and the first users.
• Technical conversations with different providers.
• Building the complete backend on Google Cloud, using Kubernetes, clean architectures and async processes between microservices.
• Building the mobile app in Flutter.

tyba

tyba is an investment app for small amounts. They hired me to build one specific thing: the crypto investing module.

What I did

• Turning the Figma designs into working modules inside the Flutter app.
• Connecting those modules to the backend team's APIs.
• Unit and integration tests.
• Return and investment projections.

Ualet and Skandia

Ualet was the first app in Colombia for investing small amounts. We were four on the team. I was the backend person and also worked on the Flutter app.

Some time later Ualet shut down, and Skandia bought the product and relaunched it in Mexico as Savebox. There I took over the backend architecture and the whole identity verification flow.

What I did

• Design and implementation of the whole backend, including the connection to investment providers.
• Building the complete KYC flow for identity verification, in both Colombia and Mexico.
• Implementing Google Analytics.
• Building new features and fixing bugs in the Flutter app.

Siigo

Siigo makes accounting software for small businesses. It was my first job at a big company. I worked on Aurora, their payment gateway: the flows where Siigo bills its subscribers and where those subscribers' customers pay their invoices. Several modules I built in 2020 are still in production.

What I did

• Building the UI of their payment gateway.
• Building the UI of their invoicing system. Sometimes I see businesses still using the interface I coded back then.
• Fixing minor bugs.
• Endpoint tweaks, database migrations and deploying microservices on Kubernetes.

Vivarium

My first job, at eighteen. An app for field teams photographing properties across Bogotá, with GPS routes and live location. I learned more than I delivered, but it got delivered.

What I did

• Building a mobile app in Flutter, connected to Firebase.
• Offline maps.
• Saving GPS positions.
• Syncing with the backend when the connection came back.

Billiards VAR

What landed on my desk

A client has a scoreboard for three-cushion billiards clubs. They put a camera above the table and a mini PC that records the shots. They wanted the system to say on its own whether a shot is a point or not, like a VAR.

The rule is short: the shot counts if your ball touches the other two and, before touching the second one, it has already bounced off the cushions at least three times.

They already had a first version with AI. In their tests it got it right 88% of the time.

What I was asked to do

Take that 88% as close to 100% as possible. And keep it running on the same mini PC the clubs already have, which is a modest machine.

How we approached it

The first thing was getting data. We used broadcasts of professional tournaments, around 60 matches, and taught a program to read the on-screen scoreboard to know what the referee called on each shot. That gave us more than 5,600 labelled shots without having to go through them one by one.

With that we measured the existing system on full matches. There it got about 57% right. Looking into why, the problem wasn't in the decision. It was earlier: the system kept losing sight of the balls. With good positions, that same logic went up to 92%.

So we decided not to train a model that guesses point or no point. Billiards is physics. If you know where each ball is at every instant, you can reconstruct what happened and apply the rule. We split the problem into three pieces.

And we set one condition for measuring: always on matches the system had never seen.

1. The ball detector

It's a small neural network that looks at three consecutive video frames and says where each ball is. Looking at three frames lets it see motion, and that helps when a ball is moving fast and comes out blurred.

It finds more than 99% of the balls, with an error of less than a millimetre. That holds on tables of a different colour and with balls it had never seen. On the club's mini PC it runs at about 43 frames per second.

2. The physics engine

It takes those positions and reconstructs the shot: the path of each ball, every cushion bounce and every ball-to-ball hit, with the instant it happened.

Every time a ball changes direction, the engine tries several explanations. Was it a cushion? Was it another ball? Both? It keeps the one that fits the physics best.

One detail that took work: to count a hit, the ball that was hit has to really move. Before, a still ball that jittered by one pixel in the video could pass for a touch.

Before using it on real matches we tested it on thousands of simulated shots, many of them borderline on purpose.

3. The decision

With the events in order, applying the rule is easy: you count the cushions before the second ball.

What matters is that the system also says how sure it is. If it's sure, it decides. If not, it sends the shot to human review, just like a VAR. There are shots even referees don't always call the same way, like grazes where the ball moves less than a pixel.

How it turned out

On 36 matches the system had never seen, more than 3,200 shots, the engine gets 97% right. In VAR mode it decides 92% of the shots on its own and gets 98.6% of those right. The rest go to review.

All of it runs on the club's mini PC. We delivered the code in the client's repository, with a tool so their team can test any video and see why the system decided what it decided.

My CV

Sorry, I had to keep it to two pages. I keep it up to date.

• CV in English (PDF)
• CV en español (PDF)

If you want to talk

Write to me at svelandiacasas@gmail.com or find me on LinkedIn. I read everything that comes in.