I designed and implemented MAP as a role-based SaaS product for micro-market operators, suppliers, administrators, and branch users. My work covered workflow and role modeling, dashboard UX, onboarding, company and branch structures, Base44 product logic, AI-assisted guidance concepts, documentation, maintenance, and an explicitly separate AWS migration direction.
MAP organizes the people, organizational context, and information behind product-placement and supplier-support decisions. Operators can work within company and branch context, suppliers can move through structured support workflows, and administrators can manage the system around them. The current Base44 application and the planned AWS direction remain clearly separate states.
Start with roles and decisions, not dashboard widgets
The business workflow crosses several perspectives. An operator needs to manage company or branch activity and make product-placement decisions. A supplier needs a structured support and product-information path. Administrators need onboarding and management controls. Branch users need access scoped to their working context.
Beginning with a generic dashboard would have hidden those differences. I first modeled the decisions each role needed to make, the information available to that role, and the action that should follow. Those relationships became the basis for navigation, dashboard hierarchy, onboarding, product-support flows, surveys and events, MarketIQ, and SupplierIQ.
Role workflow walkthrough
Change the role. Keep the context visible.
A deterministic explanation of the confirmed role, organization, and workflow relationship. It is not a live Base44 application and does not collect data.
Work from a branch-scoped product decision.
The operator sees the branch context before reviewing a product-placement or support workflow.
- Context
- Organization · Branch A · operator
- Workflow
- MarketIQ product-placement review
- Decision
- Choose the next product or support action
The role model is both a product and architecture boundary. It shows how operators, suppliers, administrators, and branches relate without exposing real companies, customers, pricing, or authorization configuration.
The current product workflow
The current implementation uses Base44 product and data logic to support company and branch structures, user and administrative actions, onboarding, surveys and events, product placement, supplier support, and dashboard workflows.
A typical path starts before a user reaches a dashboard. Account setup can involve a temporary password or resend path, agreement or NDA steps, company setup, and branch context. Each stage needs a success state, a way to correct invalid information, and a clear destination after completion.
Once inside the product, MarketIQ and SupplierIQ organize different tasks rather than duplicating one dashboard with new labels. MarketIQ supports product-placement and market-oriented decisions. SupplierIQ structures supplier details, product support, and related workflows. Public reconstructions use neutral sanitized organization and workflow labels so the product logic can be demonstrated without exposing private operating information.
Company and branch boundaries
Multi-role products require more than a role name in the interface. The underlying records and actions need a consistent company and branch context. I designed the product around company, branch, user, role, survey or event, product, and support relationships.
Company isolation and role-based behavior are part of the product model. The public narrative explains that boundary and its workflow intent without publishing the private authorization configuration or claiming a security certification.
Error and recovery states also follow the workflow. A temporary password can expire, an agreement can remain incomplete, company setup can be missing required information, or an administrative action can need revision. These states make recovery part of the product journey rather than an afterthought.
AI assistance with a human decision point
AI appears as assistance within product workflows: recommendations, structured insight, support-response help, and guidance. The responsible product boundary is that a user reviews the information and decides what to do next.
This is AI-assisted guidance with a visible human decision point, not an autonomous agent with independent business authority. No recommendation-quality score is claimed.
Current implementation and future architecture
The current application and the AWS direction solve different questions. Base44 supports the product as it exists now. The AWS work documents a potential path for future maintainability or scale. A migration diagram may show stages, but planned services are not treated as already deployed.
This separation keeps a future-state diagram from being mistaken for today's runtime. Migration progress, target services, and cutover decisions stay out of the public architecture until they are confirmed for release.
What I owned
My contribution included product architecture, role and workflow design, Base44 implementation, dashboard and onboarding UX, admin and client flows, documentation, AI-assistance patterns, maintenance, and AWS migration planning.
Confidential relationship details, customer identities, pricing, and private strategy remain outside the portfolio. No customer, revenue, adoption, or performance metric is approved for public use.
Evidence and next iteration
Direct implementation confirmation and sanitizable private product artifacts support the workflow story. The public Game Plan Mastery site provides organization context, while the current product screen remains in a needs-export state until company, customer, access, and pricing data have been reviewed.
A sanitized walkthrough of one complete role journey would make the product logic easier to inspect: onboarding, organization context, one MarketIQ or SupplierIQ decision, and the resulting human-reviewed action.
The next engineering documentation step is equally specific: record the current data and authorization boundaries separately from the proposed migration architecture. That keeps implementation facts stable even as the future plan changes.