My résumé stopped being a list of technologies, and conversations changed
For years, my developer resume described every job with a variation of the same sentence: "Developed web applications using React, Node.js, and PostgreSQL". It's correct information and completely useless. Any developer with two years of experience can write that same sentence, whether they did brilliant work or mediocre work.
Why that sentence says nothing
The problem isn't the grammar, it's what's missing. It doesn't say what problem got solved, nor what decision I specifically made, nor what happened as a result. A recruiter reading that line can't tell me apart from a hundred other résumés saying the exact same thing with the same three technologies.
Technologies are interchangeable. What isn't interchangeable is the judgement I used to choose them and the problem I solved with them.
The concrete change
I used to write "Developed a SaaS platform with Next.js and Supabase". Now I write something closer to this: "Built GymSmartAccess from scratch, a platform that handles billing and access control for independent gyms in Argentina. I owned the architecture, the interface design, and the production deployment. It's live with paying customers, iterating on real feedback".
The difference isn't length. The second version answers three questions the first doesn't even raise: what problem did I solve, what did I specifically decide, and what evidence is there that it worked.
The three questions I apply to every developer resume line
What decision did I make, not what technology did I use? "Chose Mercado Pago for recurring payments over Stripe, because the target market pays in Argentine pesos" says more about my judgement than "integrated Mercado Pago".
What's the evidence of the outcome? Not just any outcome counts. A specific number, a verifiable state ("live in production with real customers"), something that isn't just my word.
Does this set me apart, or could anyone write it? If the sentence would work equally well describing someone else's work on a different project, I rewrite it until it's specific to what I actually did.
A before-and-after example, side by side
Before: "Developed web applications using full-stack technologies, including backend services with Ruby on Rails and frontend frameworks like React.js, working closely with cross-functional teams."
After: "I build end-to-end solutions where code and design are considered together from the start. I choose the stack per project, set up CI/CD pipelines, and integrate user experience from the prototyping stage rather than as a layer added at the end."
The first version is a list of nouns. The second tells how I think about the work. That's exactly what a recruiter — or a client evaluating whether to hire me — can't see by looking only at the technology names. It's also what an applicant tracking system doesn't filter by keyword, and where a real person does stop to read.
Why this matters more for a profile like mine
A profile that combines development and UX/UI design is easy to reduce to two separate disciplines: "I can code" plus "I can design". That reduction loses exactly what makes the combination valuable. What's valuable is how one discipline informs the other in real decisions: choosing a stack while thinking about business constraints, or designing an interface already knowing how it will be implemented.
Telling that requires longer sentences than a list of technologies. But it's the only way the combination actually shows, instead of reading as two generic skills placed side by side. The same applies to portfolio projects.
The result, without overstating it
I have no precise way to measure how much this changed recruiter responses: it isn't a controlled experiment. What I can say is that the conversations that followed started differently. People asked about the specific decisions I mentioned. They stopped asking me to "tell them more about my React experience", which is the question the old version used to generate.
Keep reading
- How I design an interface from scratch: my complete UX/UI processThe five stages I work through before calling an interface finished, with real numbers from the redesign I did for Argentina's largest tech retailer.
- From Figma to production: my process for not losing anything in translationDesigning and coding the same product changes the order of decisions. How I organize the path from a Figma file to real components, without the friction of two people passing a file back and forth.