Soulful Asia

The project started with a real social need, not with a website brief. From my own experience and from repeated conversations in migrant and community contexts, I saw the same pattern again and again: people needed trustworthy support, culturally legible information, and lower-friction ways to participate in a new environment.

At the same time, the association itself needed an operating structure. Brand communication, event publishing, courses, publications, membership, certificates, and internal coordination were being handled across manual processes and scattered tools. I reframed the work as an organisational digital infrastructure project rather than a simple website build, because both the public service side and the internal operating side had to be solved together.

This reframing changed the whole project. Instead of asking, "What pages should the website have?", I asked, "What system does the organisation need in order to build trust, support participation, and keep operating sustainably?"

This was not a case where one neat round of user interviews produced a fixed requirement list. I was working in an early-stage context, so the research approach combined founder insight, qualitative observation, and continuous feedback from highly engaged participants and collaborators.

I treated the project as a stakeholder-structured product problem. That meant identifying not only end users, but also everyone who would shape or operate the system: participants, volunteers, lecturers, therapists, counsellors, operators, and internal managers. Their needs were different, their entry points were different, and the system had to reflect those differences.

A simple brochure site could not support how the organisation actually needed to work. Events, courses, publications, member records, and volunteer participation all had to be carried through clearer structures instead of disconnected manual handling.

I therefore split the product into public-facing and operational layers. The website had to build trust and guide participation. The backend had to let the team edit content, manage members, publish events, maintain records, and support ongoing operations. I also treated the course system and app direction as connected product decisions rather than optional extras, because future service growth depended on those boundaries being thought through early.

In product terms, this was a shift from page thinking to platform thinking. The public website became the main trust and participation surface, while the operating layer became the mechanism that allowed the organisation to actually function.

One important part of this project was not only defining pages and modules, but also defining system boundaries. The main website, the course system, and the iOS direction could not be treated as isolated surfaces. Their data relationships had to be decided intentionally.

I defined the main website as the primary user system, while keeping the course system capable of supporting future independent deployment. That meant user identity, course access, and operational records had to be considered at the product level before implementation details were confirmed.

This also changed how I validated the work. I did not only check whether an API returned successfully. I also checked whether the actual user experience, system boundary, and data ownership matched my product intent.

In practice, this meant defining the main website as the primary trust and account surface, keeping the course system extensible for later independent deployment, and planning future app access as a lighter-touch layer rather than forcing everything into one interface too early.

One concrete prioritisation decision was that I did not push the app into the first release, even though it was attractive as a member-facing surface. At that stage, the organisation still lacked a stable account structure, membership logic, and operating workflow. If I had expanded into an app too early, I would have multiplied complexity before the core platform rules were stable.

I made a similar decision with bilingual support in the opposite direction: I treated it as a first-release requirement rather than a later enhancement. For this audience, language was directly tied to trust and emotional safety, so delaying bilingual structure would have weakened the product at its most important entry point.

That tradeoff shaped the first version clearly: stabilise the website and backend first, make bilingual trust-building native from day one, and leave the app as a later extension once the system skeleton and data relationships were reliable.

I did not force the organisation into a generic CRM pattern. Instead, I organised the platform around real operating objects: members, courses, certificates, publications, and events. That made the backend more aligned with how the organisation actually worked and made the system easier to maintain as the association evolved.

In this project, AI did not replace product thinking. I used it as a practical collaborator across requirement refinement, structure comparison, coding support, debugging, and implementation verification.

The most important rule was that product judgment stayed with me. I used AI to reduce execution cost and iteration time, but the decisions about stakeholders, priorities, system boundaries, and service logic were all human-led.

As a founder, my strongest advantage was being able to work backwards from organisational goals and lived user pain into product structure.

I used stakeholder mapping to avoid treating all users as one group, because participants, volunteers, lecturers, and internal operators each needed different entry points and support.

I used service-structure thinking to separate frontstage trust and participation from backstage management and operating continuity.

I used information architecture as a strategy tool, organising the website around user questions rather than around a default sitemap.

I used phased product strategy to decide what had to exist in version one and what should remain a later expansion path.

AI improved execution efficiency significantly, but product judgment, prioritisation, and system-boundary decisions still had to be made by a person.

This project also exposed where my first assumptions were too narrow. I initially thought in terms of building a better website, but the real challenge was product structure: account logic, membership levels, course access, operational workflows, and cross-surface data had to be designed intentionally much earlier.

I also learned that “AI-assisted delivery” does not reduce product responsibility. It actually raises the bar on judgment. I had to keep checking whether implementation still matched the platform logic I intended, especially when data flow, hosting, and system boundaries were not fully visible from the interface level.

The result was a deeper shift in how I work: I now treat platform boundary definition, infrastructure risk, and execution verification as part of product design, not as something to think about only after launch.