TL;DR

I built Halal Code Check first as a practical scanner to help Muslim consumers verify food additives quickly while shopping. After shipping that first version, I ran a focused product sprint to reduce first-visit confusion, improve trust signals, and instrument behavior so iteration is based on evidence. It still supports scan, voice, and manual lookup with local-first OCR and a curated 360+ E-code dataset, but the product is now evolving beyond scanning into a broader halal intelligence layer around ingredients, certification context, and market research.

The Problem

The initial product worked technically, but first-time users still needed more guidance.

Core friction points:

Tiny ingredient text on packaging
E-code labels that are hard to interpret under time pressure
Uncertainty around what to check and when to trust a result
Decision flow drop-off after viewing results
Weak qualitative signal collection for roadmap decisions

Product Direction

This sprint shifted the product from a practical scanner and lookup tool toward guided decision support, while also moving it closer to a broader halal intelligence product:

Build for real user uncertainty, especially first-time visitors
Clarify outcomes and usage expectations earlier in the journey
Close the loop: ship -> observe -> collect feedback -> iterate
Use both analytics and stored qualitative input for decisions

Recent Sprint Updates

1. Homepage Reframed for New Users

Repositioned copy and layout to assume no prior E-code knowledge
Updated headline/subcopy around “before you buy” decision context
Improved information hierarchy to explain product value faster

2. Trust and Credibility Layer Added

Introduced a dedicated trust-proof block on the homepage
Added clearer guidance language around expected outcomes
Refined sensitive claims (including offline-related copy) for safer communication

3. Workflow Improvements Across Core Pages

Strengthened “what to do next” pathways after results
Moved feedback prompts closer to decision moments
Improved interaction clarity, including stronger visual states for Yes/No feedback

4. Section-Level Analytics Instrumentation

Added section-level event tracking to identify engagement and drop-off by block
Extended tracking coverage to newly introduced feedback interactions
Enabled practical CRO iteration based on observed behavior

5. Feedback System Expanded and Operationalized

Feedback capture (rating + optional comment) is now available on:

Results pages
E-code detail pages
Food category pages

Feedback is persisted in Supabase, making it queryable for UX and content prioritization.

6. Abuse-Resistant Feedback Backend

Built secure persistence through RPC and server-side abuse checks:

Cooldown/rate limiting
Daily submission caps
Duplicate detection via comment hash
Basic spam and link-pattern protection

This keeps user input useful and reduces noise in qualitative data.

Current Product Experience

Halal Code Check supports three primary lookup paths:

Scan mode: Users scan ingredient labels and extract E-codes via OCR
Voice mode: Users speak E-codes for hands-free lookup
Manual mode: Users directly search the database when they already know the code

The product then maps detected additives to halal status categories and guides next steps with clearer on-page decision support.

Coverage

Curated database of 360+ additives (E-codes)
Practical consumer-first scope over broad, unverified coverage

Architecture and Implementation

I kept privacy-first constraints while adding measurement and feedback infrastructure:

In-browser OCR with Tesseract.js (no mandatory image upload for core scan flow)
Explicit permission handling for camera and microphone usage
Section-level analytics for behavioral insight
Supabase-backed feedback storage for qualitative learning
RPC-based feedback persistence with anti-abuse protections

Key Trade-offs

Guided UX over minimal UI: more product surface area, lower first-visit confusion
Stored feedback over event-only analytics: more backend complexity, better roadmap signal
Abuse controls over frictionless submission: slightly stricter input flow, cleaner data quality

Why This Matters

These changes made the product:

More understandable for first-time users
More trustworthy at the moment decisions are made
Easier to improve continuously through measurable usage and stored feedback

This is the operating model I use on product teams: ship quickly, instrument behavior, capture qualitative signal, and iterate with evidence.

Tech Stack

Layer	Choices
Frontend	React 18, TypeScript, Vite, Tailwind CSS, shadcn/ui
OCR	Tesseract.js (in-browser)
Voice	Web Speech API
Data	Curated E-code dataset + Supabase feedback storage
Backend Logic	Supabase RPC with anti-abuse checks
Analytics	Section-level event tracking across core content blocks
Deploy	Cloudflare Pages

Roadmap

Expand trust-proof surfaces with stronger source-level context
Use section analytics + feedback comments to prioritize highest-friction flows
Continue improving conversion from result pages to confident action
Add higher-confidence assisted lookup flows without weakening privacy defaults

Final Thoughts

Halal Code Check reflects how I build products:

Start with a specific user pain point
Make trust and clarity explicit in UX, not implicit in features
Instrument behavior early so decisions are measurable
Operationalize feedback so iteration stays grounded in real users

If you want to build and iterate a consumer product with strong UX fundamentals and evidence-based CRO, let’s talk.