Start with the problem, then choose the form
At Tomokichi Studio, I do not want to begin with “Let’s make an app” or “Let’s build a web service.”
I want to begin with a problem, a small friction, or a feeling that something in everyday life could work better.
“This is a little inconvenient.”
“Why do I have to do this every time?”
“I wish there were a simpler way.”
Those small observations are often where making something starts.
Problems are hidden in ordinary life
When we hear the word “problem,” it is easy to imagine a large social issue or something nobody has ever solved before.
But the problems Tomokichi Studio wants to notice are often much closer to home.
They can come from something I find inconvenient myself, something another person struggles with, or a moment when an existing service feels almost right but not quite.
Each one may be small. But there may be other people who feel the same thing.
So instead of letting that feeling pass, I want to ask:
Why does this feel inconvenient in the first place?
That is where the process begins.
Look at the difficulty, not just the requested feature
Once a problem is found, I do not want to jump straight to features.
Even if someone says, “I want this feature,” adding that exact feature may not be the real answer.
Why do they want it?
What are they actually trying to do?
Where does the current experience get in their way?
By going one level deeper, there may be a simpler and better way to solve the real problem.
Tomokichi Studio wants to start from what the person is actually trying to solve, not from what happens to be easy or interesting to build.
Do not decide the form before the solution
And the answer does not have to be an app.
It might be a website, a small tool, an automated workflow, or simply a better way to organise and present information.
What matters is not what was built. What matters is which form solves the problem most naturally.
If an app is the right answer, build an app.
If the web is a better fit, build it for the web.
If the problem can be solved without creating something new at all, that can be the right answer too.
Technology and format should come after the problem, not before it.
Build only what is needed
When thinking about a solution, I do not want to fill it with everything that could possibly be added.
More features do not automatically make something better.
The goal is for people to understand what to do without unnecessary friction and to accomplish what they came for naturally.
Everything that is needed should be there. Everything that is not needed should have a reason to stay out.
That kind of simplicity is what I want to aim for.
Take small frictions all the way to something useful
Find a problem. Understand what is really behind it. Think about the right solution. Give that solution the right form.
And then do not stop at making it — deliver it in a state where someone can actually use it.
That is the cycle Tomokichi Studio wants to keep repeating.
Notice a small friction in everyday life.
Understand the real problem underneath it.
Solve it in the form that fits best.
An app, a website, a tool, or something else entirely are all just possible means to that end.
Start with what needs to be solved, not with what we want to build.
That is how Tomokichi Studio wants to make things.