Career journey
Experience that compounds.
My experience spans full stack development, Laravel and PHP backend work, CRM and LMS products, lending workflows, APIs and production operations.
- Promfly Team — Full Stack Web Developer (Full-time, 20 Apr 2026–Present): SpeakMint AI voice conversations, interview practice, LMS courses and verified Razorpay subscription workflows.
- TRENITY Consultant, Mohali — Backend Laravel/PHP Developer (Full-time, 01 Dec 2025–11 Apr 2026): 15+ CRM modules, sales and support workflows; 45% database performance improvement; payment, email and SMS integrations.
- Megma IT Pvt. Ltd., Bhopal — Laravel Developer (Full-time, 03 Mar–30 Nov 2025): LMS serving 100,000+ users with 12 roles, 50% database performance improvement, response time below 200 ms, 60% less manual EMI processing and 10,000+ monthly Razorpay transactions.
- Edu Care ERP, Remote — Full Stack Developer (Full-time, 11 Jul 2023–28 Feb 2025): 50% reporting efficiency improvement, 40% faster REST API response (450 ms to 270 ms), JWT authentication and WordPress customisations.
- Inno grove Technology, Patna — Laravel Developer Intern (Full-time, 07 Jan–30 Jun 2023): 10+ CRUD modules, 30% performance improvement, validation and error handling.
01 / A CLOSER LOOK
Understand the career progression
The experience timeline covers internship, backend and full stack work across several organisations. The supplied resume documents CRUD development, query improvements, operational reports, role-based applications and external integrations. The emphasis changes between roles, so the useful comparison is the responsibility, the surrounding workflow and the outcome recorded for that specific position.
For a recruiter, the timeline is a starting point for questions about ownership and collaboration. A developer may contribute to a larger product without owning its entire infrastructure or business operation. I welcome a discussion around a particular module, the decisions behind it and the work that connected it to the rest of an application. The original resume remains available alongside these explanations.
02 / A CLOSER LOOK
Read the evidence in context
A project description, a public website and a source repository each answer a different question. The description explains the problem and contribution; a website shows its current public experience; a repository exposes the code that has actually been published. A screenshot is a captured view, while a conceptual illustration explains an idea. Those distinctions remain visible throughout this portfolio.
Performance figures belong to the employer, product and time period where they were documented. A platform user count should not be read as a personal customer count, and a result from one application should not be transferred to another case study. When a detail is unavailable, a discussion can establish what can be demonstrated without exposing confidential accounts, customer records or credentials.
03 / A CLOSER LOOK
Business rules behind the interface
A backend connects a user action to the rules that determine what is allowed and what should be saved. For a CRM record, that might include the required fields, the permitted status changes and the organisation that owns the record. For a learning application it may include enrolment, access and the relationship between a lesson and recorded progress.
Separating request handling from reusable application logic makes those decisions easier to understand and review. Validation should explain why input cannot be accepted, while authorisation decides whether the current user may perform the action at all. A practical backend discussion therefore starts with examples of the business process and the existing data model, rather than choosing a framework before the workflow is understood.
04 / A CLOSER LOOK
Make operational state understandable
Business software is useful when people can tell what needs attention. A lead, task, invoice or learning activity should have a state that means something to the people using it. Ownership, timestamps and linked records help explain who is responsible and why a record appears in a particular list.
Reports should follow those definitions so that a total has an understandable meaning. A dashboard number is less useful if users cannot tell which records it includes or how recent they are. Exports and bulk actions also need access rules and validation, because they can affect many records at once. The relevant case studies describe documented workflows; sample explanations on this page are not live customer data or a claim about current business activity.
05 / A CLOSER LOOK
Collaboration with clear context
A productive handover starts with shared language. The same word can mean different things to a salesperson, a learner and an administrator, so examples of real tasks are more useful than broad labels alone. A short walkthrough of the current process can reveal where information is copied, where permissions differ and where a person needs feedback before continuing.
I prefer discussing work through concrete requirements and reviewable changes. A request can describe the current behaviour, the desired behaviour and one example that demonstrates the difference. That makes it easier to compare an implementation with the original goal. Questions about responsibilities, communication and review timing can then be agreed around the actual project rather than assumed in advance.
06 / A CLOSER LOOK
Review the complete journey
A screen can appear correct while the underlying workflow is incomplete. A useful review follows a record from its first creation through validation, persistence, reload, later edits and any linked action. It also checks what happens when a field is missing, an external service fails or a user attempts an action that their role does not permit.
The depth of testing should match the consequence of a mistake. An informational layout needs readable content and working navigation; a payment or permission change needs closer checks around state and access. Review notes should make the expected result visible, explain the conditions used and distinguish a verified outcome from a limitation that still needs attention. This is a review approach, not a claim that every historical project has identical test coverage.
07 / A CLOSER LOOK
Make the next step understandable
A useful delivery includes enough context for the next person to operate the result. That can mean a short explanation of a workflow, where configuration belongs, how a record is managed or which external service is responsible for a particular result. Documentation should describe the application as it is delivered, including anything that remains outside the agreed scope.
Ongoing work may include content changes, bug fixes, performance reviews or new requirements after real use. Those are easier to discuss when the original boundaries and known limitations are recorded. Source access, hosting responsibilities, credentials and support arrangements should be agreed directly for the engagement; the presence of a public project link does not imply permission to access its private administration area.
08 / A CLOSER LOOK
Use the resume alongside the case studies
The original PDF is the reference for the professional timeline, education and experience figures shown on this site. The website gives those entries more room for explanation and provides links to public products where available. Reading both helps distinguish a concise resume claim from the context of the application and the role behind it.
For a hiring discussion, identify the responsibilities you need: backend ownership, API integration, interface delivery or work on an established business system. The most relevant example may sit in a different industry but involve a similar engineering problem. Dates, employment details and qualifications should be checked through the normal recruitment process. This page adds reading context and a practical discussion guide, not new employers, certificates or unsupported claims.