← back to work
case · 01 Nov 2024 — present

Orienta

Digital psychometric tests, an AI recommendation engine and continuous university scraping — all stitched together by an event-driven architecture that only spends compute on demand.

orienta.app ↗
Role
Full-Stack Developer
Period
Nov 2024 — present
Stack
TypeScript · Fastify · MongoDB · AWS · OpenAI / Gemini
image / screenshot · drop here

The problem

In Latin America, choosing what to study at 17 is still a gamble. Traditional psychometric tests hand you back a PDF with a list of compatible careers — useful, but static, with no context and no one to explain why.

The founding team came from educational psychology and already had the instrument, the data and the outcomes. What was missing was turning that into a product today’s student would actually use: digital, conversational, mobile-first, and that teaches rather than just recommends.

My role

I joined as Full-Stack Developer and sole technical lead. I decide stack, architecture, infrastructure costs, AI provider and data shape. I built the API from scratch and own the end-to-end cycle: backend, frontend and infrastructure.

The job isn’t just writing code. It’s translating what the psychometric team already knew into a system a 16-year-old can talk to at 11pm from a mid-range phone.

Technical decisions that matter

Event-driven instead of always-on. The initial version had a worker running 24/7 on an EC2 instance waiting for work. I rewrote it as an SQS + ECS Fargate architecture: compute only spins up when there’s a vocational analysis to generate. Operational cost dropped significantly and the system scales only under load.

AI pipeline with fallback. Gemini as the primary provider for cost and latency; OpenAI as backup when Gemini fails or returns invalid output. A 103-question wizard (14 thematic blocks) feeds the pipeline and generates 8 distinct vocational reports per student.

Fastify + TypeScript on MongoDB Atlas. REST API with DDD, JWT and clear domain separation. Fastify for its JSON Schema validation and because, at the current scale, its wins over Express are noticeable.

Production-grade SES. DKIM, SPF and DMARC configured from day one — because vocational emails landing in spam kill the product.

103
questions / wizard
14
thematic blocks
8
reports generated
↓ costo
vs. always-on

What didn’t work at first

The first version used a monolithic prompt — all the student’s information stuffed into the context at once. It worked for one report but broke when several had to be chained. I rewrote the flow as a pipeline with explicit provider fallback and structural validation at every step.

I also overestimated how quickly users would type in a chat. Most prefer buttons, sliders and micro-surveys. Today the wizard feels more like a guided conversation than a free-form chat — and that makes it usable on any phone.

What I learned

The most important technical decisions in an AI product aren’t about the model. They’re about what data enters the context, in what order, when to stop generating and ask for input, and what to do when the model fails. Frameworks handle the rest.

And working with a non-technical team forces you to defend every layer of complexity. There’s nothing like explaining to an educational psychologist why you need two weeks to refactor something invisible to discover you actually don’t.