Methodology

Building with Momen skips the coding, but not the engineering logic. This guide outlines the systematic approach to building applications from concept to production, ensuring your project is scalable and maintainable.

Software Development Lifecycle

A successful app usually goes through specific engineering stages. Momen visualizes these complex steps, but the core logic remains the same.

Requirements & MVP

Goal: Define “What to build” and “For whom”. Key Action: List core features and plan the Minimum Viable Product (MVP). Avoid “feature creep.”

Data Modeling

Goal: Design the underlying data structure. Key Action: Draw an ER Diagram (Entity-Relationship). Define tables (Schema) and relations. This corresponds to the Data section in Momen.

UI/UX Design

Goal: Design the visual interface and user flow. Key Action: Plan User Journeys and construct the layout using containers and basic components. This corresponds to the Design section in Momen.

Logic Implementation

Goal: Implement interactivity and business rules. Key Action: Configure frontend interactions and backend Actionflows. This corresponds to the Action section in Momen.

Publish & Iterate

Goal: Deliver and Improve. Key Action: Deploy to production and iterate based on user feedback.

Step 1: MVP Mindset

MVP (Minimum Viable Product). Beginners often fall into the trap of trying to build a full-scale platform like Facebook or Amazon immediately.

Strategy:

Subtract: Keep only the features that solve the core pain point.
Iterate: Launch fast, gather real-world feedback, then improve.

Example: “Online Course App”

Suppose you want to build an app for selling courses:

Pain Point: Instructors need a platform to sell content; Students need access to learn.
Core Roles:
- Student: Browse courses, purchase, watch videos.
- Instructor: Publish courses, manage orders.
MVP Features:
- ✅ Course List & Details
- ✅ Payment Integration (Stripe)
- ✅ Video Playback
- ❌ (Postpone) Community forums, Gamification (Points), Live Streaming

Step 2: User Journey

A User Journey is the specific path a user takes within the application to achieve a goal. Defining this clarifies what pages and logic are needed.

Example: Student Buying a Course

Entry: Open app via link or search.
Browse: View course list, filter by category.
Details: Click a card to view the introduction and preview video.
Purchase: Click “Buy Now” to initiate checkout.
Success: Payment confirmed, system redirects to “My Courses”.
Learn: Click the course to start streaming content.

💡

Tip: Sketch this flow on paper or use a whiteboard tool before opening the editor. Identify which Pages (Home, Detail) and what Data (Course, Order) are required for each step. You can also consult the AI assistant for help.

Step 3: Data Modeling

This is the most critical step in Momen. It determines what your app “remembers” and how scalable it is.

Core Elements

Table: Core objects (e.g., account, course).
Field: What each row in the table stores (e.g., name, price, description). Each field has a type, such as text, decimal, boolean, date, image, file, json, etc.
Relation: Connections between data tables.
- 1:1 (One-to-One): A account has only one profile.
- 1:N (One-to-Many): A account can place multiple orders.
- N:N (Many-to-Many): A account can take multiple courses; a course can be taken by multiple accounts(Students are a collection of accounts). Requires an intermediate table

💡

Tip: In Momen, each table has default id, created_at, updated_at fields.

id: Record’s unique identifier.
created_at: Record’s creation timestamp.
updated_at: Record’s last update timestamp.

Example: Data Model for Course App

Table	Fields	Description
account	id (bigInt), username (text), profile_image (image), email (text), phone_number (text)	Basic account info and authentication.
course	id (bigInt), title (text), cover (image), price (decimal), video_file (file), description (text)	Course content and metadata.
order	id (bigInt), status (text), amount (decimal)	Transaction records.
enrollment	id (bigInt)	Intermediate table for account-course many-to-many relationship. Records which students have access to which courses.

Key Relations:

account - order (1:N): Links the account(buyer) to their orders. All orders made by the same account can be accessed via the account’s orders relation.
course - order (1:N): Links the course(product) to the orders. All orders where this product is bought can be accessed via the product’s orders relation.
account - enrollment (1:N): One account can have multiple enrollment records.
course - enrollment (1:N): One course can have multiple enrollment records.
account - course (N:N via enrollment): Links the account(student) to the courses through the enrollment intermediate table. All courses a student has bought can be accessed via the student’s enrollment relation.

Step 4: UI/UX Design

UI (User Interface) focuses on visuals. UX (User Experience) focuses on flow and usability.

Example: Designing the Layout

Home Page:
- UX strategy: Use a List layout to display courses. Highlight the cover image and price to drive clicks.
- Momen Implementation: Use a List component, bind the course table to the data source. Add an Image component, bind the image source with the cover field. Add a Text component, bind the text content with the title field. Add a Text component, bind the text content with the price field.
Detail Page:
- UX strategy: Place the preview video at the top (Hero section). Fix the “Buy Now” button at the bottom for easy access on mobile.
- Momen Implementation: Use Relative Position to organize the video, text description, and sticky footer button.

Step 5: Logic Implementation

Finally, use Action (Frontend) and Actionflow (Backend) to connect the UI and Data.

Example: “Purchase Logic”

When the user clicks “Buy Now”, the system executes a sequence:

Create Order Record - Server-Side Security Before initiating the payment flow, you must create the order record on the server side. ⚠️ Critical Security Principle: Order creation logic must be executed within an Action Flow, not directly from the frontend database operations.

Config: Create an Action Flow with the following logic:
1. Receive Course ID and User ID from frontend
2. Query course data on the server to get real price and stock information
3. Perform necessary validations (e.g., sufficient stock, valid price)
4. Create an order record with Pending status using the server-retrieved real price
5. Return Order ID and amount to frontend
Why:
- 🔒 Prevent Price Tampering: Frontend cannot manipulate price, stock, or other sensitive data
- ✅ Ensure Data Consistency: Server-side unified business logic validation
- 📊 Traceability: Provides a reliable Order ID anchor for subsequent payment processes

Call Payment Action - Bind Server-Verified Context

Config: Bind the server-returned order.id, amount, and currency (from Step 1) to the Payment action’s input parameters.
Why:
- 🔒 Security: Use the server-verified amount returned from Step 1, not client-side values that could be tampered with
- 📌 Traceability: Pass order.id so the payment callback knows which order to update
- ✅ Data Integrity: Ensure the payment gateway receives the exact amount validated by your server

Handle Business Logic This is where the core business rules are defined. Momen provides a built-in Actionflow that triggers automatically by payment gateway webhook.

System Auto-Handling: The system automatically records a Payment Record and parses the payment result into different branches.
User Config: Inside the built-in Actionflow, locate the “Success” and “Failed” branches to add your business logic:
- Success: Change the order.status to Paid, create an enrollment record to grant access to the course.
- Failed: (Optional) Change the order.status to Failed, log the error and notify the user.
- Processed: System automatically skips to prevent duplicate processing. No user configuration needed.
Why:
- Frontend Risk: Logic running in the browser (Frontend) is untrusted because users can use developer tools to manipulate variables or fake a “Success” signal to bypass payment.
- Backend Security: This Actionflow runs in a trusted server environment completely isolated from the user. It relies on a direct, verified signal (Webhook) from the payment provider to the server. Since the user cannot touch or intercept this server-to-server communication, it is impossible to spoof a payment.