About me
Last updated
On this page
I'm Manish Singh, a computer science graduate from Madhya Pradesh, currently building my career around data, AI, automation and software. My journey hasn't been a straight line, and that's probably one of the most important things to know about me.
I grew up in Umaria, Madhya Pradesh, a relatively small town, and later moved to Hyderabad for work. I studied Computer Science and gradually found myself drawn less toward simply writing code and more toward understanding how technology can solve real problems for people and businesses. That curiosity has taken me through data analytics, Python, SQL, Power BI, automation, web development, AI, data engineering and, increasingly, the process of turning ideas into actual products.
I'm someone who tends to think in terms of systems. When I encounter a repetitive process, a messy spreadsheet, information scattered across emails, or a problem that requires people to keep doing the same thing manually, my first instinct is usually:
"Can this be turned into a system?"
That way of thinking led to one of the biggest projects I've worked on: Trinetra. It started from a very practical problem inside a manufacturing environment, where important operational information was spread across large Excel workbooks, trackers, emails and departmental processes. I built a web-based system to bring workflows, reporting, procurement, production, warehouse, quality, maintenance and related activities into a more centralized digital process. Working on it taught me something that tutorials and courses never could: building software is only one part of solving a problem. Understanding the people, processes, constraints and business context is just as important.
That experience changed the way I think about technology.
I'm also very interested in AI as a tool for building things, not just as something to talk about. The recent generation of AI coding and development tools has changed the economics of experimentation. A person with a computer, an internet connection and enough technical understanding can now prototype ideas that previously would have required a team. So I'm experimenting with that myself. Some of those experiments may work. Most probably won't. I'm comfortable with that.
What matters to me is learning why something worked or didn't work.
I like building, but I also like understanding
I enjoy exploring data, financial markets, business models, productivity systems, technology, strategy, games, maps, cycling, hiking and new tools . I can spend a lot of time going down a rabbit hole when I find a subject interesting, trying to understand not just what something is, but why it works, where it breaks, and whether it can be improved.
That has taught me an important lesson:
An idea is not an asset until reality proves that someone values it.
Building something is easy compared with getting someone to use it. Getting someone to use it is easier than getting them to come back. And getting someone to actually pay for it is harder still.
Why I build things
I want to build things that remove friction: turning a complicated spreadsheet process into a web application, transforming messy data into something understandable, automating repetitive reporting, or taking an idea that exists only in someone's head and turning it into something people can actually use.
The technology changes. The underlying idea doesn't:
Take something complicated and make it more useful.
The process before the result
I don't have everything figured out. A lot of technology content is written from the perspective of someone who has already succeeded. What interests me more is the process before the result: the ugly prototype, the feature that nobody uses, the experiment that fails, the business idea that seemed brilliant until real users tried it.
Those are the things I learn the most from, and this website is where I document them.
What you'll find here
AI
How I use AI tools to learn, build, automate and experiment, and where the technology is genuinely useful versus where the hype gets ahead of reality.
Tech
The tools, architectures, development approaches and engineering lessons I encounter while building things, including data: analytics, data engineering, SQL, Python, business intelligence and the practical side of turning raw information into decisions.
Games
Not only playing them, but understanding the systems, mechanics and design decisions behind them.
Systems
How repetitive processes can be redesigned using software, workflows, APIs and automation, and what building products teaches: prototypes, user feedback, failures, pricing, and the uncomfortable gap between building something and building something people want.
Ideas
Anything else that I find genuinely interesting enough to investigate, understand and explain.
One principle I'm trying to follow
I don't want to pretend I know the answer before I test the idea. So my approach is becoming:
Learn → Build → Launch → Measure → Understand → Improve → Repeat.
Not every experiment will become a business. Not every project will succeed. Not every technology will live up to the hype. That's okay. The goal is to keep learning fast enough, building enough, and paying enough attention to reality that eventually something compounds.
— Manish Singh