← Selected work

Mission tech / privacy

Hanuri Missions

A bilingual mission-support product prototype designed around church leadership, missionary support groups, member privacy, and practical communication. The implementation remains private; the portfolio exposes only stakeholder-facing artifacts that demonstrate product thinking without exposing source code or sensitive ministry data.

Stakeholder communication, not private infrastructure

Leadership context informs bilingual materials for stakeholder review. Feedback can refine the explanation while private implementation and ministry data remain outside publication.

Publication boundary Conceptual communication pattern only. No application topology, member records, access rules, or unpublished artifacts are exposed.

  1. 01 · Stakeholder boundaryLeadership context

    Explain the mission-support problem.

  2. Translate the problem
    02 · Communication boundaryBilingual materials

    Describe the concept for ministry stakeholders.

  3. Support discussion
    03 · Human review boundaryStakeholder review

    Discuss the concept without publishing private implementation.

Feedback: Stakeholder review → Bilingual materials
Conceptual feedback loop

Publication concern: expose only the rationale needed for review, not sensitive ministry data. Named artifacts are not treated as publicly downloadable evidence.

Public-summary abstraction reviewed ; not employer approval.

Selected portfolio artifacts

Leadership infographic · Korean

hanuri-missions-hanuri-ko.png

A church-facing visual explanation of the product and its leadership model. It is included because it shows bilingual product communication and the ability to translate a technical system into a form usable by ministry stakeholders.

Shareable handout · Korean

hanuri-missions-hanuri-ko.pdf

A distribution-ready version of the same stakeholder narrative. It is included because the work is not only app implementation; it also required packaging the concept for review, discussion, and real-world adoption.

Why these artifacts, and not the repository

The portfolio should demonstrate product judgment, bilingual communication, privacy awareness, and mission-domain translation. Those signals are visible in the leadership materials. Publishing the private source repository would add implementation detail without improving those signals, while increasing the chance of exposing internal design assumptions, prototype account structure, or ministry-specific information that does not belong in a public portfolio.

Publication boundary
  • Included: the Korean leadership infographic and its PDF handout as named portfolio artifacts.
  • Excluded: source code, repository links, credentials, internal implementation details, and private operational data.
  • Excluded: prototype details that are not necessary to explain the stakeholder problem or design rationale.