---
title: "How we build a monday.com app"
description: "We built one monday.com app, a board view that writes a short AI summary of a board, and submitted it in August 2026. It was rejected in September for overlapping apps that already exist. The build method held up; the step we skipped was asking monday, before writing code, whether the concept would clear its duplication policy."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/how-we-build-a-monday-app/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Apps / monday.com
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/cum-construim-o-aplicatie-monday/
---

# How we build a monday.com app

*We built one monday.com app, a board view that writes a short AI summary of a board, and submitted it in August 2026. It was rejected in September for overlapping apps that already exist. The build method held up; the step we skipped was asking monday, before writing code, whether the concept would clear its duplication policy.*

> Apps · monday.com · 2026-10-11 · https://goingstellar.ro/methods/how-we-build-a-monday-app/

## Key points

- Before building a monday.com app, ask monday in writing whether the concept clears its duplication policy; that step needs no code and can save a rejection.
- monday's duplication policy covers functionality, not only third-party connectors, and it treats slight interface tweaks and minor feature additions as no new value.
- The monday.com submission form is the strictest and most current source of requirements, stricter than the developer documentation or the listing terms.
- When every API call from a monday board view fails with GraphQL validation errors, even on the simplest query, the app usually has no scopes rather than a broken query.
- Letting monday host the app code removes work from the security review, such as logging of signed session tokens and describing your own secrets in the privacy answers.

## What this is, and where it stands

monday.com lets developers add views, widgets and integrations to its boards and sell them through its marketplace. We built one app there, Recap: a board view that reads a board and writes a plain-language summary of what moved, what is blocked and what is due, exportable as a PDF. We submitted it on 16 August 2026. On 28 September monday's reviewer rejected it, saying its functionality overlapped significantly with solutions already available and that the AI feature did not add meaningful value. It is not listed, and we are not building a second monday app.

What follows is the method we used, which mostly worked, and the decision we got wrong, which did not.

## Read the form before the docs

The binding requirements are spread across the developer documentation, the marketplace listing terms and the submission form, and the form is the strictest and the most current of the three. Three of its rules change what you build. Since 13 August 2026 it states that monday only accepts apps with AI capabilities, a rule we found in no developer document. Billing must go through monday's native monetisation. No-code and "vibe-coded" apps are not eligible.

A fourth rule decides whether to build at all. monday's quality and duplication policy bars a new app whose main purpose duplicates an existing integration, even a better one, and says that slight interface tweaks and minor feature additions are not new value. We read it as a list of forbidden third-party connectors. The rejection showed it also covers functionality.

Demand data is easy to get. The marketplace is fed by public JSON with exact install counts per app; join the files on `app_id`, never on `id`, which silently mis-joins. Split by launch year, the 2026 cohort of 235 apps had a median of 5 installs when we measured it in August. We recorded that and built anyway, as a single bet.

## Building the board view

The app is a board view: a front end in an iframe using monday's SDK, plus a backend that verifies monday's signed session token and asks a language model for one paragraph. The order matters: create the app, add a board-view feature, point it at your build, grant scopes on a draft version, promote that version to live, and only then install. An install made while the version was still a draft does not bring the view into the board.

The traps we hit. The CLI command that creates an app crashes without a terminal but still creates the app, so list your apps before retrying or you get duplicates. A promoted version is locked, and edits to it silently revert until you create a new version. When every API call from the view fails with *Graphql validation errors*, including the simplest possible query, the app has no scopes; your query is fine. And the install consent screen is the only honest record of what you ask for: ours requested profile access our own paperwork said we did not need, so we removed it.

We tested the renderer outside monday by feeding it a real board as JSON. That caught a status called "Fixed" that our code did not count as done, so the report showed zero completed items where 3 were resolved. Invented test data, where everything finished is called "Done", would have hidden it.

## Let monday host it

monday can host app code itself, and its own form says that doing so lightens the security review. We hosted Recap ourselves and paid for it. The signed session token, which monday puts in the view's URL, was being written into our web server's access logs; we had no defined retention period for those logs; and our secrets had to be described in the privacy answers. None of that exists when monday hosts the code. Decide this when you scaffold the app, not after the security questions arrive.

## Audit before filing

Before filing we ran an adversarial audit with 14 agents over the code, the listing text, the published legal pages and monday's documentation. It returned 45 raw findings; 7 survived refutation, and the verdict was "not ready". The classes worth checking on any app: claims about competitors that are not true (we had described the incumbents as template-based tools, when several were zero-setup board views and one already wrote an AI recap, and that claim sat in the very field monday uses to judge duplication); privacy text that promises more than the code does; a status classifier that counted "Unpaid" and "Not approved" as completed; a third theme, black, besides light and dark; and declaring mobile support for a PDF button that does nothing in the mobile app.

## Filing

The long-text fields stop at 2,000 characters and turn the counter red instead of truncating, so an over-long answer looks fine until it blocks the form. One of ours had to go from 2,672 characters to 1,994. Some steps belong to the account owner and cannot be automated: accepting the developer terms, a binding support commitment of 2 business days, and a signature image.

We filed with the wrong pricing answer and nearly withdrew over it. The documentation says initial pricing is reviewed inside the running review, so it was correctable there; the one choice that cannot be changed later is the pricing model. monday's first response is due within 72 business hours, and the rest of the review runs on a shared board.

## Where we were wrong

Our own assessment from August said not to build for monday at all, with one exception, Recap, and only after getting written pre-clearance of the concept against the duplication policy: a step that needed no code and about 72 business hours. We filed the app the same day and never asked. We learned the answer from the rejection instead.

The rejection itself arrived by email on 28 September and sat unread for 7 days. Our mail watchdog searched only for the Atlassian review sender, and we reported "no new mail" when what we had checked was one sender. The check now starts with a broad search and states which channels it covered.

The competitor claim above belongs here too. We caught it before filing, but the reflex to describe neighbours as weaker than they are is exactly what a duplication review tests.

## Limits and checklist

The build steps held: the view worked on real boards and passed our own audit. That says nothing about whether monday wants the app or whether anyone would install it, and both questions are answered before the first line of code.

**1. Pre-clearance.** Ask monday in writing whether the concept clears the duplication policy before building.

**2. The form.** Read the live submission form, not last month's notes; plan a real AI feature from day one.

**3. Hosting.** Default to monday's hosting unless there is a specific reason not to.

**4. Scopes.** Read them on the consent screen and remove any you do not use.

**5. Audit.** Check competitor claims, privacy text, status logic, themes and mobile before filing.

## Questions and answers

### Why would a monday.com marketplace app be rejected?

A monday.com marketplace app can be rejected for overlapping with solutions that already exist. monday's quality and duplication policy bars a new app whose main purpose duplicates an existing integration, even a better one, and treats slight interface tweaks and minor feature additions as no new value. One AI board-summary app was rejected on those grounds, with the reviewer also saying the AI feature did not add meaningful value.

### What are the main requirements for submitting a monday.com app?

The main requirements for submitting a monday.com app are set out most strictly in the live submission form. The form states that monday only accepts apps with AI capabilities, that billing must go through monday's native monetisation, and that no-code and vibe-coded apps are not eligible. Some steps belong to the account owner, such as accepting the developer terms, a support commitment and a signature image.

### Why does my monday.com board view not appear after installing the app?

A monday.com board view often fails to appear because the app was installed while its version was still a draft. The order matters: create the app, add a board-view feature, point it at your build, grant scopes on a draft version, promote that version to live, and only then install. A promoted version is locked, so further edits need a new version.

### Should I host my monday.com app myself or let monday host it?

Letting monday host the code is usually the better default for a monday.com app, because monday's own form says it lightens the security review. Self-hosting means the signed session token that monday puts in the view's URL can end up in web server access logs, those logs need a retention period, and secrets have to be described in the privacy answers. This decision belongs at scaffolding time.

### What should I audit before submitting a monday.com app?

Before submitting a monday.com app, audit competitor claims, privacy text, status logic, themes and mobile support. Claims that describe existing apps as weaker than they are can sit in the very field monday uses to judge duplication. Privacy text should not promise more than the code does, status classifiers should not count unpaid items as done, and the app should handle a third, black theme besides light and dark.

## How to cite

**Cite this as:** Going Stellar (2026). *How we build a monday.com app*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/how-we-build-a-monday-app/

```bibtex
@misc{goingstellar2026how,
  title  = {How we build a monday.com app},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/how-we-build-a-monday-app/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/how-we-build-a-monday-app/
- Same article in Romanian: https://goingstellar.ro/ro/metode/cum-construim-o-aplicatie-monday/