In this talk, I address the direct value or user research for small teams. It illustrates how much money, developmental effort and time a remote team had lost without a proper research process. In 2013 I was working on an RSS-reader: a personal project that quickly grew to six digits daily active users. Five years later, I look back, reflecting on the research-related mistakes and outlining what lightweight and budget-friendly methods could have flipped the table, including approaches to planning, organising and running research. The importance of following a user-centered design approach has been declared over 53 million times on the internet, according to Google Search results. However, in practice, small teams may not have the resources, and often lack a dedicated researcher or the luxury of proper budgets, so the research becomes a lesser priority compared to the delivery side of projects. This creates sets of problems, where teams are losing money, waste limited developmental efforts and are often unable to evaluate their work on a larger scale. In 2013 I was working on an RSS-reader: a personal project that quickly grew to six digits daily active users. We did not follow a proper research process and because of that made some seriously bad mistakes and decisions. This talk lists the core ones and outlines what lightweight and budget-friendly methods could have dramatically change the situation, including approaches and advice on planning, organising, running and presenting research along with the advice for developers and engineers. Since the topic of "Should designers code" has been hotly debated in the past couple of years, maybe it is time for discussion around "Should developers research" and arguments for (and against!) non-UX-people being involved in traditional UX activities. This talk covers: - The direct value of (not) doing research - Planning, organising and running lightweight discovery and evaluation activities - Introducing research to non-UX people