Engineering
Hands-on development across frontend, backend, databases and integrations.
Meru TechnoSoft Private Limited ● Current chapter
Professional experience / 2025 — present
My journey at Meru TechnoSoft has taken me from hands-on software development to product engineering, client-facing solutions and technical leadership across HelloBooks.ai and HelloGrowthCRM.
The throughline
When I joined Meru TechnoSoft, my responsibilities were primarily focused on software development. As the products became more complex, users began interacting with them, clients brought real-world requirements and the engineering team grew. My role expanded along with that journey.
Hands-on development across frontend, backend, databases and integrations.
Understanding requirements, workflows, product gaps and user experience.
Demos, onboarding, requirement discovery and solution mapping.
Third-party APIs, payments, subscriptions, webhooks and external services.
Coordinating and guiding 8+ junior engineers while staying close to the work.
Planning, assigning, following up, debugging and shipping features.
Nine turning points
The title changed less than the questions did. Each stage widened the surface area I was responsible for understanding.
The foundation
Before building the CRM, I learned how to work inside an established accounting product.
For approximately one year, I worked as a junior developer on HelloBooks.ai. Unlike a new product, it was already an established and complex system. I joined an existing engineering environment and had to understand its architecture, business logic, data flow, services, APIs, database relationships and development practices.
That taught me how to contribute to software with users, history and complexity. I also gained practical exposure to GST, billing, accounting workflows and financial transactions. Financial software requires care: accuracy, consistency, validation, edge cases and transaction correctness matter because small mistakes can have meaningful business consequences.
See the product contextThe main chapter
My work on HelloGrowthCRM began when the product was still in its early development stage. I worked on it from the beginning, including its initial implementation. At the earliest stage, another developer and I were responsible for core functionality and the shape of the initial product.
As functionality increased, HelloGrowthCRM moved from an early-stage software project toward a CRM platform used by real businesses. I stayed close to the implementation while the product, the customer context and the team around it grew.
Explore related projectsReality check
Real users changed the questions. Different clients brought different workflows, lead sources, existing software, automation requirements, integrations, reporting needs and expectations. Many requirements were not part of the original CRM.
“A feature isn't complete simply because the code works. It has to solve the user's actual problem.”
In the room
I don't simply demonstrate features. I try to understand how the client's business operates and map that workflow to the CRM.
From context to shipping
Some requirements could be solved with existing CRM functionality. Others needed new functionality, workflow changes, custom features, integrations, data connections, automation or payment functionality.
Where documentation ends
Working with real businesses means connecting the CRM with systems outside our control. I gained practical experience with Meta integrations, payment integrations, subscription handling, external software connections, REST APIs, authentication, webhooks and data synchronization.
Production introduces authentication problems, token expiry, webhook failures, unexpected payloads, API limitations, downtime, data mismatches, retry requirements and business-specific edge cases.
These challenges gave me practical experience solving production integration problems rather than only implementing API documentation.
Critical workflows
I remain hands-on with payment functionality, subscription handling, integration logic and critical backend workflows. These areas require careful attention to validation, error handling, data consistency, user states, edge cases and external service communication.
The mindset shift
My role became increasingly involved in UX/UI improvement, workflow improvement, feature planning, product gaps, edge cases, user feedback and product iteration.
A wider lens
I regularly participate in meetings with senior advisors and leadership who have experience across products and businesses. I explain how the CRM works, demonstrate features, discuss limitations and technical/product challenges, receive feedback and bring recommendations back into development.
“Product development isn't only about asking whether something can be built. It is also about asking whether it should be built and why.”
The team grew
As the CRM accumulated functionality and real-client requirements, the workload became too large for a small engineering team. I transitioned into technical leadership and team coordination while remaining hands-on. Today I coordinate and guide 8+ junior engineers.
junior engineers currently coordinated and guided
I didn't move from developer to manager by leaving engineering. My leadership responsibilities grew on top of my technical responsibilities.
Connecting three worlds
One of my current responsibilities is connecting these three worlds: understanding what the client needs, helping determine what the product should do, helping the engineering team understand what needs to be built and implementing technically important parts.
Business problems
Requirements
Feedback
↕Features
UX
Priorities
↕Architecture
Implementation
Delivery
This means communicating differently with clients, developers, senior advisors, the CEO/founder and leadership.
Current responsibilities
Core functionality
Payment functionality
Subscription handling
Third-party integrations
Automation
Production troubleshooting
Feature planning
Requirement analysis
Workflow design
Product gaps
UX/UI improvements
Feature prioritization
Product demos
Client onboarding
Requirement gathering
Client communication
Workflow analysis
Custom feature discussions
8+ junior engineers
Task allocation
Daily follow-ups
Technical guidance
Blocker resolution
Feature delivery
CEO/founder reporting
Senior advisor discussions
Product improvement
Technical recommendations
Feature planning
The working environment
This is not a generic skill wall. These tools are part of the environments where I learned how products are built, connected, deployed and maintained.
Breadth through contrast
What I learned: Understanding existing systems, domain logic, service architecture, data accuracy and production environments.
What I learned: Building from early stages, product thinking, customer discovery, integrations, ownership and leadership.
The lasting lessons
A working implementation matters most when it improves the situation that asked for it.
Workflows become clearer, stranger and more valuable when they are attached to a real business.
The difficult work begins where documentation ends: states, failures, retries and mismatches.
The best technical choice is often the one that makes the whole workflow easier to understand.
Guidance is stronger when it comes from someone who is still close to implementation.
Context changes how you validate data, prioritize edge cases and communicate tradeoffs.
Feedback from production gives every next decision a sharper shape.
Responsibility, not a promotion ladder
These are not formal promotions. They are the responsibilities I gradually took on as the work, product and team around me changed.
The complete picture
My experience at Meru TechnoSoft changed the way I think about software engineering. I started by learning how to write and maintain software. Then I learned how products work. Then I learned how real businesses use those products. Then I learned how to translate business problems into technical solutions. And eventually, I began helping other engineers build those solutions.
I am still deeply interested in engineering, but I now understand that good software is not created by code alone. It comes from understanding the problem, the people using it, the business behind it and the team building it.
I started with code.
The product taught me to think.
Users taught me to listen.
Clients taught me to understand business.
Integrations taught me to solve problems I couldn't control.
The team taught me to lead.
Continue the story
Explore the work behind the experience, or start a conversation about a product that needs thoughtful engineering.