TL;DR

I built Halal Code Check to solve a clear real-world problem: Muslim consumers need a faster, simpler way to verify whether food additives are halal-compliant while shopping. The app supports scan, voice, and manual lookup, runs OCR locally in the browser for privacy, and includes a curated database of 370+ food additives (E-codes).

The Problem

For halal-conscious shoppers, ingredient labels are hard to trust and hard to read.

Common friction points:

Tiny ingredient text on packaging
E-code numbers that are difficult to interpret on the spot
Conflicting answers from random online sources
Purchase decisions made quickly in-store with limited context

Why This Matters

Uncertainty at the point of purchase creates hesitation and frustration
Existing workflows are manual and inconsistent
Privacy concerns increase when users must upload images to unknown servers

Why I Built This

I wanted a practical verification tool people could use immediately while shopping, without asking them to trust black-box services with their data.

The product direction was straightforward:

Let users verify ingredients in the way that suits their context
Keep core functionality local-first
Make results easy to understand
Keep the system maintainable as data and feature scope grow

What the Product Does

Halal Code Check supports three input 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 app then maps detected codes to halal status categories and shows clear, readable results.

Current Coverage

Curated database of 370+ food additives (E-codes)
Focused on practical consumer use cases rather than encyclopedic depth

Product and Architecture Decisions

I designed this around one non-negotiable constraint: privacy-first by default.

Local OCR processing with Tesseract.js in the browser
No mandatory image upload for core scan functionality
Explicit permission handling for camera and microphone access
Static-first deployment on Cloudflare Pages for straightforward operations

Design Trade-offs

Local-first over cloud-first: stronger privacy posture, but requires careful client-side optimization and device compatibility handling
Multi-input UX over single flow: more implementation complexity, but better real-world usability
Curated dataset over broad unverified coverage: slower data expansion, better trust in results

What I Built

I delivered the product end to end:

Frontend experience in React + TypeScript
OCR pipeline integration with Tesseract.js
Voice input integration via Web Speech API
E-code data model and lookup logic
Result categorization and user-facing explanation patterns
Cloudflare Pages deployment pipeline

This was built as a production-minded product, not just a demo: clear user flows, clean architecture boundaries, and room to iterate. This is the kind of work I do through my MVP Development service.

Tech Stack

Layer	Choices
Frontend	React 18, TypeScript, Vite, Tailwind CSS, shadcn/ui
OCR	Tesseract.js (in-browser)
Voice	Web Speech API
Data	Curated local E-code dataset
Deploy	Cloudflare Pages

Roadmap

Add richer source-level references for each E-code entry
Expand regional language support for voice and content
Add barcode-assisted flows for faster product-level verification
Introduce optional premium features without weakening privacy defaults

Final Thoughts

Halal Code Check reflects how I approach product delivery:

Start with a specific user pain point
Make architectural constraints explicit early
Ship a usable product fast
Keep quality and trust central as scope evolves

If you want to build a privacy-conscious consumer product with clear trade-offs and pragmatic execution, let’s talk.