Skip to main content

Can a non-techie build an app? Witness the joy (and the video)!

  • March 1, 2026
  • 1 reply
  • 50 views

OmerK
Forum|alt.badge.img+1
  • monday.com Team Member

Hey Community! For those of you who don’t know, I’m not a technical person, but we've had our Apps MCP for about 3 months, so I decided to challenge myself by building a simple to-do list application for monday with it.

You can check out my journey, which documents:

  • The step-by-step process of using monday.com Apps MCP to construct a functional tool.

  • Creating a solution with task lists and checkboxes to manage items like cooking dinner or cleaning the house.

  • And yes - it took some “prompt fixes” from my side, but in less than 30 minutes (less than 22 minutes, originally) the app was up!

Check out the full video linked below for the complete build walkthrough and share that excitement!

Let me know in the comments: what’s one small, useful app you'd love to build for yourself or your team without needing to code? Or - what would you add to your existing app/s leveraging the Apps MCP?

 

1 reply

OmerK
Forum|alt.badge.img+1
  • Author
  • monday.com Team Member
  • March 3, 2026

Sharing here the full prompt I used:
 

Act as a Full Stack Developer. Build a monday.com Board View app from scratch using the monday SDK and React. The app will be used for a live demo recording, so it must be complete, deployable, and visually polished.

Requirements

1. Project setup

Use the official monday.com apps workflow: install @mondaycom/apps-cli (mapps) and scaffold the quickstart-react template into the project folder with mapps app:scaffold ./ quickstart-react (or, if scaffolding fails, create a React app with Vite + React and add monday-sdk-js and wire it like the quickstart).

Ensure the app can run locally with npm run server (Vite) and that the Board View feature is configured in the monday.com Developer Center with boards:read and boards:write OAuth scopes.

Remove or work around any dependency that blocks npm install (e.g. optional removal of @mondaycom/apps-cli from project devDependencies if its postinstall fails; use global mapps for deploy).

2. Data integration

Context: Get boardId from the monday context using monday.get('context') and monday.listen('context', ...) in the main view. Handle the case where the view is opened outside a board (show a friendly message).

Fetch items: Call the monday GraphQL API to load board items. Use a query like boards(ids: $boardId) { items_page(limit: 500) { items { id name column_values(ids: ["status"]) { id value text type } } } }. Parse each item into { id, name, statusText, isDone } where "Done" means checked.

Create item: Implement a mutation create_item with board_id, item_name, and optional group_id / column_values. Expose it in a small API layer (e.g. src/mondayApi.js).

Update status: Implement a mutation to update the status column (e.g. change_simple_column_value or change_multiple_column_values) so that toggling "Done" in the app updates the board. Use status labels like "Done" and "Working on it" (or match the board's status column).

3. State management

Keep the list of items in React state (e.g. useState). When boardId is available, fetch items and set state.

When the user checks or unchecks a box, call the update-status mutation then refetch the list (or update state optimistically) so the board and app stay in sync.

When the user adds a new item via a form, call the create-item mutation then refetch (or append) so the new item appears in the list.

No global store is required; local component state plus the monday API is enough.

4. UI/UX – Windows XP (Luna) aesthetic The interface must strictly follow a Windows XP look and feel:

Title bar: A full-width bar at the top with the signature blue-to-bright-blue vertical gradient (e.g. #0054e3 → #238edb). White text, bold. Rounded top corners on the main window.

Main window: White or light gray content area, rounded corners (e.g. 8–12px) on the outer container, subtle border (e.g. 1px solid #0054e3 or gray). Clear separation between title bar and content.

Icons: Pixel-art style icons (e.g. 16×16 or 24×24, hard edges, minimal or no anti-aliasing). Use inline SVG or small PNGs. Place an icon in the title bar and, if desired, next to the "Add" button.

monday color palette: Use as accents and for status:

Green (e.g. #00c875) for success / "Done" state (e.g. checked checkbox).

Yellow (e.g. #ffcb00) and red (e.g. #ff4757) available for status or accents.

Checkbox: Style as a classic checkbox (square border, checkmark when "Done"). Map checked state to the status column value used for "Done."

Typography: System fonts that resemble XP (e.g. Tahoma, Segoe UI, or similar sans-serif). Keep layout compact and list-based.

Implement in a single CSS file (e.g. src/App.css) with classes for the root container, title bar, list, and list rows. Avoid heavy UI libraries that override this aesthetic.

5. Robustness and deployment

Error boundary: Wrap the root app in a React error boundary so any uncaught error shows a short message (e.g. "Something went wrong" + error text) instead of a blank screen.

Safe SDK usage: Wrap monday.execute, monday.get("context"), and monday.listen("context") in try/catch or promise catch so failures don't crash the app. Show "Loading…" until context is loaded, then either the list or "Open this view from a board to see items."

Embedding fix (critical): When the Board View is embedded inside monday.com, the iframe document may be on monday's domain. Relative asset paths (e.g. ./assets/index-xxx.js) then resolve against monday's URL, so the browser requests the JS from monday.com and gets HTML (wrong MIME type) → blank screen. Fix: Build the app with absolute base URL pointing to the deployment CDN (e.g. in Vite set base: 'https://YOUR-DEPLOYMENT-URL.cdn2.monday.app/' or use an env var like VITE_CDN_BASE). After the first deploy, use the URL returned by mapps code:push as the base so that script and link tags in index.html are absolute and always load from the CDN.

HTML fallback: In the built index.html, inject a visible "Loading…" div inside #root (e.g. via a Vite transformIndexHtml plugin) so that if the HTML loads but the script fails, the user sees something instead of a blank screen.

6. E2E testing and deploy

Add a minimal E2E suite (e.g. Playwright): build the app, serve the build (e.g. vite preview --port 8302), and test that the XP window and a "no board" or "Loading…" message appear when opening the app without monday context. Document how to run E2E (e.g. two terminals: one for serve, one for E2E_BASE_URL=... playwright test).

Deploy: Build with npm run deploy:build (or equivalent), then run mapps code:push --client-side -d build -i <APP_VERSION_ID> using the draft app version ID from the Developer Center. In the Developer Center, set the Board View feature's Feature deployment to "Client-side code via CLI" and select the deployment. Promote the version to Live when ready for the demo.

README: Include short instructions for: OAuth scopes (boards:read, boards:write), running locally, running E2E, and deploying (build → code:push → connect deployment → promote). If the CDN base URL can change, document rebuilding with VITE_CDN_BASE=https://NEW-URL/ npm run deploy:build before pushing.

Deliverables

A working Board View app that: (1) lists board items with checkboxes mapped to status, (2) allows adding new items, (3) syncs checkbox toggles to the board via the monday API, (4) uses the Windows XP aesthetic and monday color palette, (5) works when embedded in monday.com (no blank screen) thanks to absolute CDN asset URLs, (6) shows clear loading/error states and survives SDK errors without a blank screen.

Clear steps to run locally, test E2E, and deploy to monday.com for a live demo recording.