Built with FlutterFlow
DOER Partners: AI-Powered B2B Sales Engine
InfiniteUp Agency
1 collaborator
DOER Partners: Foundational Project Document & System Overview
1. Project Identity & Vision
Project Name: DOER Partners
Mission: A decentralized B2B sales engine equipping gig workers ("Sales Partners") to discover, track, and sell enterprise software to localized businesses.
The core vision is to build a robust, AI-assisted toolset that bridges the gap between individuals looking for sales work and small local businesses in need of modernized solutions.
1.1 Platform Availability
The application is cross-platform and live on the following endpoints:
2. Development Methodology: "Visual Pairing"
DOER Partners is built using an advanced model of AI-assisted development defined as Visual Pairing. This methodology explicitly rejects the concept of "vibe coding" (relying solely on an AI's memory), which breaks down on complex projects due to Context Drift (finite memory/context windows).
2.1 The Division of Roles
Visual Pairing utilizes a visual structure (the Widget Tree in FlutterFlow) as an immutable anchor for project context.
Human Developer: Holds architectural authority. Responsible for structural calls, verifying widget hierarchies, and deciding when to roll back (hitting
Cmd + Z).Anchored AI: Functions as a pattern recognition engine. It reads stack traces, surfaces relevant documentation, and generates localized hypotheses.
Specialization: The central AI is effectively "divided" into hundreds of tiny, specialized AI "minions" that manage specific, localized tasks within the defined visual framework (e.g., "Auth Specialist AI", "JSON Parser AI", "API Query AI", "Widget Builder AI", "Briefing Logic AI", "Magic Sales AI").
3. Core Functionality & Features
The application is a centralized workspace for a Sales Partner's localized CRM, mapping, and prospecting operations.
3.1 Dashboard & Revenue Tracking
Equips Partners with a dashboard to visualize their portfolio, tracking estimated annual revenue (ARR). It also handles task assignments and access to coaching materials.
3.2 Localized Prospecting (Nearby Search)
A coordinate-based prospecting tool that enables Partners to discover new localized leads (e.g., searching for 'Car Repair' or 'Dentists').
Workflow: Partners select a category and are presented with prospects. They can then add relevant leads to their active "hitlist".
State Dependency: Relies on App State variables like
location, selectedCategory, locationFilter, and currentSearchLocation.3.3 Territory Management
Leverages Google Maps API for territory mapping and specialized localized prospecting.
3.4 Daily Briefings & AI Coaching
The app provides personalized daily briefings and leverages advanced AI tools for coaching and pipeline management.
Backend dependency: Briefings are managed via a subcollection
briefings nested inside a parent business document.3.5 AI-Driven Tools ("Magic Sales")
A dedicated pipeline and toolset, powered by the OpenAI API, designed to streamline the partner's workflow and sales cycle.
4. Technical Architecture & System Overview
DOER Partners is constructed on a Firebase backend and a FlutterFlow frontend, utilizing specialized APIs.
4.1 Technology Stack & Integrations
Frontend/Framework: FlutterFlow (Visual UI/Widget Tree).
Database & Backend: Firebase (Firestore for data architecture).
Authentication: Firebase Auth.
Location Services: Google Maps API (Territory Mapping), Google Places API (Localized Prospecting/Nearby Search).
AI: OpenAI API.
Build Provider: Codemagic (transient, infrastructure failure noted).
4.2 Known Database Schema & State Management
Firebase Structure:
Top-level
users collection.Top-level
businesses collection (Single Document). Often contains an owner field referencing the Authenticated User.Subcollection
briefings nested inside individual businesses documents.App State: The application utilizes several critical App State variables (
location, selectedCategory, locationFilter, currentSearchLocation). State reliability is managed by explicitly "persisting" coordinate data to local storage to prevent "App Amnesia" on cold boot.4.3 Key Engineering Resolutions
A snapshot of the intense, iterative debugging process that defined the sprint:
The macOS/iOS "White Screen of Death": A fatal cold boot crash was resolved. It was caused by three architectural failures aggregated on the Homepage: an unlocked auth gate, a ghost parameter (
businessDoc), and a conditional trap based on non-persisted App State.Curing "App Amnesia": Fixed an issue where localized prospecting results failed to load after the app was closed and reopened, by persisting coordinate data.
Interested in working with InfiniteUp:
Book a complimentary discovery call with InfiniteUp's Barrett Nash to share your product ideas.
DOER Partners inside the FlutterFlow development environment.
Like this project
Posted Apr 8, 2026
Architected a cross-platform AI sales CRM. Deployed to iOS, Android & Web utilizing FlutterFlow, Firebase architecture, and OpenAI for localized prospecting.
Likes
1
Views
2
Collaborators
