Crowdlinks PMF Prototype

MVP First Phase

We built the MVP for the new business “CrowdLinks” using the following architecture and conducted PSF (Problem-Solution Fit) validation.

Some features were intentionally left unimplemented and operated manually to deliver the overall user experience—an example of a so-called “Wizard-of-Oz” style MVP.

MVP Post Problem-Solution Fit Phase

Tech Stack

Main Application

Media Application

Build & Development Tools

Core Technical Components / Decision Making

Monorepo

We chose a monorepo structure based on the team’s situation. The main goal was improving developer experience (DX) for better productivity.

Given our business status and a small team (only 3 engineers), it was inefficient for each person to separately handle frontend, backend, and infrastructure tasks. We needed everyone to cover all areas, but a multi-repo setup would require constant repository switching during development and reviews.

We judged that this cross-repo overhead was non-essential and wasteful. Thus, we adopted a monorepo to eliminate this switching cost.

Pros 👍

• Completely eliminates repo-switching tasks
• Simplifies dependency management between projects
• Improves code sharing and reusability across projects
• Easier to enforce consistent coding standards and tools
• Enables atomic commits across multiple applications

Cons 👎

• Onboarding Cost, Setup Cost: Requires solid understanding of CircleCI to optimize deployment flows; onboarding new members may incur learning costs
• Potential for longer build times if not properly optimized

Adding Media Application as a Microfrontend

We integrated a media-oriented Nuxt application within our monorepo as a microfrontend. This approach allowed us to:

BLoC Pattern: Separating State and Presentation

After finding Atomic Design led to components with mixed responsibilities, we adopted the BLoC (Business Logic Component) pattern to create clearer separation of concerns:

• Presentation Components: Handle UI rendering and user interactions
• BLoC Components: Manage state, business logic, and data flow

This approach eliminated ambiguity in component responsibilities and improved maintainability.

RBAC Implementation for Permission Management

As user roles became clearer, we implemented Role-Based Access Control (RBAC) to simplify authorization logic and eliminate code duplication.

Approach: Tell, Don’t Ask

Before: Permission checks were scattered throughout components, with each fetching data and implementing logic (Ask pattern).

After: Centralized permission checking through a dedicated function (Tell, Don’t Ask pattern).

Example: Project Apply Button

Before - Logic embedded in component:

<button v-if="isAppliable" @click="apply">
    Apply for Project
</button>
</template>

<script lang="ts">
  computed: {
    currentUser(): CurrentUser | null {
      return this.$store.getters[CURRENT_USER_GETTER]
    },
    currentUserProfile(): UserProfile | null {
      return this.$store.getters[CURRENT_USER_PROFILE_GETTER]
    },
    isAppliable(): boolean {
      return (
        this.currentUser !== null &&
        this.currentUserProfile !== null &&
        this.currentUserProfile.hasEnoughProfile()
      )
    }
  }
</script>

After - Delegated to permission checker:

<button v-if="isAppliable" @click="apply">
    Apply for Project
</button>
</template>

<script lang="ts">
import { checkPermission } from "~/supports/auth/permissionChecker"
import { ParticularWriteAcl } from "~/config/acl/accessControlList"

  computed: {
    isAppliable(): boolean {
      return checkPermission(this.$store, ParticularWriteAcl.PROJECT_APPLY)
    }
  }
</script>

This abstraction centralizes permission logic, making it easier to maintain and modify access rules without touching component code.