RecallZero

RecallZero turns fragmented supplier, QA, ERP, and complaint signals into faster, defensible recall decisions with DynamoDB-backed audit trails and production-ready connectors.

Comment

Inspiration

Recall decisions are some of the highest-stakes moments in commerce. A company may receive a supplier email, a QA hold, an ERP lot traceability update, and customer complaints at different times, in different systems, with incomplete evidence. If the team waits too long, the risk grows. If the team reacts without enough context, the decision can be costly and hard to defend.

RecallZero was inspired by that gap: the space between messy operational signals and a clear, auditable recall posture. We wanted to build a product that helps teams move faster without pretending that AI alone should make the final legal decision.

What it does

RecallZero is a recall decision cockpit for regulated commerce teams.

It turns fragmented supplier, QA, ERP lot traceability, and returns or complaints signals into:

  • A recall posture
  • Confidence level
  • Missing evidence
  • Delay risk
  • Recommended next actions
  • Persistent incident records
  • Audit history

The product includes a live SaaS-style workflow with sign up, sign in, tenant workspaces, plans, credits, settings, connector configuration, webhook ingestion, admin controls, and controlled judge access.

Customers can configure connector lanes for supplier inboxes, QA systems, ERP / lot traceability, and returns or complaints feeds. Admins can view production readiness, webhook endpoints, and rotate workspace webhook secrets. Judges can enter a dedicated review workspace without receiving admin privileges.

RecallZero is not a chatbot and does not claim to make final legal recall decisions by itself. It provides decision support and auditability so recall teams can understand what is known, what is missing, and how delay changes risk.

How we built it

We built RecallZero as a Next.js application deployed live on Vercel, with Amazon DynamoDB as the primary backend database.

The database choice was intentional. RecallZero’s core access patterns are tenant-scoped and time-sensitive: load a workspace, check credits, create an incident, append audit events, list recent incidents, read connector configuration, and verify admin/security metadata. DynamoDB fits this workflow because these operations are key-addressable, fast, and do not require relational joins in the hot recall-decision path.

We used a single-table DynamoDB design with lowercase pk and sk keys. Each signed workspace receives its own partition. Within that partition, RecallZero stores workspace profile and credits, incident records, audit events, connector configuration, and admin/security state.

Built with:

  • Next.js App Router and React for the product experience
  • Tailwind CSS and component-based UI for the SaaS interface
  • Amazon DynamoDB for persistent workspaces, incidents, credits, connectors, audit trail, and admin state
  • AWS SDK for JavaScript using key-based reads and writes
  • Signed session cookies for authentication and role-based access
  • Tenant-scoped workspace IDs so customer data is separated by workspace
  • Credit enforcement for analysis usage
  • A decision engine that combines structured recall heuristics with AI-ready analysis behavior
  • Intake quality gates to reject fake probes or messages without operational recall context
  • Connector configuration and webhook routes for supplier, QA, ERP, and complaints signals
  • Admin-only webhook secret rotation with hashed secret storage
  • Billing-ready plan flows for Free, Pilot, Program, and Enterprise
  • A judge review flow that creates a controlled reviewer session

The live app is available at:

https://recallzero-app.vercel.app

Judge entry:

https://recallzero-app.vercel.app/judge

Source code:

https://github.com/moazizbera/RecallZero

Challenges we ran into

One major challenge was making the project feel like a real product instead of a static hackathon demo. That meant building not only the analysis screen, but also the surrounding product system: onboarding, plans, credits, settings, admin, connectors, judge access, and persistence.

Another challenge was trust. A recall workflow cannot simply accept any email and produce a confident answer. We added intake quality checks so fake test messages or vague prompts do not consume credits or create incidents. We also positioned the product carefully: RecallZero supports recall teams, but does not replace their final legal or regulatory judgment.

The most important engineering challenge was designing persistence around how recall teams actually work. We needed workspace-scoped records, credit tracking, connector state, audit history, and admin metadata without leaking data between users. DynamoDB worked well because each workspace can be modeled as a tenant partition, and the app can query incidents, connector state, credits, and audit events by key instead of scanning the whole table.

We also had production polish challenges: protected admin access, repeated signup behavior, plan preservation after sign-in, public deployment aliases, splash-screen routing, and making the interface ready for judges to review without confusion.

Accomplishments that we're proud of

We are proud that RecallZero became a full product experience, not just a single AI demo screen.

Highlights include:

  • Live deployment on Vercel
  • Amazon DynamoDB as the primary backend database
  • Single-table DynamoDB model for tenant workspaces, incidents, credits, connectors, audit history, and admin/security state
  • Workspace-based data separation
  • Controlled judge access
  • Admin-only operations page
  • Credit and plan tracking
  • Connector configuration for real enterprise source systems
  • Webhook ingestion path
  • Incident records and audit history
  • Fake-signal rejection before analysis
  • Production readiness health checks
  • SaaS-style pricing and onboarding
  • A polished splash and product panorama

Most importantly, the product tells a clear story: scattered recall evidence can become a faster, more defensible decision record.

What we learned

We learned that the hardest part of applying AI to high-risk workflows is not generating text. The hard part is context, trust, control, and auditability.

For recall decisions, the system must explain what evidence is present, what is missing, and how risk changes over time. It must avoid overclaiming. It must create records that teams can review later. It must fit into existing operational systems like supplier inboxes, QA platforms, ERP lot traceability, and customer complaint feeds.

We also learned that database design matters for product credibility. DynamoDB was a strong fit because RecallZero does not need broad relational queries in the critical path. It needs fast tenant-scoped access to workspace state, incident records, connector settings, credits, and append-style audit history while evidence changes over time.

Finally, we learned that hackathon products become much stronger when they include the product wrapper around the core idea: authentication, roles, billing model, usage limits, settings, admin controls, and deployment readiness.

What's next for RecallZero

Next, we would turn RecallZero from a production-style review build into a customer-ready pilot.

Planned next steps:

  • Add real SSO with providers such as Azure AD, Auth0, or Cognito
  • Add email verification and team invitations
  • Connect live Stripe subscriptions
  • Add managed secret storage for connector credentials
  • Build deeper ERP, QA, and complaints integrations
  • Add richer incident timelines and regulatory export packets
  • Add organization-level roles and approval workflows
  • Improve recall-specific model evaluation with expert-reviewed scenarios
  • Add monitoring, alerts, and compliance reporting
  • Pilot with regulated commerce, food, health, and consumer goods teams

RecallZero’s long-term vision is to become the operational decision layer for recall and incident response teams: faster than scattered spreadsheets and emails, more defensible than ad hoc judgment, and safer than treating AI as a black-box decision maker.

Built With

Share this project:

Updates