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.
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.
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.