I didn't start with a business plan.
I started with a strong feeling that I wanted to build my own path.
I studied Computer Science (BTech CSE). Technology genuinely interested me from the very start, but I never felt strongly drawn toward a predefined career path or the conventional corporate milestones laid out ahead.
From an early age, I held a stubborn belief that output, the ability to build, and the willingness to take risks mattered far more to me than conventional credentials or predefined measures of success.
That belief also had a clear downside: I underestimated the value of formal academics and fundamentals. My academic journey was not particularly strong, and I had to confront the limits of trying to move fast without deep roots.
Over time, I learned that building real, durable things isn't about shortcuts or pure willpower, it requires genuine depth, fundamentals, and quiet discipline.
The honest reality: I wasn't an outlier who effortlessly bypassed college; I was someone who wanted his own path and had to discover through direct trial and error where my early assumptions were wrong.
I had to build a few wrong things first.
The progression wasn't a neat career ladder. It was a sequence of collisions between what I thought would work and what reality demanded.
Computer Science & Engineering
CSE / The Starting PointTechnology interested me, but predefined tracks felt disconnected from building real things that people actually use.
AI & Resume SaaS
The First Product Attempt“My first attempt to turn AI and technology into something people might actually pay for.”
Websites & Freelancing
The Front-End Deliverables“I thought having a useful technical skill would be enough to create demand.”
Local Businesses & Hotels
Direct-Enquiry & Booking Systems“I started building booking and direct-enquiry systems, and got much closer to the real problem.”
Operational Systems
State Logic & Internal Workflows“I became more interested in what was happening underneath the visible product.”
The MicroSite
Systems-First Engineering“A company built around understanding that problem before deciding what technology belongs.”
“Each attempt narrowed the question.”
From "What can I code?" to "How does this business actually operate?"
Building taught me to look beyond what was visible.
I spent months speaking with hotel owners and staff, building booking systems, testing direct-enquiry flows, and trying to understand whether the technology actually solved something valuable.
That was when the real pattern became impossible to ignore: A booking system could work perfectly and still solve very little if the hotel didn't have the traffic, process, awareness, or internal conditions around it.
“What can I build?”
Focused on technical capability, tools & deliverables“What does this business actually need?”
Focused on operational reality, handoffs & human habitsGuests arrive from channels with high intent, but no attribution of what they specifically care about.
Inquiries land into a general inbox with zero categorization or automatic urgency routing.
Front desk is busy during check-ins; inquiries sit for 3 hours and go cold before anyone calls back.
Assuming a smooth UI guarantees checkout completion without immediate reassurance on WhatsApp.
Payment confirmation sits in an email while the kitchen and housekeeping have no synchronized record.
Eventually, I realised I wasn't really interested in websites.
Or booking engines.
Or automation for the sake of automation.
What kept pulling me back was the thing underneath them:
how a business actually works.
Two businesses can offer the exact same service and still need completely different digital infrastructure.
Because their people, responsibilities, approvals, information flows, decisions, exceptions, and operating habits are fundamentally different.
“The system should emerge from the business, not the other way around.”
* Technology appears last. It is only the physical execution layer of an already understood operation.
That's what The MicroSite became.
A place to turn that way of looking at businesses into something useful.
We start by understanding how work actually happens.
Then we simplify what doesn't need to be complicated.
Only after that do we decide what should be built, whether that's a workflow, automation, interface, integration, or something else entirely.
Messy Operational Reality
- Tools accumulated faster than process structure
- Handoffs relying entirely on human memory & chats
- Websites disconnected from the back-end operation
- Growth creating linear manual exhaustion
Working System Architecture
- Explicit state transitions and automated lead triage
- Clear boundary between machine logic and human judgment
- Interfaces serving as clean front-ends to backend infrastructure
- Operations that become calmer as volume expands
How does work actually happen?
We sit with the real operation - who touches what, where things get dropped, and what happens when an exception occurs.
What complexity can disappear?
Before adding software, remove redundant steps and fragile dependencies. Good architecture is subtractive.
What system actually belongs here?
Craft tailored infrastructure, workflows, interfaces, or automations, that fit the business like a glove.
“Technology has to earn its place.”
I'm still building the capability.
I haven't spent ten years building enterprise infrastructure.
I haven't worked with hundreds of companies.
I'm still early.
What I do have is a growing body of experiments, systems, conversations, failures, and observations, and a much clearer understanding of the kind of problems I want to spend my time solving.
- Businesses where the operation has become more complicated than it needs to be
- Companies where tools have accumulated faster than structure
- Workplaces where people are quietly holding a broken process together through manual stress
“I want to understand those businesses deeply, and build what actually belongs there.”
Testing wrong assumptions, building isolated tools, and discovering that software without operational context fails.
Systems emerge from human reality, not software features. The real leverage is making business operations clear and calm.
Resilient operational systems, tailored automation, and clear interfaces for service businesses ready for real infrastructure.