AI / LMS · Project 01
A learning experience with a voice.
SpeakMint brings AI voice conversations and interview practice together with structured learning content and subscription workflows.
- Live AI voice conversations.
- Real-time interview practice.
- Courses, modules, lessons and learner progress.
- Webhook-verified payments and subscription activation.
Laravel · MySQL · Razorpay · AI
Live preview loads when this card comes into view.
THE PROBLEM
Context
Learning and interview practice can be difficult to combine with structured courses and a reliable subscription journey.
MY CONTRIBUTION
Engineering decisions
- Organised courses into modules and lessons with progress tracking.
- Integrated AI voice conversations and interview practice into the learning experience.
- Used server-side Razorpay webhook verification before activating subscriptions.
SYSTEM FLOW
Conceptual architecture
Learner → course / lesson → voice practice → progress record
Illustrative workflow · Not a production screenshot
OUTCOMES
What changed
- Delivered voice learning and interview practice workflows.
- Connected subscription state to verified payment events.
Public product link appears only when a product URL was verified. Source code is not linked unless a project-specific public repository is verified.
01 / 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.
02 / A CLOSER LOOK
Connect clients through a clear API contract
An API contract describes the request a client may send and the response it can rely on. That includes input names, validation rules, authentication, pagination and the difference between a successful operation and a rejected one. Consistency helps a web interface, a mobile application and an external integration handle the same business rules without guessing.
Changes to an established API need to consider existing consumers. Removing a field, changing its meaning or altering an error shape can affect a client that was not part of the latest development session. Examples and compatibility notes make the contract easier to review. The portfolio documents REST API work and integrations; the exact endpoints and access requirements of a live product should be confirmed through its own authorised documentation.
03 / A CLOSER LOOK
Separate payment evidence from access changes
A browser returning from checkout is part of the user experience, but it should not be the only evidence that a payment completed. A payment workflow needs to associate the provider event with the correct internal record and verify the event through the integration’s trusted mechanism before changing access, an order or a subscription.
The application should distinguish pending, successful, failed and later adjustment states where those states apply. Repeated provider events must not create repeated business effects. The portfolio documents Razorpay integration and verified subscription workflows in the relevant experience and project pages. This section explains the design concern; it does not expose payment credentials, customer transactions or private production records.
04 / A CLOSER LOOK
Handle repeated events and partial failures
External services can send the same event more than once, and a request can fail after some work has completed. A safe event handler needs a way to recognise an event already applied and a clear definition of the operation that must happen together. This becomes especially important when a record change also triggers access, a notification or a scheduled task.
Useful review cases include a valid first delivery, a repeated delivery, an invalid event and a failure before the business action completes. The stored outcome should make it possible to understand what happened without recording secrets in logs. An integration is complete only when the expected event and its failure behaviour are understood; receiving a successful HTTP response from the provider does not prove the entire workflow worked.
05 / A CLOSER LOOK
Identity, roles and record access
Authentication establishes who is making a request. Authorisation decides which actions and records that identity can access. A hidden button does not replace a server-side permission check: a protected operation must still check the user when a request reaches the application. Record ownership also matters when several teams or clients use the same system.
A role matrix can make the expected behaviour explicit. It should describe who may view, create, update, export or delete each kind of record, including exceptions such as an assigned owner or administrator. Session expiry and sign-out should have understandable outcomes. A review should include a permitted request and a denied request, so the boundary is demonstrated instead of inferred from the interface.
06 / A CLOSER LOOK
Design an interface around its task
A useful interface makes the next action understandable. Labels should explain the information being requested, navigation should match the user’s context and a screen should show whether information is loading, empty, saved or unavailable. A responsive layout also needs to preserve the order and meaning of content rather than merely shrinking a desktop view.
Frontend work connects these states to real backend behaviour. A form should display validation next to the relevant field, a list should make filtering understandable and a destructive action should explain its consequence. Keyboard focus and touch target sizes affect whether someone can complete the journey comfortably. The portfolio lists JavaScript, React, Vue.js and Laravel Blade as part of the toolkit; the right interface approach depends on the surrounding product.
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
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.