← tech

listening to users is just as important as coding | commits of the week #1

  • tools

friday the thirteenth, my 35th birthday, i decided to start this newsletter to share the day-to-day of software development in the tech whirlwind that is 2026.

here i hope to be a comforting hug to newer devs and a helping hand to non-technical folks (:

in this first issue, i present the main project i'm working on and leave some cool links i saw throughout the week.

today we're going to talk about: product discovery, user interviews, and ubiquitous language.

Let's go!

__

Mono Repo

The main project right now.

I'm building a Software as a Service (SaaS) to make buying real estate at auction easier in Brazil, for now it's called: leilaonomapa.com

Product discovery: before coding, understand who it's for

One tip I can give to anyone wanting to build their own software: before anything else, do some product discovery. In the world of product management, there is a methodology called Product Backlog Building (PBB) that structures this very well. The core idea is: start from the problem and the impact on the user before getting into the technical details.

In practice, this starts with a simple question: who are your users?

In my case, the user could be:

  • auctioneers wanting to advertise their auctions;
  • auction property investors;
  • lawyers or advisors specializing in auction buying and selling;
  • people buying their first property.

Notice that each of these people will use the platform differently, prioritizing different features. In PBB, they call this defining personas, and the point is that when you look at the product from the perspective of the person actually using it, your mindset shifts. You stop thinking only about technical implementation and start caring about the actual experience.

understanding the process inside the user's head

At first, I created a process flow for searching, selecting, analyzing, and purchasing auction real estate based on a course in the field and by analyzing my "competitors."

It's not enough.

Doing interviews with potential users is essential. That's where you discover blind spots in the market — and for a SaaS, that's crucial, especially if we apply what Marc Lou suggests: start with a simple software that solves just one pain point, without throwing in a thousand things right off the bat. (I'm not doing that very well... but anyway lol)

That's the heart of PBB: identifying the real problem before defining features. Instead of just jumping into coding an unorganized list of features, you map out problems, expectations, and personas, and features emerge with a clear reason to exist.

the biggest insight i've had so far

... came from interviewing an auctioneer. how did i find an auctioneer?! by sending lots of messages, every day, via linkedin, instagram, and whatsapp, talking to different people who guide me to other contacts. that's the hard road lol

Well, he said the biggest difficulty in the process is that when the documentation (the legal analysis) is very complicated, there's a back-and-forth: you have to see how much legal clearance will cost, add it to the commercial analysis, and only then know if it's worth it

(BPMN) High-level, simplified flow of buying real estate at auction

He said that every case is different.

And my curiosity right now is: is it really?

Having worked with corporate automations for over 5 years, I've seen many cases where people considered a process hard to standardize and in the end it was completely automatable.

Speaking their language

One thing you'll notice doing interviews, people talk about the same step in the process, but in different ways:

in the case of leilaonomapa the auctioneer calls it "legal analysis", the investor uses more English terms and calls it "due diligence", but the lawyer will speak plain Portuguese: "documentary diligence".

This is a classic requirements engineering problem. If each persona uses a different term for the same concept, how do you model a system that serves everyone?

In Domain-Driven Design, by Eric Evans, this became the concept of ubiquitous language: creating a common vocabulary among everyone involved (devs, users, stakeholders) so the code reflects the real business domain, without translations getting lost along the way.

screen of the solution in development

In practice, for Leilão no Mapa, this means I have to decide: which term will the system adopt? It depends a lot on the customer I want to serve... it's good for this term to be understood by all parties, including a more novice buyer... so, I preferred to use "legal analysis".

__

Merge Conflict

discovering demand vs. creating demand

One objection to my own "methodology" is that argument popularized by Steve Jobs: people don't know what they need or want.

Kevin O'Leary (from Shark Tank) said that back in the 90s, when his company Softkey made educational software for Apple, Jobs told him something like "I don't care what the students want, they don't know what they want until I tell them what they want." [link]

You can build something and generate the desire to buy in them later.

This has been partly true in my experience, but it's a tension everyone who builds products faces. PBB solves this partially: it doesn't ask the user to say what they want as a solution, but rather to describe their problems and expectations.

The solution is built from there, at least the backlog comes out prioritized by value, not by guesswork... but yes, it is limited by the interviewees' perspective.

__

Other Branches

Links and references that caught my attention this week.

Until the next commit, Michelle (:

Mica Tech Studio