CRM · Project 03
A connected view of operations.
OpsPulse CRM brings custom business modules, sales tracking, integrations and dashboards into one operations workflow.
- Client management modules.
- Sales tracking and support workflows.
- REST integrations and reporting dashboards.
- Database optimisation.
CodeIgniter · MySQL · JavaScript
A public demo URL is not available for this project.
THE PROBLEM
Context
Sales, customer and support work can become fragmented when teams use disconnected tools and records.
MY CONTRIBUTION
Engineering decisions
- Built custom CRM functionality across 15+ modules.
- Connected payment, email and SMS integrations to business workflows.
- Optimised database performance by 45%, according to the resume.
SYSTEM FLOW
Conceptual architecture
Organisation → customer / lead → sales or support activity → dashboard
Illustrative workflow · Not a production screenshot
OUTCOMES
What changed
- 15+ CRM modules delivered.
- 45% database performance improvement listed for the TRENITY CRM work.
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
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.
02 / A CLOSER LOOK
Model the relationships before adding screens
A relational model should reflect the relationship between the records people work with. A client may have several projects, a project may contain tasks and an invoice may refer to a service or a customer. Explicit relationships help the application answer questions consistently and reduce the need to copy the same information into unrelated places.
The model also needs rules for change. What happens to linked history when a record is archived? Can two users create the same external reference? Which fields represent the current state and which preserve an event that already occurred? These decisions influence validation, reporting and deletion behaviour. A diagram is useful when it clarifies those questions; a list of tables alone does not explain the business process.
03 / 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.
04 / 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.
05 / A CLOSER LOOK
Measure a query before changing it
A slow screen can involve several causes: too many database requests, a query that scans unnecessary rows, a large response or repeated work after the query completes. The first step is to identify the actual request and the data volume involved. A measured example provides a baseline for deciding whether an index, a different query or a smaller result is useful.
An index should follow a real access pattern, including filters and ordering. Loading related data deliberately can avoid repeated lookups, while selecting only necessary fields can reduce transfer and processing. Changes should be checked against the result that the screen still needs to display. Performance figures shown in the experience section remain tied to their documented roles; this explanation does not add a new benchmark or guarantee.
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
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.
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.