mmahlatse-ventures-live-secure

byMahlatse Shiburi

Build a REAL production-ready SaaS application called: MAHLATSE VENTURES LIVESECURE Owner: Mahlatse Ventures Market: South Africa Tagline: “Live Protection. Real Response. Every Moment.” IMPORTANT: This must NOT be a fake AI demo, mockup, static prototype, or collection of screens. Build a functional application with real authentication, database, APIs, GPS/location capabilities, notifications, role-based access, security, and deployable architecture. Every major button and workflow must perform a real action or clearly show what configuration/API credential is required. PRODUCT PURPOSE: LiveSecure is a safety, security and emergency-response platform for individuals, families, businesses, schools, transport operators, security companies and organisations. Users can trigger emergencies, share their live location, manage emergency contacts, receive alerts, and allow authorised responders/admins to monitor and respond to incidents. BUILD IT AS A MULTI-TENANT SAAS: Mahlatse Ventures is the platform owner. Multiple client organisations must be able to register/use the platform independently. Each organisation must have isolated data. Platform Owner/Admin can manage organisations, users, subscriptions, incidents and system settings. USER ROLES: 1. MASTER ADMIN - Secure admin login - Dashboard with live system statistics - Manage organisations/tenants - Manage users and roles - Manage responders - View/manage incidents - View active emergencies on live map - Manage subscriptions/plans - System audit logs - Notification management - Platform settings - Suspend/reactivate tenants - Export reports 2. ORGANISATION ADMIN - Organisation dashboard - Manage employees/users - Manage responders - Manage emergency contacts - View organisation incidents - Live incident map - Incident history - Reports - Organisation settings - Subscription/plan information 3. CLIENT/USER - Secure registration/login - Personal profile - Emergency contacts - SOS/PANIC button - Share live location - Start emergency incident - Cancel incident with confirmation - View incident status - View incident history - Receive alerts - Account/security settings 4. RESPONDER - Secure responder login - Set Available/Unavailable status - Receive nearby emergency alerts - View incident location - View incident details - Accept/decline response - Navigate to incident - Update status: Dispatched, En Route, Arrived, Resolved - Add incident notes - View assigned incidents EMERGENCY/SOS SYSTEM: Create a highly visible SOS button. When activated: 1. Confirm emergency action where appropriate. 2. Create a real incident in the database. 3. Capture user's current GPS coordinates. 4. Record timestamp, user, tenant, incident ID and status. 5. Notify authorised organisation admins/responders. 6. Display the incident on the live operations map. 7. Continuously update location while the emergency session is active, subject to browser/device permissions. 8. Show incident status to the user. 9. Allow authorised responders/admins to acknowledge and manage the incident. 10. Store a complete incident timeline/audit trail. Do NOT claim that the system can automatically contact SAPS, ambulance, fire or private security unless an actual supported API/service is configured. Build integration-ready adapters and configuration screens for future integrations. LIVE LOCATION: Use browser/device geolocation APIs where available. Request location permission properly. Show accuracy, latitude, longitude and timestamp. Allow authorised responders/admins to see active incidents on a map. Use a mapping provider such as Mapbox or Google Maps through environment/API configuration. Never expose private API keys in frontend code when they should be server-side. DATABASE: Use a real persistent database. Recommended structure: organisations users roles responders emergency_contacts incidents incident_locations incident_events notifications subscriptions audit_logs system_settings Every organisation-owned record must contain tenant/organisation ID. Enforce tenant isolation on backend/database queries. Never allow one organisation to access another organisation's data. INCIDENT STATUSES: ACTIVE ACKNOWLEDGED DISPATCHED EN_ROUTE ARRIVED RESOLVED CANCELLED FALSE_ALARM INCIDENT INFORMATION: - Incident ID - User - Organisation - Emergency type - Priority - GPS location - Address/reverse geocoded address where available - Created time - Last location update - Assigned responder - Status - Timeline - Notes - Resolution EMERGENCY TYPES: Panic/SOS Medical Fire Crime/Security Accident Vehicle Emergency Other DASHBOARD: Create a professional command-centre dashboard showing: - Active emergencies - Incidents today - Open incidents - Resolved incidents - Responders available - Users - Organisations - Recent incidents - Live map - Emergency priority indicators LIVE MAP: Show active incidents and responder locations where permission and tracking are available. Clicking a marker opens incident details. Provide filters by status, organisation, priority and emergency type. NOTIFICATIONS: Build a real notification architecture. Support in-app notifications. Prepare integrations for email, SMS, WhatsApp and push notifications. Store notification delivery status. Do not fake successful delivery when no provider is configured. SECURITY: Implement: - Secure authentication - Password hashing through trusted authentication provider - Role-based access control - Tenant isolation - Server-side authorization - Input validation - Rate limiting for SOS/API endpoints where appropriate - Audit logging - Secure environment variables - No hardcoded secrets - Protection against unauthorized incident access - Session security - Error handling without exposing sensitive information PRIVACY: Treat location and emergency information as sensitive. Only authorised users may access it. Provide privacy/consent settings. Provide account deletion/data-management capability where appropriate. Create Terms, Privacy Policy and Emergency Service disclaimer pages. SAAS/BILLING: Create subscription architecture with plans such as: FREE/TRIAL BASIC PRO BUSINESS ENTERPRISE Include: - Organisation subscription status - Trial period - Plan limits - User limits - Responder limits - Billing page - Upgrade/downgrade architecture - Payment provider integration-ready design Do not pretend payments succeeded without a real payment provider. UI/UX: Create a premium modern security-tech interface. Mobile-first and fully responsive. Professional South African business aesthetic. Fast loading. Accessible. Clear emergency states. SOS button must be extremely obvious but designed to reduce accidental activation. Use professional dashboard cards, tables, maps, status badges, charts and notification panels. Do not overcrowd the interface. PAGES: Landing page Login Register Forgot Password User Dashboard SOS/Emergency Emergency Contacts Incident History Responder Dashboard Responder Incident View Organisation Dashboard Organisation Users Organisation Responders Live Operations Map Incidents Reports Notifications Subscription/Billing Profile Settings Master Admin Dashboard Organisations Platform Users Platform Incidents Audit Logs System Settings Privacy Policy Terms Emergency Disclaimer 404/Error pages LANDING PAGE: Clearly explain: - Personal safety - Family protection - Business security - Emergency response - Live location - Responder management - Organisation dashboards - SaaS benefits Include strong CTA: “Get Started” “Request a Demo” TECHNICAL REQUIREMENTS: Use a maintainable production architecture. Separate frontend, backend/business logic and database access where appropriate. Use reusable components. Use environment variables for all credentials/API keys. Create database migrations/schema. Create seed/demo data only for development and clearly label it. Create proper loading, empty, error and success states. Handle network failures gracefully. Create API endpoints/services for authentication, users, organisations, incidents, locations, notifications and subscriptions. Validate all incoming data. Add logging and audit trails. AI: AI may be used for useful functions such as: - Incident summarisation - Priority/risk assistance - Duplicate/related incident detection - Admin reporting - Natural-language incident summaries But AI must NEVER fabricate emergency events, locations, responders, successful notifications or emergency-service dispatches. Clearly distinguish AI assistance from verified system data. REAL-WORLD READINESS: Build the application so it can be connected to: - Mapbox/Google Maps - Firebase/Auth or equivalent authentication - PostgreSQL/Firestore or equivalent database - Email provider - SMS provider - WhatsApp provider - Push notifications - Payment provider - Emergency/security APIs where legally and technically available Create a clear environment-variable/configuration system and setup documentation showing exactly what credentials are required. QUALITY CONTROL: Before completing: - Test registration/login - Test role permissions - Test tenant isolation - Test SOS creation - Test GPS permission/error handling - Test incident status updates - Test responder assignment - Test live map updates - Test notifications - Test admin workflows - Test mobile responsiveness - Test error handling - Remove broken links/buttons - Remove fake functionality - Remove placeholder claims - Ensure database operations are real IMPORTANT FINAL RULE: Prioritise FUNCTIONALITY over visual mockups. Build the actual application foundation and working workflows first. If an external service requires credentials, implement the integration correctly and show a configuration/setup requirement rather than replacing it with fake data. Brand everything as: MAHLATSE VENTURES LIVESECURE Owned by Mahlatse Ventures South Africa