For a long time, I saw research as something separate from professional software development.
I thought research belonged to laboratories, journals, and universities, while development belonged to code editors, production servers, client requirements, bugs, deadlines, and real users.
Over the last few years, that idea changed.
As a software developer, I have worked across frontend development, backend APIs, IoT integrations, RFID workflows, cloud deployments, databases, automation, and enterprise systems. I have seen how a small technical decision can affect reliability, cost, scalability, usability, and sometimes an entire business workflow.
That experience is one of the main reasons I am preparing to begin my PhD journey.
This is not a post announcing that I have already been admitted. It is a record of the journey before admission: why I want to pursue research, what I have learned so far, and the kind of problems I hope to solve.
From Learning Technology to Building Systems
My journey started with curiosity.
I was interested in computers, software, hardware, automation, and the idea that technology could solve practical problems. Over time, that curiosity became hands-on work. I moved from learning programming concepts to building applications, APIs, dashboards, integrations, and device-connected systems.
Working in software made me realise that real-world systems are rarely simple.
A project may begin as a dashboard, but soon it involves authentication, databases, deployment, performance, logging, device reliability, user experience, communication protocols, and support for unexpected failures. An IoT project may look like a hardware problem, but in practice it also becomes a backend, cloud, data, security, and operations problem.
I started enjoying this intersection: where software meets the physical world, business workflows, and practical constraints.
Why a PhD Now?
A PhD is not just a degree for me.
I want it to be a structured way to study problems that I have already seen in practical development work. I do not want research that stays only inside a document. I want to work on research that can become a usable framework, a prototype, an open-source contribution, an implementation model, a patent-worthy idea, or even a product in the future.
My interest is in applied Computer Science research, especially around:
- RFID-enabled systems
- IoT and connected devices
- Open-source ERP platforms
- Artificial intelligence and automation
- Inventory optimization
- SME digital transformation
- Reliable enterprise software systems
The direction I am currently exploring is:
AI-Driven RFID Enabled Inventory Optimization Framework Using ERPNext for Small and Medium Enterprises
This topic connects strongly with the kind of systems I enjoy building. It brings together RFID-based tracking, ERPNext workflows, inventory intelligence, real-time data, automation, and decision support for small and medium businesses.
Many SMEs still manage inventory through manual entries, spreadsheets, disconnected software, or delayed updates. These methods can lead to stock mismatches, missing assets, poor visibility, unnecessary purchases, and operational delays.
I want to explore whether an integrated RFID and ERP framework, supported by intelligent analytics, can make inventory management more accurate, affordable, and practical for smaller organisations.
The Gap Between Theory and Deployment
One thing I have learned from development is that a system is not successful just because it works in a demo.
A useful solution must be reliable. It must handle real users, real devices, inconsistent networks, incomplete data, maintenance challenges, cost limitations, and changing requirements.
That is where I believe my industry experience can support my research journey.
I have worked with technologies such as FastAPI, React, PostgreSQL, MQTT, ESP32-based devices, RFID readers, ERPNext, cloud deployments, automation tools, and monitoring systems. These experiences have shown me the difference between an idea and an implementation.
Research can identify a model. Engineering can make that model usable.
My goal is to work at that intersection.
What I Hope to Learn
I know a PhD will demand much more than technical implementation.
It will require reading deeply, understanding existing work, identifying genuine research gaps, designing experiments, documenting methods, validating results, writing clearly, handling criticism, and staying consistent for years.
That is exactly why I want to begin this journey.
I want to develop stronger research discipline. I want to learn how to ask better questions instead of only building faster solutions. I want to understand how to prove whether an approach is useful, scalable, and meaningful.
Most importantly, I want to create work that has value beyond one project or one company.
Building in Public
I also want to document this journey publicly.
Not every detail will be shared, especially where research confidentiality, employer work, or unpublished findings are involved. But I want to share what I learn about:
- Selecting and refining a research topic
- Preparing for PhD admission
- Reading research papers effectively
- Identifying practical research gaps
- Building prototypes and proof-of-concepts
- Combining industry work with academic research
- Mistakes, challenges, and lessons along the way
- Open-source tools, ERP systems, IoT, RFID, and applied AI
This blog will become my record of growth - from a developer who builds systems to a researcher who studies, validates, and improves them.
The Journey Starts Before Admission
The PhD journey does not begin on the first day in a classroom or research lab.
It begins earlier: with curiosity, preparation, uncertainty, reading, planning, and the decision to take a difficult problem seriously.
I am still at the beginning. There are many things I need to learn, refine, and prove.
But I am excited about the direction.
My goal is simple: to build practical research that helps organisations adopt better technology, improves real workflows, and connects academic knowledge with real-world engineering.
This is the beginning of that journey.