01
Start from the problem, not from the feature list
Technology comes later. First we need to understand what is actually broken, slow or unclear.
Build things that have a reason to exist.
What matters to me is not simply finishing something, but understanding the value of the work itself, what it solves and why it deserves to exist. I do not like the feeling of putting real effort into something only to end up with an outcome that leaves behind no meaningful value.
Core background
Born in 1999, I previously worked as a software engineer at larger companies such as Groove Technology and Nissan Automotive Technology before moving into independent work.
How I work
Each project may be different, but the way I enter a problem tends to stay fairly consistent.
02
Align scope and working rhythm early
Once the problem is clear, the next thing I want to clarify is what needs to be done first, what can wait, and what kind of working rhythm makes sense for both sides. When the scope is clear, the work becomes much less messy.
03
Communicate closely, transparently, and continuously
Every discussion should create concrete progress. I prefer updates that are concise, focused, and aimed directly at the decisions that need to be made, so both sides can save time. If I feel a direction is not strong enough, I would rather say it early than let things drift too far before correcting them.
04
Keep the technical side strong enough for the long run
I am not interested in building something that only works for a demo. If it gets built, I want the technical foundation, processing flow and scalability to be stable enough that the project does not later turn into avoidable rework.