PORTFOLIO / SELECTED EXPERIENCE

Rionegro, CO · GMT-5 10+ yrs

Gian Barboza — Senior Backend Engineer & Software Architect

Senior Backend Engineer & Software Architect

Designing and building backend systems, distributed architectures and payment platforms for production.

Hands-on: I design the architecture and write the code that runs in production.

Developer → CTO → Senior Backend Engineer & Software Architect

A decade of designing, building and evolving production systems across payments, distributed infrastructure and automation.

Nov 2023 — Aug 2026

Senior Backend Engineer

Hablax Inc. · 100% Remote

Led AI-driven initiatives on the gift cards and top-up platform: AI-generated programmatic SEO, fraud detection engine with extensible rules, gateways to modernize legacy services, and a multi-channel notification orchestrator.

Apr 2023 — Nov 2023

Full Stack Engineer · Freelance

Independent clients · Remote

Built an end-to-end digital-goods e-commerce with a modern stack: Next.js, TypeScript, Clean Architecture and Vitest. Full Stripe and PayPal integration, delivery automation, and custom admin system.

Dec 2017 — Apr 2023

Full Stack Developer → CTO

Hablax Inc. · 100% Remote

Grew from developer into CTO leading a team of 4 developers. Designed the migration from monolith to an 8-server distributed infrastructure on DigitalOcean, integrated the core payment processors (PayPal, Payeezy, DLocal), and built the multi-provider product engine with automatic failover.

Jan 2016 — Mar 2017

Java Software Developer

Fermat.org · 100% Remote

Built P2P Android apps on top of cryptocurrencies (taxi, e-commerce) where payments landed directly in the provider's wallet with no intermediaries. First exposure to decentralized systems and 100% remote work.

Numbers that shipped to production.

A few metrics that summarize a decade of decisions.

10+
Years of Experience
99.9%
Uptime on Critical Infrastructure
$200K+
Transactions Processed / Month
5+
Payment Providers Integrated

Production systems and an independent public-beta product.

Explore the context, problem and architecture behind production systems and Rentoru, a publicly available independent product still in development.

01 Rentoru — Residential Rentals Public beta
Context
Independent full-stack product for long-term residential rentals in Venezuela. Public beta, still in development: publicly available and functional, with corrections ahead of the marketing launch.
Problem
Publishing a rental involves more than a listing form: persistent drafts, property management and CSV portfolio imports need to work alongside filtered search, ownership checks and controlled access to publisher contacts.
Architecture

Built with TypeScript, React and Next.js, with a backend separated into domain, application and infrastructure layers. PostgreSQL persistence uses Drizzle ORM on Neon. Auth.js handles Google OAuth and email sign-in through Resend; ownership authorization controls property management, and access to publisher contacts is rate-limited.

The image pipeline uses signed Cloudflare R2 uploads with validation, Sharp-generated WebP derivatives and perceptual duplicate detection. Lifecycle emails, retry handling and scheduled cleanup cover background operations. Vitest unit and integration tests and Playwright browser tests include JavaScript-disabled flows, with GitHub Actions checks for types, coverage, builds and integration.

Result
Public beta, still in development · Listings, drafts, search and portfolio management available · Corrections ahead of the marketing launch
TypeScriptNext.jsPostgreSQLDrizzle ORMCloudflare R2VitestPlaywright
02 Multi-Gateway Payments Integration with Failover 5 payment providers
Context
Global gift cards and top-up operation where relying on a single gateway leaves gaps in geography, conversion, and availability.
Problem
Each gateway covers different countries at different fees, and any of them can go down or start rejecting more without warning. On top of that, every provider ships its own API shape — integrating them one by one would have scattered provider-specific code across the platform.
Architecture

Every provider sits behind a single payment contract. Each integration adapts its own API — different auth, field names and error shapes — into normalized request and response objects, so the rest of the platform charges, refunds or voids without knowing which processor is on the other side.

Selection and behaviour are decoupled through design patterns: a Factory resolves which integration to build, Strategy lets each provider carry its own behaviour behind the shared contract, Adapters absorb the per-API differences, a Builder assembles the more complex provider requests, and a Repository keeps transaction persistence out of the payment logic. Routing is configuration, not code — active provider and priority chain per product — with automatic failover when the active one fails or rejects. Five processors integrated end to end (PayPal, Payeezy, DLocal, Stripe, Shift4) with 3DS, refunds, voids, Apple Pay, Google Pay and in-house card tokenization.

Result
5 payment providers in production behind one contract · A new provider integrates without touching platform code · Payments stay available through provider incidents · Routing tuned per country for cost and conversion
StripePayPalDLocalShift4PayeezyPayment Routing3DSApple PayGoogle PayTokenization
03 Fraud Detection with Extensible Rule Engine Hours, not weeks
Context
Payments platform exposed to two fraud vectors: transactional (stolen cards, suspicious patterns) and access-level (multi-accounts, account-takeover attempts).
Problem
New fraud patterns appeared faster than the pipeline could absorb them: every rule meant editing the central evaluator. And detecting suspicious accounts or devices could not come at the cost of friction for legitimate users.
Architecture

Separated the evaluator from the rules. A Factory builds each rule, every rule owns a single responsibility, self-registers, and receives an already-normalized context — so adding a pattern means adding a class, never editing the engine. Access fraud runs as its own layer on device fingerprinting, keeping session signals (multi-account abuse, account takeover) out of the transactional path.

Also prototyped LLM-based contextual evaluation, imitating how a support agent decides. It stayed in beta and never reached production.

Result
Significant reduction in manual review load · New rules ship in hours instead of weeks · Both fraud vectors covered without either touching the other's code
Factory PatternSRPDevice FingerprintingRules Engine
04 Monolith to Distributed Infrastructure Migration 99.9% uptime
Context
Gift cards and top-up platform processing ~1,000 transactions/day and $100K–$300K in monthly volume — all of it on a single server.
Problem
An availability problem, not a throughput one. The calling system consumed every resource on the box, so traffic spikes on Mother's Day and New Year's Eve took the whole platform down for ~3 hours — on the most lucrative dates of the year.
Architecture

Redesigned it as an 8-server distributed architecture on DigitalOcean, separating web, database and dev tiers so no workload could starve another. HAProxy for HTTP load balancing, MySQL master-slave replication for read capacity and standby, node-level failover, automated backups and recovery runbooks.

The trade-off: the legacy stack could not be provisioned automatically, so the topology was built by hand over Linux — slower to stand up, but it removed the single point of failure without rewriting the application first. Led a team of 4 through the migration.

Result
99.9% uptime sustained since 2019 · Zero outages during peak dates over the last ~5 years
MySQL ReplicationHAProxyDigitalOceanNginxLinux
05 Programmatic SEO with AI at Scale Org. traffic ↑
Context
Thousands of dollars in monthly paid-ad spend, with a catalog of 1,600+ products per provider multiplied across multiple countries and services.
Problem
Cut the dependency on paid acquisition without losing volume. Writing landing content by hand for thousands of country/service/product combinations was never going to happen.
Architecture
Designed it as a hierarchical pipeline rather than a one-off content dump: three tiers (country → country/service → country/service/product), each inheriting context from the one above, populated through ChatGPT-4o with prompts curated per vertical. The pipeline is event-driven — a new product landing in the catalog regenerates the affected tiers on its own, so the content surface grows with the catalog instead of drifting behind it.
Result
Significant replacement of ad spend with organic traffic · Better new-client ratio than the paid channel · Scales autonomously with the catalog
ChatGPT-4oNode.jsProgrammatic SEOAIPHP

Technical expertise.

Tools and patterns I reach for, grouped by domain.

Backend Engineering

Node.jsExpressTypeScriptNext.jsPHPLaravelRedisJavaREST APIs

Architecture

Distributed SystemsHigh AvailabilityClean ArchitectureDesign PatternsGateway PatternAPI Design

Infrastructure

LinuxHAProxyNginxMySQL ReplicationPostgreSQLDigitalOceanDockerGitHub ActionsCronjobs

Payments & Risk

StripePayPalDLocalShift4PayeezyPayment RoutingFraud EnginesDevice FingerprintingPCI Compliance

Automation & AI

LLM IntegrationAI-assisted development (Claude Code, Codex)Programmatic SEOContent AutomationWeb Scraping

Open to Senior Backend Engineer & Software Architect roles
in backend systems, distributed architecture & payments.

Available full-time: remote, or on-site/hybrid in Medellín, for production systems with real technical constraints. Fastest reply via email or LinkedIn.

Get in touch