This is the first article in a series about building my product from the ground up — not just the code, but the decisions, doubts, mistakes, conversations, and lessons behind it.
What would you do if you are working as an IT person with various projects under your belt, when you constantly feel that things could have been done better?
Sometimes it’s a technical improvement, sometimes it’s a business workflow. You see the solution clearly. But you can't do much about it because you are "just" a software engineer, a team lead, or maybe an architect who has to work under rigid constraints. You discuss things, you pitch the changes, but then the stakeholders reject your ideas for improvement.
After a long time of working for others, you reach a point where you feel: maybe it's time I do things for myself. Maybe it’s time to showcase something that is better, simply because it is built exactly like how you would like it to be.
If that is so, then perhaps you should read on. That is exactly what I'm going to share with you: the story of my project.
A few years ago, I was designing a major system modernization. We migrated a legacy platform into a clean, decoupled microservices architecture. For months, the execution was flawless. The engineering team was hitting every milestone, the boundaries were clean, and the data isolation was textbook perfect.
Then came the deployment. Shortly after going live, business-level stakeholders intervened with a massive list of "pivots." They forced design changes that completely shattered our domain boundaries. Suddenly, services were chopped in half, data datasets were leaking across boundaries, and the clean architecture was forced into a tangled web just to meet a non-technical checklist. I raised concerns, but as a consultant, my job was to advise, not to dictate. The constraints won.
That was the exact moment a colleague turned to me and said, "You have the experience. Why don’t you build something of your own, where you control the blueprint?"
It was a powerful thought, but the reality of the software business hit me immediately. Where would the investment come from? What would I even build? In the real world, software doesn't sell just because the code is organized or well-maintained; it sells because of marketing, funding, and branding. Looking at a saturated market full of existing tools, I convinced myself that the hurdles were too high. I gave up before I even started, telling myself it was too much noise for a market that didn't need another tool.
Yet, the thought lingered.
During my time as a consultant, I crossed paths with a support agent for a specific online platform. Technical support was far from his true expertise; he was a salesman in his mid-50s who had been laid off, and online support was simply his survival option. His entire career had been spent as a high-level sales executive for a supply chain management consultancy. His job had been to evaluate enterprise needs and recommend heavyweights like Salesforce or SAP.
Because he deeply missed the career he excelled in, he often shared his past experiences with me. An interesting person becomes truly fascinating when you are actively learning from them, and it was through his nostalgic stories that the first seed was planted: perhaps there was a need to build something better for supply chains.
That seed stayed dormant until two years ago, when an unexpected visit brought it back to life.
An old friend of mine, an accountant at a company where I had previously consulted, came to see me. He, too, had recently lost his job during a brutal round of corporate downsizing. He had a family to support, and I did my best to offer comfort. Luckily, he found a new role a few months later, a vendor who imported goods for the local market. It hit me right then—he was working directly in the supply chain. During one of our catch-ups, he sighed and remarked, "You know, the company I’m working for now... they use basic spreadsheets to maintain all their accounts and everything."
"Did you advise them to switch to an actual software solution?" I asked.
"Not sure," he replied then asked, "Why don't you build me something that helps me manage accounts?"
I laughed. "Me? There are thousands of accounting solutions out there already. Why don't you just use one of them?"
"Well, yes," he countered, "but I'm sure you could build something better. You have the actual field experience."
His words instantly triggered the memory of my former sales colleague. Still, the developer in me was skeptical. "My field is actually different, but even if I do, Who is actually going to use it?" I asked, confident that the idea was a dead end.
"myself," he said proudly.
"Will management even allow you to change the way they work now?" I asked. I was certain a newly hired, mid-level finance person wouldn't have the authority to pivot a company's software strategy.
"Leave that to me. In fact, there are many other professionals just like me who desperately need this exact thing," he said with absolute certainty.
"Who exactly?" I inquired.
He looked at me and said, "You would know if you were serious. But if you are, build something better. I can share my experiences to help you do it."
I didn't give it much thought. I had my own reasons and his idea seemed emotional
A month later, my friend called and asked me to accompany him to a meeting with a small business owner who wanted a similar solution.
"Why?" I was completely puzzled.
"Why not?" he replied, looking excited. "You asked me who would actually be interested in using this. Here is your answer."
"What? But there is nothing that even remotely resembles a solution," I argued. "It would just be a discussion over a cup of tea."
"Well, then you have nothing to lose!" he said calmly.
So, we met this business owner. He ran a small company and desperately wanted a tool to manage his cash flow, specifically so he wouldn't have to hire an expensive third party just to prepare his tax returns, or scramble to fill in financial gaps at the end of the year because of missing paperwork. He told me the existing online solutions were either far too complex or looked childish. He wanted a system he could actually manage—something that his highly knowledgeable accountant and he, with much less financial knowledge, could understand and use at the exact same time.
I sat there thinking, Man, interesting idea but difficult execution!
On the way back, my friend turned to me and asked if this was finally motivating enough for me to build something. I could feel the genuine enthusiasm in his tone.
For the first time, I didn't make excuses. I started looking at my day-to-day schedule, calculating how I could carve out the time to make this real.
That was how my project was born. At that point, I still didn’t have a product, a roadmap, or even full confidence that the idea made sense. What I had was a recurring signal: real people with real operational problems were asking for something simpler, clearer, and more practical than the tools they already knew.
In the next part, I’ll share how that vague idea turned into an actual product direction