Enhance existing wordpress site with custom plugins

Platform Build Brief Project context The platform is a client-worker marketplace. Clients browse worker profiles on the website and should be able to unlock contact access only after purchasing a plan. The product should remain lightweight, reliable, and practical for a small founder-led team. The current website is WordPress-based, and the immediate objective is to strengthen the worker hiring flow through reliable payments, gated contact access, matching logic, and website-based telephony. Primary priorities The current implementation priority is: 1. Payment gateway + gated contact access. 2. Matching / recommendation logic. 3. Website-based calling / telephony. Authentication/OTP and CRM/messaging are also in scope because they support the core flow, but the above three areas are the most important for this phase. Existing stack assumptions · WordPress website. · Client and worker profiles already exist or are being created on the website. · Current login/signup flow exists but needs review and stabilization. · The solution should preferably use reliable plugins/custom development with maintainable code. Scope of work A. Payment gateway + gated contact access Objective Enable clients to purchase plans and unlock a limited number of worker contacts for a defined duration. Required work · Integrate a suitable payment gateway into WordPress. · Recommend the best gateway option based on Indian market use case, WordPress compatibility, and ease of reconciliation. · Create plan-based access control for worker contact details. · Ensure access rights persist correctly after payment, logout/login, and plan expiry. Functional requirements · Client can browse worker listings before purchase. · Contact details should remain hidden until a paid plan is purchased. · After plan purchase, a client can unlock only the number of contacts included in that plan. · Example phase-1 logic: o Small pack: unlock 2 to 3 worker contacts. o Mid pack: unlock 5 worker contacts. o Time-based plan option: access valid for 15 days or 30 days depending on plan. · The system must track: o plan purchased, o date/time of purchase, o number of contacts allowed, o number of contacts already unlocked, o expiry date of plan, o whether a worker contact was already unlocked by that client. · Once a contact is unlocked, that same client should continue to see that contact during the validity period without paying again. · Once the pack limit is exhausted, further contacts should remain hidden unless the client upgrades or purchases another plan. · Once the plan expires, access should stop automatically. · The system must correctly remember entitlements even after logout and login. Example business-rule detail to design for · A client buys a 5-contact pack valid for 15 days. · They can unlock up to 5 unique worker profiles only. · Re-opening one of the already unlocked profiles should not consume another unlock. · On day 16, access should expire automatically unless a fresh plan is purchased. Admin / reporting needs · Admin should be able to see which client bought which plan. · Admin should be able to see which worker profiles were unlocked by each client. · Admin should be able to manually adjust access in exceptional cases. · Payment records should be traceable for support and reconciliation. Expected output · End-to-end payment and gated-contact flow working on production/staging. · Reusable plan logic that can support future pricing changes. · Short admin SOP/documentation for handling support cases. B. Matching / recommendation logic Objective Create the first working version of client-to-worker shortlist generation. Product expectation This does not need AI in phase 1. A rules-based matching engine is acceptable and preferred if it is robust and easy to explain. Required work · Build a rules-based or template-based recommendation system. · Client inputs should be matched against worker profile fields such as: o locality / area proximity, o availability, o budget, o work type / hours, o experience, o task requirements etc. · Produce a shortlist or ranked recommendation output on the website/admin side. C. Website-based calling / telephony Objective Allow clients to call workers via the platform in a controlled way without immediately exposing direct personal numbers in an uncontrolled manner. Required work · Propose the most feasible setup for website-based calling / telephony within an Indian WordPress context. · Assess and, if feasible, implement one of the following: o click-to-call, o masked calling via a common business number, o routed calls through a telephony provider, o call logs tied to client/worker records. Desired product behavior · Ideally, a client who has unlocked access should be able to initiate a call through the platform or via a protected call route. · Telephony should respect plan entitlements where applicable. · The system should support at minimum: o call initiation logic, o call routing feasibility review, o call activity logs, o call log analytics, o future ability to monitor usage limits. Example business-rule detail to plan for · Client unlocks access under a plan of 5 contacts valid for 15 days. · Only those 5 unlocked workers should be callable during the active plan period. · For each worker, based on call response, a call response % to be highlighted next to profile. · The vendor should clearly state what is technically feasible in phase 1 versus later phases, especially for masking, recording, click-to-call, and compliance concerns. Expected output · Feasibility recommendation. · Proposed telephony stack. · Phase-1 implementation plan with limitations clearly stated. D. Authentication and OTP stabilization Objective Make login/signup stable, secure, and production-ready so that paid access and contact-unlock logic can depend on a reliable user account system. Required work · Review the current WordPress login and signup flow. · Review the OTP verification setup and fix issues affecting production reliability. · Review current nonce-related fixes and confirm secure implementation. · Ensure redirect behavior after login/signup is correct and consistent. · Ensure account/session state is reliable, especially when a client purchases a plan and later logs in again. Expected output · Stable login/signup flow. · Reliable OTP verification in production. · Secure redirect and nonce handling. · Clear documentation of what plugin/custom code is being used. E. CRM + messaging integration Objective Connect user actions to a simple CRM and messaging stack so the business can track leads and send key communications. Required work · Recommend and integrate a CRM suitable for WordPress-based marketplace operations. · Recommend and integrate messaging tools for: o OTP, o payment confirmations, o plan expiry reminders, o basic alerts/notifications, o client communication workflows. · The vendor should recommend practical tools, not enterprise-heavy systems. Expected output · Suggested tool stack with reasons. · CRM capture for key user events. · Messaging triggers for critical workflows. Suggested phase-1 logic The vendor should propose a practical scoring model, for example weighted matching across selected fields, with an explanation of how the score is calculated. Important expectation · Matching logic must be editable later. · Score/weights should not be hard-coded in a way that makes iteration difficult. · Founder/ admin should be able to refine rules over time. Expected output · Working matching logic. · Clear explanation of scoring criteria and weights. · Recommendation output that can be tested and refined. F. Later phase: support desk This is not an immediate build priority but the solution should not block future setup of: · support tickets, · issue tracking, · simple escalation workflow for one support person. Vendor response format requested Please respond with the following: 1. Recommended technical approach for WordPress. 2. Which parts will use plugins and which parts require custom development. 3. Tool/plugin recommendations for payment gateway, OTP, CRM, messaging, and telephony. 4. Estimated timeline by module. 5. Ballpark commercial quote. 6. Examples of similar work done, especially in marketplaces, gated access, membership logic, or telephony flows. 7. Risks, dependencies, or limitations the vendor sees in this scope. 8. Post-launch support model. Important implementation note The preference is for a phase-wise build. The vendor should avoid overengineering and should prioritize a stable phase-1 launch over building a very large, abstract system. The immediate goal is to make client purchase, contact unlock, shortlist generation, and controlled calling work reliably in production.