Professional Experience

Virtual Tech GT — Educational E-Commerce Platform

• React
• TypeScript
• Kotlin
• Java
• Spring Boot
• Node.js
• PostgreSQL
• DynamoDB
• Redux
• AWS
• Stripe

→ Live demo

Description

Virtual Tech GT is a full-stack EdTech e-commerce platform that lets educational institutions and training providers sell, deliver, and certify online courses. As Software Developer (June 2019 – September 2022), I worked across the entire stack — React/TypeScript on the frontend, Kotlin/Java/Spring Boot and Node.js/Express services on the backend — and the work that actually moved the business number (a ~40% increase in course sales) was as much about checkout friction and funnel design as it was about backend architecture.

For an institution, this platform is their online education business — every course sale, every completed exam, every invoice runs through it. That framing shaped the priorities: reliability and compliance weren't nice-to-haves layered on top of a course catalog, they were the product, because an institution won't put its revenue and its regulatory standing behind a platform that treats either as an afterthought.

Content Delivery and Assessment

The platform's two jobs, beyond commerce, are getting course content to a student reliably and proving they actually learned something. Video content is served from cloud storage encoded for web playback rather than raw uploads, so a student on a weaker connection in a smaller city gets a degraded-but-working experience instead of a spinner — a deliberate tradeoff given the platform's actual user base spans well beyond fast urban connections. Exams are taken directly inside the platform and tied to course completion, which matters commercially as much as pedagogically: for most institutional customers, the certificate at the end is the actual product being purchased, and the course video is the delivery mechanism for it. An exam feature that isn't trustworthy — that can be gamed, or that loses a student's progress — undermines the credential the institution is selling, not just the UX.

Key Responsibilities & Achievements

• Built and launched the platform end to end, taking course sales and delivery from concept to a system driving a ~40% increase in course sales — through funnel optimization and checkout UX, not just backend throughput.
• Architected REST APIs and microservices in Kotlin, Java, and Spring Boot, with Node.js/Express for lighter, IO-bound services — a deliberate split, not a historical accident: core transactional and domain logic stayed in the strongly-typed JVM services, while thinner integration endpoints moved faster in Node.js. PostgreSQL and DynamoDB backed transactional integrity and flexible data models respectively.
• Built the React frontend around reusable components, Hooks, Redux, and Context API, which kept state complexity manageable as the platform grew from a single course catalog into a multi-institution commerce and content-delivery system.
• Integrated Págalo, 2Checkout, and Stripe side by side, because a Guatemalan/Central American customer base does not convert on a single US-centric payment processor — offering the payment method a buyer already trusts was a direct lever on completed-purchase rate, not just a technical integration checkbox.
• Applied OOP, SOLID, and clean architecture across the Kotlin/Java services so the backend could absorb three years of institutional customers with different course structures and pricing models without each new customer becoming a special case in the codebase.
• Automated invoicing and regulatory compliance through SAT and InFile integrations — SAT is Guatemala's tax authority, and manual invoicing at course-marketplace volume is both an operational bottleneck and a compliance risk. Automating it let institutions scale their catalogs without scaling back-office headcount in lockstep.
• Ran the platform on AWS with CI/CD pipelines for availability, fault tolerance, and repeatable, low-friction releases.
• Worked in Agile/Scrum, shipping iteratively against real institutional feedback rather than a fixed upfront spec.

Tech Stack

Key Learnings

In EdTech commerce, the certificate is often the product and the video is the delivery mechanism. That reframes what "reliable" means for a feature like exams — it's not just uptime, it's whether the institution can stand behind the credential it's selling.

Payments are a UX and market-fit problem before they're an integration problem. Wiring up Págalo, 2Checkout, and Stripe side by side mattered less for the API calls than for meeting Central American buyers with a payment method they already trusted — that's what actually moved completed-purchase rate.

A polyglot backend is a legitimate architecture decision, not a lack of discipline. Keeping core domain logic in Kotlin/Java and pushing thinner integrations to Node.js let each side move at the speed its actual complexity warranted, instead of forcing every endpoint through the same framework regardless of fit.

Clean architecture pays off most in long-lived backend services. Applying OOP and SOLID principles across the Kotlin/Java microservices kept the codebase extensible over three years of iteration and a growing, heterogeneous set of institutional customers — where a less disciplined structure would have accumulated much more debt.

Automating regulatory workflows (SAT, InFile) removes an entire class of manual error, and for institutional customers specifically, compliance risk is a bigger deal than it looks from the engineering side — it's the difference between an institution being willing to scale its catalog on the platform or not.