PORTFOLIO / GROW WITH RAJUgrowwith raju
Resume ↓
GROW WITH RAJU

Explore.

NOW READINGIntroduction
FULL STACK ENGINEER / INDIA
Download resume ↓rajukumar.191813@gmail.com ↗

FOR RECRUITERS & TEAMS

Let’s build
your next chapter.

Have a role or project in mind? Tell me about your team and the opportunity.

Your details are stored privately so Raju can respond. This submits an enquiry; it does not book or confirm an engagement.

Home / Selected work

Selected work

Built for real use cases.

A selection of systems, workflows and integrations from my portfolio. Each project page explains its focus and the technologies involved.

Laptop with a code editor during a development session
Illustrative workspace photograph · Chirayu Trivedi / Unsplash · not a project screenshot
  • SpeakMint — AI voice conversations, interview practice, courses and subscriptions.
  • Emishopco — loan processing, EMI automation, payments and reporting.
  • OpsPulse CRM — client, sales and support workflows with dashboards.
  • Growithraju — courses, internships, assessments and payment features.
  • Panatomics — agency CRM, projects, tasks, invoices and database-backed service pricing.

01 / A CLOSER LOOK

Explore the portfolio with a purpose

Use the project collection to compare the kind of workflow you need: learning and interview practice, lending operations, agency administration, a storefront or a browser-based tool. The dedicated pages explain the focus and available links. The experience and resume pages provide the professional timeline, while the skills pages explain how the technologies fit together.

If you have limited time, start with one project that resembles your requirement, then check the related backend, API or data page. A useful enquiry can refer to that example and describe what is similar or different in your own situation. This keeps the conversation specific. Unavailable external sites are labelled, and repository previews are distinguished from hosted application demos.

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

Learning tools connect activity and progress

A learning platform needs to connect content to the person using it. Courses, lessons, assessments and progress records represent different parts of that journey. A clear model defines what counts as completion, what happens on a repeat visit and how access relates to enrolment or a subscription where those features are present.

Feedback should help a learner understand the next step rather than simply display a percentage. For an interview-practice or voice feature, the distinction between starting a session, receiving a response and recording an outcome should remain clear. The SpeakMint and Growithraju pages list their documented features separately. This explanation does not imply that a feature from one learning product exists in every other education-related project.

05 / A CLOSER LOOK

A storefront is a sequence of decisions

A shopping interface helps someone discover a category, compare an item and understand what happens next. Product descriptions, cart entry points and account navigation should agree about the item and the state of the journey. A public storefront can be reviewed visually, but the presence of a button alone does not establish that payment, fulfilment or order handling has been verified end to end.

The QuickBuy deployment uses the MyshopX brand and presents study-resource categories alongside shopping navigation. Its portfolio description stays within that observed scope. A deeper implementation review would follow the complete product-to-order journey with authorised test data, including unavailable products and interrupted steps. No sales, customer adoption or transaction volume is inferred from the public page.

06 / A CLOSER LOOK

A creative tool needs reversible choices

An image or poster editor combines several kinds of state: uploaded assets, layout choices, text, background, effects and export settings. A useful workflow lets someone understand what is selected and see the consequence of a change before committing to an output. Undo and reset serve different purposes and should communicate the amount of work they affect.

The resulting file also matters. A preview on the screen is not the same as an exported image, so a review should consider dimensions, aspect ratio and how readable the content remains outside the editor. StudySync exposes controls for these tasks in its public interface. This describes the observed tool and the questions worth reviewing; it does not add unverified format support, cloud storage or collaboration features.

07 / 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.

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.

← Back to full portfolio