Tech Lead · Full Stack Developer
Full stack developer with 5 years building end-to-end web products. I have led small teams as a tech lead: architectural decisions, stack and standards, and stepping into business logic when the team had no dedicated product role.
My default is the simplest option that solves the real problem — not the most complete one. And I think that with AI in the workflow (Claude Code and local models with Qwen), the technical side is no longer the bottleneck: the focus is on the solutions and on the people building them.
Bolivian and Peruvian citizen — authorized to work in both countries.
Principles
When there are two paths, the winner isn't the most elegant one — it's the one that puts less risk and less cost on the business. Migrating a whole database might be the "correct" move; an adapter that bridges it might be what keeps the product alive. I decide through that lens and I write it down so the team knows why.
When business asks for something and engineering oversizes it, I don't squeeze the team — morale and stress are part of the system. I first check with the team whether the requirement is genuinely oversized, then mediate with business to cut it down to an MVP, we measure it, and only with that data do we re-estimate time and infrastructure for the rest.
I use Claude Code and local models (Qwen) where they actually pay off: exploring systems I don't know, debugging, and code review. At Q-minex we received mining rigs of a model we had never handled; with SSH access from the plant network I used AI to map the firmware and its exposed APIs, and out of that came the integration proposal and the factory that brought them into the system — days of discovery cut to hours.
Toolkit
Money moving end to end
End-to-end Stripe implementation at Racquets App Suite for tournament entry fees, court bookings and training sessions. At Q-minex, Binance integration to control ASIC deposits into the main account and automate payouts of the generated balance. Trained on Bolivia's electronic invoicing API.
Track record
Part of the technical core of an 8-person startup, leading a team of three (two developers and a designer) building a platform for cryptocurrency management and remote control of mining equipment, distributed across 3 plants with 111 active rigs and physical capacity for 500. I made all the architectural decisions for the product and we reached the first production deployment in 5 months.
Sole owner of the backend and infrastructure for a real-estate platform (inmobile-app.com) where agents manage their properties and get matched with relevant listings. I built the entire backend in Go and owned scalability end to end. The implementation is complete and the product is in open beta on Google Play: first users on board and dashboards running while the public launch is prepared.
Sole developer of the system that replaced the inherited in-house platform — a black box with no documentation and no visibility — of a specialized academic-bibliography distributor for the Andean region (180,000+ titles). I built it alone in 3 months: a public institutional site with the book catalog, plus an admin panel behind login for catalog, clients, and invoicing.
Led the frontend of a B2C ecommerce platform for non-perishable goods, taking it from scratch to production in 8 months with one developer reporting to me. It replaced an existing Shopify store that already had traffic across Bolivia, so the rebuild had to hold on to that audience while lifting the limits the previous platform imposed on the business. I defined the architecture, the stack (Next.js), the code standards, and the design decisions.
Sole developer of the site for a coffee shop (lalalattecoffee.com): a product showcase with its own CMS so the owners could publish promotions and manage content themselves. Built in under a month and still running in production.
Tech lead for a racquet-sports platform (court booking and tournaments). I led both the React Native mobile app and the Node.js backend, coordinated a team of ~5 developers, and worked directly with the CEO to plan and implement new features. When I joined, the product had two modules (court booking and simple tournaments); I led the design and development of the tournaments and academy modules to scale it for broader use. It ran in production with 5 clubs and around 200 players.
Second frontend (and fifth overall developer) to join a logistics startup focused on freight transport, connecting companies with drivers and trucks. Over 2.5 years I accompanied the company's growth from 5 to ~50 people, working on three successive products: FMS, TMS, and the marketplace connecting freight with fleets and trucks.
In practice
Racquets App Suite · 2022
I joined to lead a racquet-sports suite already in production on Firebase. As complexity grew we decided to move to a relational database, and there were two paths: migrate every existing module, or write an adapter letting the old modules talk to the new database.
I chose the adapter. A full migration meant more time, more cost, and a real risk of breaking functionality already serving users. The adapter let the team build new modules on the right foundation from day one without freezing the product. The debt stayed bounded and visible — which is not the same as not having it.
Gaia del Sur · 2025–2026
Gaia ran on an in-house platform inherited from an earlier team: no documentation, no visibility into what it did with the business's own data, and nothing anyone could safely change. Replacing it was the easy call. Getting the data out was not — the catalog of 180,000+ titles only existed inside that system, with no export and no schema anyone could read.
Re-keying it was never real, and there was no trustworthy way into the database underneath. The one interface the old system still honored was its own: it could render every record on screen. So I wrote a Playwright scraper that walked the catalog the way a user would, and normalized what came back into the new PostgreSQL model. Scraping is usually a smell; here it was the cheapest honest way out of a system nobody could read. The point of the project was never new features — it was making the data legible to the business that owned it.
Q-minex · 2026
A batch of ASICs arrived in a model the system didn't support. We put them on the plant network and, with SSH access, I used AI to explore the machine: what firmware it ran, what APIs it exposed, what shape each endpoint returned. With that map we built the integration proposal, and I wrote the factory for the model so it could join the mining pipeline alongside the 111 active rigs.
The interesting part isn't that AI wrote code — it's that it compressed the slowest part, which was understanding a closed system we had no documentation for.
Inmobile · 2026
Inmobile matches what agents are selling against what buyers are looking for — a search pattern is just a listing with a different status. I put the matching on a Cloudflare Worker with its own cron, separate from the Go backend, so a slow scoring pass could never make an API request slow.
The cursor took the longest. The obvious approach — remember the last processed timestamp and resume from there — loses rows silently, because Postgres NOW() is stable inside a transaction: one bulk update stamps thousands of rows with the identical value, and any batch cutting through that group drops the rest of it. I moved to a keyset cursor on (touched_at, id) that only advances once the batch is fully written, so a run that dies halfway just reprocesses idempotently. Scoring runs entirely from in-memory caches too, because on Workers every extra lookup is a subrequest, and that limit is what decides whether you can compare a listing against the whole catalog or only a handful.
Own product · 2026
I built a multi-tenant SaaS on a managed backend and later moved it to self-hosted PostgreSQL. The managed service was the right way to start — it removed a week of setup I didn't need to do twice — but as the product grew, the pieces I most needed to control, authentication and database policy, were the ones I controlled least. So I made the migration, and added a check in CI that fails the build if a reference to the old provider reappears. A migration nobody enforces is just a cleanup someone will quietly undo.
The more interesting decision was what replaced it. Tenant isolation stopped being an organization_id filter written by hand in application code and became Row-Level Security in Postgres, with every tenant query running inside a transaction that sets the tenant for that session. The point isn't that RLS is more sophisticated — it's that the boundary now fails closed: a developer who forgets the filter gets no rows instead of somebody else's. To keep that true, every migration creating a tenant table has to carry its own policy, and a script in CI fails the build when one doesn't.
Background
In the final stage of my Systems Engineering degree, with the thesis project as the remaining requirement. I also volunteered at the university's student research society, contributing to projects and teaching web technologies to new members.
Let's build
Open to tech lead and full stack roles: remote with full overlap with US time zones, on-site or hybrid in Cochabamba, and formal hiring in Peru. I am open to travel and to relocating. I invoice directly and am set up to receive international payments in USD. The fastest way to reach me is by email.