Antonio Luis Santos

I build AI driven applications and agentic systems that automate end to end workflows, integrate complex platforms, and operate reliably at scale with strong emphasis on security and fault tolerance.

Schedule a Call
Astronaut drifting in space

About me.
The person behind the code.

A Full Stack Software Engineer specializing in generative AI, leveraging expertise in ReactJS, Next.js, TailwindCSS, Supabase, Python, and FastAPI to solve complex technical challenges. Experienced in building AI powered applications, chatbots, and scalable web platforms, with a focus on AI and API integrations using tools like OpenAI, OpenClaw, and ClaudeCode, as well as automation platforms such as Zapier. Known for identifying system inefficiencies, designing intelligent solutions, and implementing workflows that improve performance, reliability, and user experience across multiple platforms.

Hands on experience integrating financial and business APIs including Intuit and Bill.com, ensuring seamless data flow and operational continuity. Adept at streamlining processes, automating repetitive tasks, and connecting disparate systems to deliver scalable, production-ready architectures. Background includes QA leadership and rule engine development with IBM ODM, contributing to enterprise systems while addressing operational bottlenecks and maintaining high standards for quality, accuracy, and performance.

Download Resume

Experience.
What I've built and where.

01/2025 - Present

AI Full Stack Software Engineer

Bruntwork Co. (Freelance)

IT & Web Development Integrations Specialist focused on building scalable automation and API driven systems across CRM,…

10/2024 - 12/2025

Senior IBM ODM Specialist (BRMS) & QA Team Manager

Bell Canada Inc.

Lead QA for a large-scale, customer-facing platform. Focus on accuracy, reliability, and seamless delivery while fosteri…

01/2023 - 10/2024

Senior IBM ODM Developer

Bell Canada Inc.

Lead end-to-end development of IBM ODM BRMS solutions aligned with business and technical requirements.

11/2020 - 01/2023

ODM Developer | BRMS Engineer (IBM ODM)

Bell Canada Inc.

Contributed to the design and development of enterprise applications using IBM ODM BRMS.

Tech stack.
The tools I use to build solutions tailored to you.

React
Next.js
TypeScript
JavaScript
TailwindCSS
HTML5
CSS3
Python
FastAPI
Node.js
Express
PostgreSQL
Supabase
Sanity
PHP
MySQL
TensorFlow
Docker
AWS
Vercel
Git
GitHub
Zapier
Netlify
Google Cloud
J
Java
C
C++
W
Wix
P
Postman
n
ngrok

Work.Things you can actually try, not screenshots.

All work
~/lab $ ls -la

The Lab.
Built with Claude Code.

portfolio — lab

// 60s reflex challenge — generated by claude code

60shits: 0acc: 0%

Click targets as they appear. You have 60 seconds.

Questions.What people ask before we start.

What problem do you actually solve?
I work as an AI automation and integration engineer, which in practice means this. Most companies lose hours every week to work that only exists because their software does not connect. Someone re-keys an order from one system into another, someone chases an approval over email, someone rebuilds the same report every Monday morning. I remove that work. Usually it is an API integration, sometimes a scheduled automation, sometimes an AI layer that reads messy input like an invoice or an inbound enquiry and routes it to the right place. The work is worth doing when it hands your team back time they can spend on something only a person can do.
How do you decide what to automate?
I look for where the volume is and where the mistakes are, which is rarely where the interesting technology is. Some decisions belong in deterministic rules you can audit and explain to an auditor, and I spent years building exactly that at enterprise scale with IBM ODM and BRMS. Others need a language model, because the input is unstructured and the rulebook would never finish being written. Getting that split wrong is why a lot of "add AI to it" projects get quietly switched off six months later. I came up through QA leadership, so I design for the failure case first: a process that is fast and occasionally wrong costs more than the slow manual one it replaced.
Which AI models do you build with?
OpenAI, Anthropic's Claude, Google Gemini, DeepSeek, Kimi, and open-weight models running on hardware you control. I choose per use case rather than per vendor, weighing cost per token, latency, context window, and how much of your data is allowed to leave your infrastructure. Some workloads should never touch a hosted API at all, and that call comes before the model choice. Building this way also keeps you out of lock-in, which matters because pricing and capability rankings shift every few months. Swapping the model underneath should be a configuration change, not a rebuild.
Will you replace the systems we already have?
Only if replacing them is a clear win, and most of the time it is not. My default is to keep what works and connect it, because your team already knows the tool, your history already lives inside it, and a migration is a risk you are choosing to take on. So I start by working out what the current system genuinely costs you: the licence, but also the manual steps built around it, the errors it lets through, and whether the vendor will still be around in three years. If that total is lower than the cost of moving, we integrate and you keep the stability. If the platform is a dead end that holds your data hostage or blocks something you need next year, I will tell you, and we plan a move you can survive. That means phased, reversible, with both systems running until the new one has earned the traffic.
How do we start, and how do you work with clients abroad?
A 30-minute call where you walk me through the process that annoys you most. From there the work runs either as a scoped build with fixed milestones or as an ongoing retainer if you want someone maintaining it. Support after launch is included on every package: 7 days on Starter, 14 on Professional, 30 on Enterprise. I work remotely from Quezon City, Philippines (UTC+8). Most of my clients are US-based, so overlapping their working day is routine rather than an exception, and I quote in USD for clients outside the Philippines.
What does an engagement cost, and how is it structured?
Most engagements are one of four shapes. An automation audit maps the process you want fixed and comes back with a ranked list of what to automate first, at a fixed fee credited against a build if you go ahead. An integration build connects two systems that currently need a person copying data between them. An AI feature build adds a model where it genuinely beats a rule, with guardrails and an evaluation set so the quality is measurable rather than asserted. A retainer covers the ongoing work, which is what most integration clients actually need, because automations sit between systems you do not control and an upstream API that changes its response shape on a Tuesday breaks things quietly. Each is quoted on scope rather than from a price list, and the audit is the cheapest way to find out what the rest should cost. I quote in USD for clients outside the Philippines.
How do you work with clients in other timezones?
I am in Quezon City, Philippines, which is UTC+8. Most of my clients are in the United States, so overlapping their working day is the normal arrangement rather than a favour: I take calls in their morning, which is my evening. Australia and Singapore overlap almost completely. The UK and Europe are the awkward ones and work on a few fixed hours of overlap plus written handover. What matters more than the clock is that you get something you can look at most days, so progress is visible without a meeting to explain it.
What does the first month actually look like?
A call where you walk me through the process that annoys you most, then I go and watch the real thing happen. The first deliverable is usually not code. It is a written description of the current process with the volumes and the failure points marked, because most people have never seen their own process written down and the argument about what to automate resolves itself once they have. Then the smallest piece that returns real hours goes first, in production, with the manual path still available. If that piece does not earn its keep, you have spent a small amount finding out, and the rest of the plan should change.
How do you choose which AI model to use?
Cost per token, latency, context window, and how much of your data is allowed to leave your infrastructure. That last one comes first and often settles it before the others are considered, because some workloads should never touch a hosted API. After that it is empirical: I run the actual task against two or three candidates with real inputs and compare the outputs, because benchmark rankings say very little about whether a model handles your particular mess of a document. The architecture keeps the model behind an interface, so swapping it later is a configuration change rather than a rebuild. That matters because the rankings move every few months.
What kind of work do you turn down?
Projects where the goal is to have used AI rather than to fix something. If a process is stable, low volume and nobody is complaining about it, automating it costs more than it returns and I will say so. I also turn down work where the automation would make a consequential decision about a person without a human able to see and overturn it, because I have spent a decade building decision systems in a regulated industry and know how those fail. And I do not take on work I cannot test, which in practice means projects where nobody can tell me what a correct outcome looks like.
What happens after launch?
Support is included on every package: 7 days on Starter, 14 on Professional, 30 on Enterprise. That covers anything broken and small adjustments, not new features. After that you can take it in-house, because you own the code and I document it for somebody who is not me, or keep me on a retainer. Automations in particular need someone watching: they sit between systems you do not control, and an API that changes its response shape on a Tuesday will break something quietly. Most clients on integration work stay on a small retainer for exactly that reason.
How do you know whether a process is worth automating?
Multiply how long it takes by how often it happens, then ask what it costs when it goes wrong. A task that takes two minutes and runs four hundred times a month is worth more attention than one that takes a day and runs twice a year. Then look at whether the inputs are consistent enough that a rule can decide, or messy enough to need a model, or genuinely require a person. If the answer is a person, the automation should be everything around the decision, so that when they arrive the information is assembled and the outcome is recorded. Removing the person from a judgement call is usually where these projects go wrong.
What does the IBM ODM background have to do with AI work?
IBM Operational Decision Manager is an enterprise rules engine, and I have built decision automation on it at Bell Canada since 2020. The relevance is that it teaches you which decisions must never be probabilistic. A rules engine gives an answer you can trace to the rule that produced it and explain to an auditor two years later; a language model gives an answer that is usually right and cannot be explained that way. Most real systems need both, and the value is in knowing where the line goes. Engineers who only know one side tend to put everything on their side of it.
Can you work with the team we already have?
Working alongside an existing team is usually the better outcome, and it is how most integration work goes. Your developers know the domain and will still be there when I am not. The arrangement that works is that I build the part that needs the specific experience, the integration layer or the AI component, alongside them rather than in isolation, and hand it over with documentation aimed at the person who inherits it. I also review code and set up the testing if that is the gap. What does not work is being handed a sealed specification and told not to talk to anybody, because the useful questions only surface in conversation with whoever does the work today.