EV Charging Marketplace App Completion

Job overview ALTEC-MMXIV Limited, trading as Makunika, is seeking an experienced mobile application developer or small development team to take turnkey responsibility for completing and launching an existing EV charging application. The application is already substantially developed and integrated with Flutterwave payments. It supports an EV charging service in which users can top up their accounts and activate charging using RFID cards. The immediate challenge is that the application has experienced technical difficulties during testing, production preparation and uploading to the Apple App Store and Google Play Store. Therefore, most of the assignment concerns: Reviewing and correcting the existing application Resolving build and upload problems Fixing bugs that prevent reliable operation Preparing the application for production Successfully publishing it on the Apple App Store and Google Play Store We are not presently seeking an unnecessary rebuild of the application. However, we welcome a professional audit and practical recommendations that improve security, stability, performance and future scalability. The selected contractor will be responsible for the complete working result. ALTEC has a resident software engineer who will provide technical information, support the handover and independently verify each milestone before payment is released. Current application and business model The existing application is intended to allow users to: Register and manage their accounts Locate EV charging stations View charger information and availability Top up account credit through Flutterwave Link an RFID card to their account Tap the RFID card at a compatible charger to activate charging Monitor charging activity Pay for charging from their account credit View their wallet, top-ups, charging sessions and transaction history The platform is intended to grow into a multi-operator marketplace where third-party charger owners can onboard their charging stations. In future, the platform should also accommodate battery-swapping stations and services. Scope of work 1. Technical audit and takeover The contractor shall: Review the existing Android and iOS application code. Review the backend, APIs, database and administrative portal. Review the current Flutterwave payment integration. Review the RFID-card and charger-integration functionality. Review the current development and production environments. Identify the causes of the current build, upload and publication problems. Identify critical bugs, security weaknesses and incomplete functionality. Produce a short audit report and prioritized correction plan. Confirm the quotation and schedule for the remaining milestones. The contractor should prioritize repairing and completing the existing system. No complete rebuild should proceed without ALTEC’s written approval. 2. Build and application stabilization The contractor shall resolve issues including: Application build failures Android and iOS configuration problems Dependency and package conflicts Registration and login failures Application crashes API and database errors Flutterwave payment failures RFID authorization problems Charging-session errors Incorrect or duplicated transactions Poor performance and error handling Security or credential-management weaknesses Inconsistent functionality between Android and iOS All corrected code must be committed to a repository controlled by ALTEC. 3. Flutterwave wallet and top-up functionality The application is already integrated with Flutterwave. The contractor shall review, test and stabilize this integration. Users should be able to: Add credit to their accounts through Flutterwave Use supported payment methods, including mobile money Receive confirmation after a successful top-up View their available balance View top-up and transaction history Receive digital receipts and notifications Receive refunds or adjustments where authorized The platform must correctly handle: Successful payments Pending payments Failed and cancelled payments Reversals and refunds Duplicate Flutterwave webhooks Interrupted transactions Payment reconciliation Wallet credit must only be issued after a successful payment has been independently verified through the backend. 4. RFID card and charging authorization Each user will be issued with an RFID card for activating charging at compatible charging stations. The system must support: Issuing and registering RFID cards Linking each card to a user account Activating and deactivating cards Blocking lost or stolen cards Replacing damaged or lost cards Linking replacement cards to the user’s existing account balance Maintaining card-status and assignment history Using one user account through both the application and RFID card Supporting multiple cards for approved corporate or fleet accounts The user’s credit should be held securely within the platform’s central wallet. The RFID card should identify and authorize the user but should not be the sole storage location for the financial balance. The expected process is: The user tops up through Flutterwave. The payment is verified and credited to the user’s platform wallet. The user taps the linked RFID card at the charger. The charger sends the RFID identifier for authorization. The platform verifies the card, user and available balance. Charging is authorized or rejected. The charger sends charging-session and meter information. The final cost is deducted from the user’s wallet. The session and payment record appear in the application. The system must safely handle insufficient balances, blocked cards, connectivity interruptions, duplicate authorization attempts, charger failures and incomplete charging sessions. 5. EV charging functionality The contractor shall verify and complete the application’s charging-related functionality, including: Charger location and mapping Station and connector information Charger availability Tariff display RFID authorization Start and stop charging Charging status Session duration Energy consumed Session cost Session and transaction history Fault reporting Charging notifications Failed-session reconciliation Where the chargers use OCPP, the contractor should review the existing implementation and recommend or implement the required functionality for OCPP 1.6J, with a future upgrade path to OCPP 2.0.1. The contractor must disclose any charger-specific firmware, API or configuration requirements. 6. Administrative functionality The administrative portal should allow ALTEC to: Manage users Issue, activate, block and replace RFID cards View and adjust wallets through controlled, auditable processes Manage charging stations and chargers Configure tariffs Monitor charger availability View charging sessions Review Flutterwave transactions Reconcile top-ups and wallet credits Process refunds and adjustments View faults and failed transactions Manage roles and permissions Access administrative audit logs Any manual financial adjustment must record the administrator, reason, date, original entry and adjustment entry. 7. Third-party charger onboarding The application should be reviewed for its ability to support chargers owned by parties other than ALTEC. The platform’s architecture should allow third-party charging operators to: Register or apply to join the platform Submit operator and station details Register chargers and connectors Provide charger manufacturer, model and protocol information Set or propose tariffs Monitor charging sessions View revenue and transaction reports Receive settlement statements ALTEC should be able to approve, suspend or deactivate operators, stations and chargers. If this functionality is not sufficiently developed in the current application, the contractor should quote for it as a separate milestone rather than treating it as part of the basic store-upload assignment. The long-term goal is for a user to use one Makunika account and RFID card across participating compatible charging stations operated by different owners. 8. Battery-swapping readiness Full battery-swapping functionality is not required for the initial store launch unless separately agreed. However, the contractor should review whether the current architecture can later support: Battery and swapping-station operators Battery identification Battery specifications and compatibility State of charge and state of health Battery custody and movement history Swap transactions Reservations Subscription or pay-per-swap models Operator commissions and settlements Applicants may separately quote for a battery-swapping architecture and implementation roadmap. 9. App Store and Google Play publication This is a central part of the assignment. The contractor shall: Diagnose the current upload and publication problems. Correct Android and iOS build configurations. Correct package names, bundle identifiers, signing and certificates. Resolve dependency and SDK compatibility problems. Prepare production builds. Configure required permissions and disclosures. Implement account deletion where required. Support privacy-policy and data-safety requirements. Prepare or advise on store descriptions, screenshots and listing information. Upload the application through ALTEC-controlled accounts. Respond to reasonable review comments. Correct technical rejection issues. Secure successful publication on both stores. The relevant milestone will not be considered complete merely upon uploading the application. Completion requires successful publication, except where approval is delayed solely by matters outside the contractor’s control after all technical and policy requirements have been satisfied. 10. Testing and production deployment The contractor shall complete: Android and iOS device testing Functional testing Payment and wallet testing RFID-card testing Charger-integration testing Security checks Regression testing Production deployment Crash reporting and error monitoring Post-launch verification ALTEC’s resident software engineer will independently review the implementation and test results before each milestone payment is released. Required deliverables The assignment should result in: Technical audit and prioritized correction plan Corrected and stable source code Working Android application Working iOS application Stable Flutterwave wallet and top-up system Working RFID-card authorization Stable charger and charging-session functionality Functional administrative portal Production backend and database Successful Google Play Store publication Successful Apple App Store publication Source code in an ALTEC-controlled repository Updated API, database and deployment documentation Administrator and RFID-card management guide Charger-integration documentation Credential and account handover checklist At least 30 days of post-launch defect support Proposed milestones Applicants must quote separately for each milestone and may recommend reasonable refinements. Milestone Required result 1. Technical audit Review existing application and systems; identify upload problems, critical bugs, security issues and required corrections 2. Build and critical stabilization Resolve build failures, crashes, authentication, API, database and critical application problems 3. Payment, wallet and RFID completion Stabilize Flutterwave top-ups, wallet ledger, RFID linking, charging authorization and transaction reconciliation 4. Core charging and administration Complete charging sessions, charger information, transaction history, card administration and operational reporting 5. Android production launch Complete testing and secure successful publication on Google Play 6. iOS production launch Complete testing and secure successful publication on the Apple App Store 7. Third-party charger marketplace Audit, complete or develop operator and charger onboarding, commissions, reporting and settlement functionality 8. Documentation and warranty Complete handover, documentation, training and post-launch defect-support period Optional milestone Battery-swapping architecture and implementation roadmap Milestones 5 and 6 may proceed concurrently where appropriate, but they should remain separately priced because the two stores have different technical and review requirements. Quotation requirements Applicants should provide: A fixed price for each milestone. A timeline for each milestone. The total proposed turnkey price. The proposed team and each person’s role. The technologies they expect to use. Their assumptions and exclusions. Any third-party costs not included in the quotation. The number and models of chargers included in their integration price. Their post-launch warranty period. Their optional monthly maintenance price. Examples of existing applications they have repaired and published. Applicants may refine later milestone quotations after completing the technical audit. Any adjustment must be fully justified and approved by ALTEC before the relevant work begins. ALTEC will not be obligated to accept an unexplained or excessive price adjustment. Required experience Repairing and completing inherited mobile applications Android and iOS production builds Apple App Store and Google Play publication Flutter or the application’s existing framework Backend APIs and database systems Flutterwave or similar payment integrations Wallet and financial ledger development RFID or NFC-based authentication IoT or EV charger integration OCPP experience Production monitoring and security Technical documentation Ownership and access All source code, databases, documentation, configurations and intellectual property developed or modified under this engagement will belong to ALTEC-MMXIV Limited. The following must remain under ALTEC’s ownership and control: Source-code repository Hosting and cloud accounts Domains Flutterwave account Apple Developer account Google Play Console account Application signing credentials Production database The contractor will receive appropriate role-based access and will be required to sign a confidentiality and intellectual-property agreement before receiving sensitive code or credentials. Screening questions Describe an existing application you took over, repaired and successfully published. What are the most common causes of applications failing during App Store and Play Store submission? Have you published applications on both stores? Please provide examples. What experience do you have with Flutterwave or comparable payment gateways? What experience do you have with RFID-based user authorization? What direct experience do you have with OCPP and EV chargers? How would you prevent duplicate top-ups, wallet deductions and charging transactions? How would you test an RFID charging session when connectivity is interrupted? How would you approach the existing code before recommending a rebuild? Please provide a price and timeline for each milestone.