Case study · Formative work
Seven years live.
Hemaka was where web work stopped being one clean job title. The site I helped build in 2019 still feels current because its motion was designed around meaning, not novelty. The logo builds itself, illustrations respond to interaction, and each animation has a clear role. Beneath that personality is solid structure: production constraints, client needs, QA, support, and careful judgment, sometimes all part of the same day. That combination of character and technical care gives the site staying power.
The education was not abstract. React components, Meteor.js patterns, TypeScript decisions, Three.js experiments, animation details, layout problems, and browser issues all had to resolve into something a real person could use. That made the learning stick: concepts mattered only when they improved the shipped experience.
I learned to move between rough prototypes and careful implementation: testing motion timing, reading unfamiliar code, tracing bugs through the stack, and translating design ambition into maintainable frontend work across React, Meteor.js, TypeScript, and browser-native motion.
What it taught me
Hemaka made me faster because it made me broader. The work trained me to see a site as a system: React components, Meteor.js data flow, TypeScript guardrails, Three.js motion, copy, state, layout, deployment, and support all influencing each other. That is still how I diagnose and build websites now.
SVG, staggered motion, timing curves, and interaction that makes an interface feel intentional.
React, Meteor.js, TypeScript, state, routing, data flow, and the tradeoffs behind library choices.
Debugging what actually broke, reducing fragile code, and making decisions that survived launch.
Switching between engineer, designer, QA, client translator, and problem owner without losing the thread.
Hemaka was a school in itself: the place where I learned that the best web builders are part craftsperson, part systems thinker, and part calm problem solver.
Outcome
Hemaka was a place for ambitious browser work, but the rule was never chase the shiny object. Every tool had to earn its place in production. That is where the creativity came from: ingenuity inside constraints, not novelty for its own sake.
The lasting result was not one screen or one technology. It was a way of working: stay curious, understand the moving parts, make the browser do something precise, and keep the user experience intact when the work gets complicated.
What that means for your build: I have already made the expensive mistakes on someone else's timeline.
Build with that level of careBring the moving parts: animation, frontend, weird browser behavior, half-built flows, or a site that needs better judgment before launch. I will turn it into a practical plan and reply within a day.
hola@josefina.dev