home / work and case studies

Work and case studies

Real systems. Honest status.

The archive includes client builds, operational systems, public demos, and a live App Store product. Each case says what is live, what is simulated, what problem it addresses, and what Leon built.

Get a fixed quote

Selected work

Business problems, working interfaces, and inspectable evidence.

Operational client system · ALLCPR

ALLCPR Site Intelligence

Problem: ALLCPR needed a consistent way to compare where to open, staff, and grow instead of manually searching maps or trusting one headline score.

Built: Leon built a location-planning system from a reviewed project dataset containing 33,772 U.S. ZIP-code records. It brings together targeted local-business map data, public business and facility data, ALLCPR's history, uncertainty ranges, reasons for and against each area, maps, and Excel exports for the team.

Reliability check: Leon found and removed a misleading validation loop, so the platform shows uncertainty instead of presenting false confidence as fact.

Decision boundary: The platform prioritizes markets to investigate. Rent, parking, classroom fit, instructor coverage, and current local conditions still require human field validation before opening.

Role: data product and full-stack developer · ALLCPR client project

ALLCPR Site Intelligence

“Leon built a system that helped us evaluate and plan new locations as ALLCPR expanded. It became a useful part of how we approached opening branches and supported our growth to more than 300 locations. He understood the business problem and built something practical that we could actually use.”

ALLCPRCPR training network

Read the full case study →

beastypages.com catalog of local-business destinations

Client website project · demo checkout

beastypages.com

Problem: A client needed a phone-first website for browsing local-business pages and menus in one consistent interface.

Built: The September 4, 2026 review snapshot contained 37 businesses, with search, business-specific menus, a prototype cart, server-side repricing, and vendor-separated demo tickets.

Honest boundary: Payment and kitchen progression are simulations. The client claim is for the website build, not a production ordering rollout.

Role: website and full-stack developer · client identity withheld

Read the full case study →Open a live business page →

Live product · App Store

Curio

Problem: Turn passive scrolling into short, source-backed learning.

Built: The React and TypeScript client, native iOS shell, Express and Postgres backend, subscriptions, content pipeline, and four-language in-app content experience.

Public proof: The product is downloadable on the U.S. App Store and its public founder profile identifies Leon's role.

Role: solo product developer

Read the full case study → Open on the App Store → View the founder profile → See mobile app development →

Labelled implementation diagram of Leon's seller-portal contribution, not a production screenshot

Client product contribution · existing product and design

LOQOL seller portal

Problem: Sellers need to complete long disclosure forms without losing the answer they are still writing.

Contribution: Built parts of the existing portal to connect answers to seller records, request automatic saves, and protect unfinished text during background updates.

Role: frontend implementation within the team's existing product and design

Read the contribution case →

Loqol seller questionnaire with conflicting public-sewer and septic-tank answers saved

Three-page California disclosure PDF generated from saved Loqol answers

Public demo · incomplete signing and email steps

Loqol disclosures

Problem: Translate a dense California disclosure form into a guided seller workflow.

Built: An 82-question seller flow, 16 consistency rules, an agent review workspace, saved answers, and a three-page PDF output.

Honest boundary: Buyer and agent signing plus seller email delivery are not complete.

Role: full-stack product developer

Open the public demo →

Additional project archive

Operational patterns behind the interfaces.

These anonymized project notes preserve useful implementation detail. They are not presented as public client demos or outcome guarantees.

Internal workflow · client anonymized

Review desk

Problem: Review notifications arrived faster than a small team could classify and answer them consistently.

Built: An inbox workflow that classifies the issue, drafts from verified business facts, and routes a Gmail draft, Slack card, and sheet row to a person.

Control: The workflow never posts a reply. A human reviews and sends it.

Internal workflow · client anonymized

Document control

Problem: Company documents and approvals lived across folders, inboxes, and memory.

Built: A template request creates and files the document; approval locks it; publishing increments the version, writes the change log, and exports the external PDF.

Handoff: The workflow was implemented in Apps Script and as six editable n8n workflows.

Regulated-market prototype · Chinese language

Compliance-aware assistant

Problem: Health-education answers needed source citations and deterministic safety limits in a market with strict advertising rules.

Built: Safety screening before the model, hybrid retrieval, evidence tiers, numbered citations, and a final legal-claim validator.

Control: If a revised answer still fails validation, the assistant declines rather than guessing.

This is Leon's current public work archive. Each entry states what is live, incomplete, or anonymized.

Get a fixed quote Need help choosing what to build? Start here →More about Leon →