Semres and FightStats belong to very different worlds.
Semres is software for moving companies. FightStats is a project in detailed fight analysis. One deals with customer communication and business operations; the other asks what becomes visible when you describe a fight more precisely.
What connects them for me is an interest in how the structure of information changes what you can understand and build.
A product is full of decisions about what matters. The fields you collect, the events you recognize, the distinctions you preserve, and the things you make easy to see all shape the user's experience.
Those decisions begin well before the interface looks finished.
The model decides which questions you can ask
Broad fight statistics can summarize an outcome. More detailed action data lets you examine differences inside those totals.
A strike can be broken down by its form and target. A takedown can be described by how it happened. Once those distinctions are stored consistently, they become available for analysis.
That is the attraction of FightStats to me: finding a way to represent the underlying action with enough detail to ask more useful questions.
The same principle appears in business software.
“Customer” is a broad label. Where is this person in the process? What happened most recently? What are they waiting for? Which relationship brought them to the company?
If the system cannot distinguish those situations, the team has to supply the distinction from memory or another tool.
Different inputs need a consistent meaning
Semres connects moving-company CRM information with communication and growth workflows.
Different systems can describe the same operational event differently. To build repeatable workflows, you need a useful shared meaning for those events and the facts attached to them.
Once that meaning is clear, a product can respond consistently without requiring every customer to become a custom software project.
I find that decision interesting because it is both technical and commercial. The model affects how easy the product is to extend, and the ability to extend it affects the business behind it.
A founder deciding how information should fit together is also deciding something about the company's capacity to grow.
More detail has to earn its place
It would be easy to make the lesson “collect more data.”
I do not think that is enough.
Every additional distinction creates work. Somebody or something has to capture it, validate it, maintain it, and make it useful.
The question is what that detail allows you to understand or do.
For fight analysis, a distinction may help you examine a specific pattern. For a moving-company workflow, it may determine whether a customer needs a reminder or whether a partner should receive an update.
If the detail does not affect a useful question or action, it can become a distraction.
That is a product judgment. You need enough information to support the use case and enough restraint to keep the product understandable.
The interface should expose the useful decision
A technically interesting model still needs a useful experience.
The user should be able to find the information that matters, understand what it means, and do something with it.
In business software, that might mean seeing which records need attention or which relationships are producing activity. In an analysis tool, it might mean being able to examine a particular pattern without reconstructing the dataset yourself.
The interface is where your assumptions meet another person's task.
It is also where you find out whether the detail you cared about is helping the user or merely impressing the builder.
AI makes those decisions more consequential
I use AI extensively. It can accelerate implementation and help explore possibilities.
It still needs a clear description of the system you want. If you have not decided what an event means, what a user should see, or which information deserves to exist, faster implementation can make your uncertainty more permanent.
This is why I care about judgment as much as output.
Being able to generate a screen is useful. Being able to explain why that screen exists, what it depends on, and how you know it works is the responsibility I want to carry.
A product should reveal how its builder thinks
When someone looks at Semres or FightStats, I want them to see more than a list of technologies.
I want them to see curiosity about the underlying problem, a willingness to describe it carefully, and an attempt to build something that makes another question or action possible.
That is also how I want someone to evaluate me for a new engagement.
The work is evidence. Look at the decisions inside it. Ask why I made them, what they allow, and what I would change as I learn more.
Those conversations tell you far more about a builder than a title can.