13 · Founder, WebCanBe
Min Sihoo · Founder, WebCanBe
I'm Min Sihoo, a 13-year-old founder building WebCanBe and a growing set of software, AI, and research projects.
Business, contracts & payments. Because I'm 13, the parts of the business that require an adult counterpart are set up that way. My mother and I have an explicit agreement covering the business, and contracts, payment accounts, and related legal or financial matters that require an adult are handled through a parent-held structure. Clients are therefore working with an adult-backed contracting and payment setup rather than being asked to rely on a minor acting alone.
My work moves between source-owned web software, AI systems, operations, marketplaces, security tooling, and long-form research. I care most about projects where the underlying system can be inspected, owned, tested, and improved.
This site is the working archive: what I built, what changed direction, what survived, and what I am still trying to solve.
A source-owned web workspace and marketplace built around one principle: visual editing should operate on the real project rather than replace it with a closed representation. The same project is intended to move across visual editing, direct code work, AI changes, preview, versioning, export, and deployment.
A long-running attempt to build a practical personal AI that can listen, reason, remember context, route tasks, use tools, queue actions, and ask for confirmation before sensitive operations. The architecture has included speech transcription, model routing, memory/context storage, tool adapters, queued execution, and speech output rather than a single chat prompt pretending to be an assistant.
A long-form attempt to push on the Beal Conjecture while keeping an unusually strict standard for what counts as progress: only a complete general proof or an explicit primitive counterexample counts as a solution.
The research log has covered primary-source theorem audits, exponent and coprimality reductions, Frey-curve and modular directions, multi-Frey methods, effective finiteness, S-unit and height bounds, primitive-divisor arguments, and repeated adversarial checks for hidden assumptions, exceptional primes, and circular reasoning.
Every serious step is classified as known, derived, candidate, refuted, or not yet verified. Failed routes stay in the record so the project becomes more accurate instead of merely looking more successful.
A systems research project around reconstructing and reading carbonized scrolls from volumetric scans: geometry, surface extraction, unwrapping, ink detection, reproducibility, and human-verifiable evidence.
The project is structured around the actual challenge constraints rather than a demo-only model: bounded human input, clean train/prediction separation, preserved character geometry, reproducible pipelines, disclosed artifacts, and inspection of intermediate coordinate states.
The key idea is that the pipeline itself is part of the scientific result. A strong ink model cannot rescue bad surface geometry, and an attractive render is not enough if the underlying mapping cannot be audited.
Store integration, inventory-state modeling, safety-stock logic, stockout-risk detection, reorder proposals, and approval workflows — moving the product from passive dashboards toward operations software.
A seller/host marketplace for distributed storage and fulfillment, with role-specific workflows, requests and approvals, inventory state transitions, QR-based movement, and the trust layer required after the initial match.
A fast-built SaaS for evaluating ideas, surfacing risks, generating execution plans, comparing directions, and tracking progress. The important transition came when the technical prototype was complete enough that distribution became the larger unknown.
A Shopify-oriented workflow for combining deterministic rules, AI-assisted thresholds, and human approval instead of blindly automating consequential refund decisions.
The recurring theme in my work is simple: keep the real system visible, then make it easier to operate.
Why visual editing only matters to me if the real code stays visible, editable, portable, and owned.
What changes when an assistant has a pipeline, tools, memory, queues, and permission boundaries instead of only conversation.
Why keeping the boundary between a promising route and a proof matters.
Why a source-editing product needs an explicit environment model before it promises universal visual editing.