About me
Curious by nature. Practical by design.
I’m Raju Kumar Raja, a full stack developer and backend engineer based in India with 3.8+ years of professional experience. I work across education products, lending workflows, CRM systems and AI learning products.
I enjoy understanding a problem from the data layer to the interface, then building software that people can use confidently. My work includes Laravel and PHP development, API integrations, payment workflows and deployment.
- Full stack web application development
- Laravel, PHP and CodeIgniter backends
- REST APIs and third-party integrations
- CRM, LMS and business workflows
01 / A CLOSER LOOK
A developer behind the work
My portfolio connects a professional profile with the systems described in my resume: learning products, business operations, APIs and the interfaces that make those systems useful. Reading the work in context matters more than treating a technology list as a promise that every project uses every tool. The project pages distinguish the product, the documented contribution and the available evidence.
I am based in New Delhi, India, and my published contact details are available for professional enquiries. For a role or a development project, the useful starting point is the problem you need solved, the people who will use the application and the constraints around delivery. That gives a conversation a concrete purpose before a framework, feature list or estimate is selected.
02 / 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.
03 / 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.
04 / A CLOSER LOOK
Learning through practical work
Computer Science and Engineering provides a foundation in data structures, databases, software design and the reasoning needed to break a problem into smaller parts. Practical development adds another layer: requirements are incomplete, existing data has history and an apparently small screen can depend on several business rules. Connecting those two perspectives helps turn an exercise into a maintainable application.
A useful learning habit is to build a small working example, explain why it behaves that way and then test a case that challenges the original assumption. Reading code, reviewing a change and writing down a trade-off make that understanding easier to share. Qualifications and community milestones are listed as documented; this page does not add certificates, scores or credentials that have not been supplied.
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.
07 / 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.
08 / A CLOSER LOOK
Turn a page into a useful conversation
If this subject relates to your requirement, describe the closest example and the part that differs in your own application. An enquiry about an API might include its current consumers and expected response; an enquiry about a dashboard might describe the records a role should see. A recruiter can point to a project or responsibility they would like to discuss in more detail.
You can contact Raju by the email, phone or WhatsApp links published on the portfolio, or use the enquiry form. Include the role or project type, preferred working arrangement and any important timing constraint. A clear first message makes the next discussion more focused. Availability, price, ownership and delivery arrangements are agreed for the specific opportunity rather than assumed from a general service page.