I like starting things.
A new product idea gives me an excuse to learn a market, sketch a system, and see how quickly I can make it real. Over the years, that curiosity has taken me through mobile apps, ecommerce, cloud infrastructure, AI, security, factory operations, and real estate.
It has been useful. I can move between product questions and technical details without treating them as separate worlds.
It has also left me with a problem: too many directions can feel reasonable at the same time.
Starting is the easy part
The beginning of a project is generous. Progress is visible. There is a blank repository, a clean architecture, and a long list of possibilities. A few focused days can produce something that looks promising.
Staying with a project is different.
The work becomes repetitive. Customers do not describe their needs in neat requirements. The first version has awkward edges. Distribution moves more slowly than development. You have to ask people to pay, hear no, fix details nobody will celebrate, and come back the next morning.
I have often been more comfortable with the certainty of building than with the uncertainty of selling. Code gives a clear response. A customer can like an idea and still never use it.
That difference matters. A collection of good starts is not the same thing as a body of work.
What Sojago asks from me
Sojago is software for rental agencies. It handles properties, tenants, rent, unpaid balances, receipts, expenses, commissions, and owner accounts.
The engineering is demanding, but it is not the main reason I am choosing to stay with it.
Sojago puts me in front of questions I cannot solve from a code editor. Will an agency trust the numbers? Will the team stop relying on its old spreadsheet? Can I make onboarding simple enough? Is the problem urgent enough for someone to pay? Can the price support the help customers need?
Those are uncomfortable questions. They are also the questions that will teach me whether I am building a business or only a capable product.
Preparation has a limit
I enjoy improving the system around the work. I can refine an interview guide, reorganize a roadmap, strengthen the infrastructure, or rewrite a sales page. Each task can be useful.
Each one can also delay a direct test.
An imperfect message sent to an agency today may teach me more than a perfect outreach system finished next month. A real onboarding session will expose assumptions that another architecture review will not. Asking for payment is clearer than asking whether the idea sounds interesting.
I am trying to notice when preparation reduces a real risk and when it simply protects me from an answer.
The focus I want
I am not trying to become less curious. I want curiosity to support a direction instead of replacing one.
For now, that direction is practical software for businesses with complicated day-to-day operations. Sojago is where I am learning the work. Employment or selective consulting can support income and keep my skills sharp. Writing helps me slow down and name what I am seeing.
Other ideas can wait. Saving an idea for later is not the same as rejecting it.
The commitment is simple: give Sojago a fair test with real agency data, regular use, direct customer conversations, completed monthly work, and a clear request for payment. If the evidence says the direction is wrong, I can change it. I just do not want boredom to make that decision for me.
That is what focus means for me right now: staying long enough to get an honest answer.