Cursor Build Live Apps: a competitor review board for under 1 cent a day

Cursor shipped Build Live Apps on November 5, 2026. In a cloud agent, you say "build an app," and Cursor builds a web app. It adds Postgres when needed, sets up Cursor sign-in, hosts the app, and gives you a link.

We used the Cursor docs to design a competitor review board for a three-person team that builds a budgeting app. Every morning, the board fetches the newest YNAB and Monarch reviews from the App Store, Google Play, and Trustpilot. It also fetches Reddit posts that discuss the two apps together. The server calls only POST /api/v1/social on EveryInfra. The key is a Cursor team secret, and the code reads only the variable name. The browser and the agent never see the value.

We did not run the Cursor side, so the prompt, the refresh route, and the scheduler are config examples. We called the data side for real on the evening of November 13, 2026. We ran the board's set of calls at three times: 21:31, 22:14, and 22:36 Singapore time. We also added Fintonic, a budgeting app in Spain, as a control, to see what the same method returns in a non-English market.

First, one daily refresh needs 7 calls and costs $0.009126 at catalog prices, or about $0.27 per 30 days. That is less than 1% of one Premium seat.

Second, the 30 newest App Store reviews did not change in any round. The newest review was already 56.7 to 58.7 hours old. Store reviews become public one or two days late, so an hourly refresh only multiplies the bill by 24. Third, Google Play and Trustpilot returned 503 in the first two rounds. We were not charged, and the retry in round 3 worked. The board must record the last good refresh for each source, so that one source that did not refresh does not block the others.

The round 3 data also showed one more pattern. On Trustpilot, 18 of the 20 newest YNAB reviews came from company invitations, and 75% were five stars. All 20 Monarch reviews were organic, and 90% had one or two stars.

What Cursor Build Live Apps is

Cursor shipped Build Live Apps on November 5, 2026. The changelog entry starts with a plain claim: agents made code cheap to write, but most apps that users build never leave localhost. The release moves that last step into Cursor. You describe the app, and Cursor builds it, sets up a database, configures sign-in, deploys it, and returns a link. The docs list the feature under Cloud Agents on the Apps page.

The feature works only in a cloud agent. The docs say it directly: use a cloud agent, because the feature is not supported locally. A cloud agent is a coding agent that runs in its own virtual machine in Cursor's cloud. It has a full development environment (Cloud Agents docs). You can start one from the desktop app, the web app, the iOS app, Slack, a GitHub comment, Linear, or the API. So a product manager can type one request on a phone, and the agent can build, preview, and publish the app in the cloud.

The big change from August is hosting. On August 27, 2026, Cursor shipped Start from scratch. That release could also publish to a live URL, but it said that a Vercel account was required. The November release removes that step. The Apps docs say that Cursor creates a dedicated hosting account for each team, or for each person on an individual plan. Each account is isolated from all other teams and users.

The New Stack reported on November 5 that Vercel said on X that the feature runs on Vercel for Platforms. Cursor's own docs do not name a hosting company. In this article we use the docs wording, "hosted by Cursor." For a review board, three facts matter more than the hosting company. They are where the secrets live, who can open the app, and how the data gets refreshed.

These parts of the docs matter for a competitor review board:

Some things are not in the docs, and we do not want readers to assume them. The docs do not give a hosting region. They do not give a Postgres size limit or a backup schedule. They also do not mention a built-in scheduler for apps. Without a built-in scheduler, you must add a trigger yourself. The section on triggers covers three ways.

Who can use it and what it costs

The Cursor pricing page, read on November 13, 2026, lists five tiers. They are Free at $0, Plus at $8 per month, a $30 tier, Super at $100, and Ultra at $200. The $30 tier has no name on the card, but the Super card says "Everything in Premium." So the $30 tier is Premium. "Cloud agents & automations" first appears in the feature list at that tier.

The troubleshooting section of the Cloud Agents docs is more direct. You need a plan that includes cloud agents: Premium and higher, Teams, Enterprise, or a legacy paid plan. Free and Plus do not include them. The changelog says the feature is "available on all paid plans with cloud agents enabled." Read together, the entry point is Premium.

The plan fee is not the whole cost. The billing section of the Cloud Agents docs says that cloud agents use your plan's usage at the rate of the selected model. Cursor asks you to set a spend limit the first time. The pricing page also says that third-party model usage is not included in the monthly price and is billed separately.

So the model cost to build the board depends on how many rounds you ask the agent to do and which model you pick. We did not run the agent in Cursor, so we cannot give a number for that part. One part is certain. After you publish the board, the daily refresh is ordinary server code that calls an API. It does not call a model, so it does not add model cost.

For a team of three to five people, one Premium seat is enough to build and publish. If other people must open the board, you have two choices. You can use Teams, so that everyone signs in to Cursor. Or you can use an individual plan and share the link publicly. Public reviews are not private data, so a public board is technically possible. But a board usually also holds your own notes and decisions, so we keep it behind sign-in.

The three questions the board must answer

Take a specific team. Three people build a budgeting app, and their direct competitors are YNAB and Monarch. This market changed fast in the last four weeks. On October 21, 2026, Monarch reopened its MCP connector, so users can ask Claude, ChatGPT, or Cursor about their own budget data.

On November 5, Anthropic launched Personal Finance in Claude. It is a beta for Pro, Max, and Ultra users in the US. Users link bank accounts through Plaid, and access is read-only. On November 4, Apple made retention messages available for auto-renewable subscriptions. A daily look at how competitor users react to these changes is more useful than a monthly survey.

We gave the board three questions, and each question has its own data set. First, what do recent low-star reviews of each competitor complain about? The data is the newest App Store and Google Play reviews, grouped by star rating and by topic. Second, does each competitor look the same on different sites? App store reviews come mostly from phone users. Trustpilot reviews are often long posts about billing, refunds, and support.

Third, which way are users moving? Reddit posts such as "moved from YNAB to Monarch" or "looking for a YNAB alternative" show user flow before star ratings change. These three questions set the scope to four capabilities. They also set the refresh rate. Reviews and posts do not change minute by minute, so one refresh per day is enough. A later section calculates the daily API cost from live calls.

We also added a control: Fintonic, a budgeting app in Spain (App Store ID 672220319, Google Play package com.fintonic, Trustpilot domain fintonic.com). It is not on the board.

In the live test, we called it with the same parameters as YNAB and Monarch. It answers two questions. What do country: es App Store reviews and Spanish Google Play reviews look like? How different are its review speed and low-star topics from the US competitors? Every Fintonic number below comes from these control calls.

Four capabilities in one table

All four capabilities use the same EveryInfra endpoint, POST /api/v1/social. Only platform, action, and params change. The parameters, prices, limits, and fields in the table come from the free EveryInfra catalog. We read it on November 13, 2026 at 21:30 Singapore time (13:30 UTC).

The catalog also lists some parameter details that are easy to get wrong. The App Store app_id is the numeric ID from the store link, not a bundle ID such as com.example.app. Google Play is the opposite. It needs the package name, and you cannot paste the full store URL. Google Play reviews change with language only. In the same language, us and gb return the same reviews.

Trustpilot needs the company website domain. Its date filter accepts only fixed values such as last7days or last30days. Reddit search always covers the last month. It returns only posts that match the keyword in the title or body. When no post matches, the call counts as an empty result and you get a refund.

Each platform page lists every capability on that site. See App Store Scraper API, Google Play Scraper API, Trustpilot Scraper API, and Reddit Scraper API.

The data flow: the browser talks only to the app, and the key stays on the server

Start with the path of the data. After you publish the board, a teammate opens the app that Cursor hosts. Cursor sign-in comes first. The page asks only the app's own server for data, and the server reads stored reviews from Postgres. A daily request starts the refresh. It carries a Cursor API key into the refresh route. The route reads the EveryInfra key from a server environment variable and calls each capability once.

The route then writes new reviews into Postgres and skips any review ID that is already there. On this whole path, the EveryInfra key exists only in a server environment variable. The browser cannot read it, and the Cursor agent never sees its value.

This split gives two benefits. First, opening the board costs nothing. Five people can open it twenty times a day, and each visit only reads Postgres. Second, the board still works when one data source has a problem. If one source fails a refresh, the board keeps the previous data and shows the time of the last good refresh.

Where the key lives: Cursor secrets, NEXT_PUBLIC_, and the publish checks

Lovable's blog says that it blocks about 1,200 private API keys in code per day. In May 2025, Semafor reported 170 vulnerable Lovable sites with database settings that were not correct. Cursor puts three gates on this path.

The first gate is the secret store. The Apps docs say that Cursor asks for the secrets that the app needs, and that the agent never sees the values. In most cases a team admin creates team secrets in the Apps dashboard. Users with permission can create personal secrets. For this board, that means one team secret named EVERYINFRA_API_KEY. The code reads only process.env.EVERYINFRA_API_KEY.

Each cloud agent runs in its own virtual machine. The Cloud Agents security overview says that one agent cannot see the code or environment of another agent. It also says that Cursor employees cannot access the code inside the VMs.

The agent's development environment has a separate set of secret types. The Secrets & Network docs list three. An Environment Variable is visible to the agent, so use it only for non-sensitive settings. A Runtime Secret also loads as an environment variable, but Cursor replaces its value with [REDACTED] in tool output, transcripts, commits, and commit messages. A Build Secret is available only to the Docker build.

To test one live API call during development, use a Runtime Secret. Do not use an Environment Variable. The docs also warn that a Runtime Secret is still visible to people who open the agent's environment through the terminal.

The second gate is the framework. The Cursor docs do not require a framework, and our config example uses Next.js. The Next.js environment variable guide says that variables without the NEXT_PUBLIC_ prefix are available only in the Node.js environment. A variable with that prefix is inlined into the JavaScript that goes to the browser at build time. So the key name must not start with NEXT_PUBLIC_, and the API call must live in a Route Handler or a Server Action. Put this rule in the prompt. It is easier than finding the mistake after the build.

The third gate is the publish check. The security section of the Apps docs lists four checks that run before every publish, even when the security review is off. A file with an API key or access token stops the publish. Private keys, service-account keys, and token files stop the publish. Cursor does not ship .env files or source maps. An AI security review runs on top of these checks.

Team admins can add rules to that review, but they cannot remove the built-in checks. Admins can approve a publish that the review blocked, with three exceptions. They cannot approve malicious code, hardcoded secrets, or exposed credentials.

These gates stop two kinds of mistakes: a key in a file and a key in the browser bundle. They do not stop a third kind: someone else uses a key that you gave out.

EveryInfra keys are billed per call, so we suggest one key for the board only. If you must replace it, you change one secret value in the Apps dashboard. The OWASP Secrets Management Cheat Sheet lists per-service secrets and fast rotation as basic practice. If the repo is on GitHub, secret scanning also checks the full Git history for hardcoded credentials. Private repos need Secret Protection for this.

Config example: the prompt for the cloud agent

Below is the prompt we wrote for the cloud agent. We did not run the Cursor side, so this section and the next one are config examples. We checked every EveryInfra parameter and field against the catalog. The prompt must say "build an app" in clear words. The Apps docs say that this is how the agent enters the app-building flow.

Build an app: a competitor review board for our budgeting app team.

Data: call EveryInfra from the server only.
- POST https://api.everyinfra.com/api/v1/social
- Header: Authorization: Bearer ${EVERYINFRA_API_KEY}  (team secret; never NEXT_PUBLIC_)
- Sources (one call each per refresh):
  app_store/reviews   {"app_id": "1010865877", "sort": "newest", "limit": 30}   # YNAB
  app_store/reviews   {"app_id": "1459319842", "sort": "newest", "limit": 30}   # Monarch
  google_play/reviews {"app_id": "com.youneedabudget.evergreen.app", "sort": "newest", "limit": 40}
  google_play/reviews {"app_id": "com.monarchmoney.mobile", "sort": "newest", "limit": 40}
  trustpilot/reviews  {"company": "ynab.com", "sort": "newest", "limit": 20}
  trustpilot/reviews  {"company": "monarchmoney.com", "sort": "newest", "limit": 20}
  reddit/search       {"keyword": "YNAB Monarch", "sort": "newest", "limit": 25}
Storage: Postgres table reviews(source, competitor, review_id, rating, title, text, posted_at, fetched_at),
  unique (source, review_id); upsert with ON CONFLICT DO NOTHING.
Refresh: POST /api/refresh, allowed only for requests that come with a Cursor API key.
  On HTTP 429 or 503 read error.retry_after, retry once, then keep yesterday's data and
  record last_success_at per source.
Pages: (1) new 1-2 star reviews since last refresh, (2) rating mix per competitor per source,
  (3) Reddit posts list. Share with: our team only.

Each line in the prompt maps to a fact from the sections above. The secret name and "never NEXT_PUBLIC_" come from the Next.js guide. The rule unique (source, review_id) exists because the same review comes back in many refreshes. The 429 and 503 handling covers the two error types that the API marks as retryable. The limit values come from the review speed of each competitor, which the coverage section measures.

Config example: the refresh route and the table

Agent output is different on each run. Below is the minimum that we expect in the refresh route, so you can compare it with what the agent writes. It is a Next.js Route Handler, and it runs only on the server.

// app/api/refresh/route.ts — config example, server only
import { sql } from "@/lib/db";

const SOURCES = [
  { source: "app_store", competitor: "ynab", body: { platform: "app_store", action: "reviews", params: { app_id: "1010865877", sort: "newest", limit: 30 } } },
  { source: "app_store", competitor: "monarch", body: { platform: "app_store", action: "reviews", params: { app_id: "1459319842", sort: "newest", limit: 30 } } },
  { source: "reddit", competitor: "both", body: { platform: "reddit", action: "search", params: { keyword: "YNAB Monarch", sort: "newest", limit: 25 } } },
  // google_play/reviews and trustpilot/reviews follow the same shape
];

async function callOnce(body: object) {
  const res = await fetch("https://api.everyinfra.com/api/v1/social", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.EVERYINFRA_API_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  return { status: res.status, json: await res.json() };
}

export async function POST() {
  const report = [];
  for (const s of SOURCES) {
    let r = await callOnce(s.body);
    if (r.status === 429 || r.status === 503) {
      const wait = Math.min((r.json?.error?.retry_after ?? 30) * 1000, 120_000);
      await new Promise((ok) => setTimeout(ok, wait));
      r = await callOnce(s.body);
    }
    if (r.status !== 200) { report.push({ ...s, ok: false, status: r.status }); continue; }
    for (const row of r.json.results ?? []) {
      await sql`INSERT INTO reviews (source, competitor, review_id, rating, title, text, posted_at, fetched_at)
                VALUES (${s.source}, ${s.competitor}, ${row.id}, ${row.rating ?? row.score ?? null},
                        ${row.title ?? null}, ${row.text ?? null}, ${row.posted_at}, now())
                ON CONFLICT (source, review_id) DO NOTHING`;
    }
    await sql`UPDATE sources SET last_success_at = now() WHERE source = ${s.source} AND competitor = ${s.competitor}`;
    report.push({ ...s, ok: true, rows: r.json.results?.length ?? 0, charged_usd: r.json.billing?.charged_usd });
  }
  return Response.json(report);
}

Deduplication uses INSERT … ON CONFLICT DO NOTHING in Postgres. The PostgreSQL docs say that ON CONFLICT gives an alternative action instead of a unique-constraint error. So when the same review comes back the next day, the table still has one row. The fetched_at column keeps the time of the first fetch. The board marks "new" reviews by fetched_at, not by posted_at. The test section explains why.

Field names differ by site. App Store and Trustpilot call the star field rating. Google Play calls it score. Reddit posts have no stars, only like_count and comment_count. You can check all of these in the catalog response_fields, so you do not need to guess.

One real round trip: request, response, and charge

Below is a real request that we sent on November 13, 2026 at 21:31:02 Singapore time (13:31:02 UTC). It asks for the newest 30 YNAB reviews on the US App Store. The key goes in through an environment variable, so the command shows only the variable name.

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"app_store","action":"reviews","params":{"app_id":"1010865877","sort":"newest","limit":30}}'

The response was HTTP 200 with count 30. The field billing.charged_usd was 0.001389, which matches the catalog price. The full JSON was about 19.6 KB. Each review had the same fields as the catalog response_fields: id, title, text, rating, rating_scale, author, app_version, helpful_count, posted_at, app_id, app_name, and platform.

The board needs only 7 of these fields. The author field is the nickname of a private person, so we drop it before we store the row. That is also why no reviewer name appears in the screenshots or tables in this article.

Live test: three times, four capabilities, and what came back

The board side is a config example, but we called the data side for real.

On the evening of November 13, 2026, we ran the calls of one board refresh at three times. The times were 21:31, 22:14, and 22:36 Singapore time.

We also called the Fintonic control: the App Store in all three rounds, and Google Play and Trustpilot in rounds 2 and 3. For each request we recorded the HTTP status, the time, the row count, and billing.charged_usd. We kept every raw response, so you can recompute the numbers below. The table shows App Store and Reddit for all three rounds. Google Play and Trustpilot are in the round 3 section.

The newest App Store reviews did not change in three rounds. For YNAB, Monarch, and Fintonic, the 30 reviews in the later rounds were the same as in round 1. They had the same IDs in the same order. There were 0 new reviews. The age of the newest review grew with the clock: from 57.6 to 58.7 hours for YNAB and from 56.7 to 57.7 hours for Monarch. So the store published no new review in that time.

Reddit also had no new posts. Rounds 1 and 2 returned the same 9 posts. Only the counts changed. For example, the November 9 discussion went from 280 to 283 upvotes, and it had 284 in round 3.

All 23 posts in round 3 are older than the round 1 request. The same post comes back in many refreshes, so the board must remove duplicates by post URL. It must use posted_at to find new posts, not "first fetched in this refresh."

Store reviews become public one or two days late. With an hourly refresh, 23 of 24 calls return the same reviews, but the API cost is 24 times the daily cost. One refresh per day is enough. If you need faster updates, refresh every 6 hours at most.

The sources have very different speeds. Successful App Store calls took 0.42 to 0.74 seconds. Google Play calls took 7.0 to 9.3 seconds. The "YNAB Monarch" Reddit search took 8.86 and 10.54 seconds. Trustpilot calls took 26.37 to 53.35 seconds, and the slowest call was the Fintonic control.

In round 3, the 7 board calls in a row took about 84 seconds, and the two Trustpilot calls used 54 of them. Give each call a long enough timeout. For Trustpilot, allow at least one minute. You can also send the calls for each source in parallel, so the slowest call sets the total time.

503 and 429: how the board should handle them

In the first two rounds, Google Play and Trustpilot returned 503. We were not charged, and the retry in round 3 worked, at the catalog price. Here is one of those 503 responses (22:14:53 Singapore time, google_play/reviews, YNAB). The error.code was unavailable, and error.retryable was true. billing.charged was false, charged_usd was 0, and refund.status was succeeded.

The two errors mean different things in HTTP, so the board must handle them differently. RFC 6585 defines 429 as "Too Many Requests." You sent too fast, and a short wait fixes it. RFC 9110 defines 503 as a temporary server problem, and the server can send Retry-After to say when to come back.

So the refresh route does this. On 429, it waits for retry_after and tries once more. On 503, it also retries once. If the call still fails, the route skips that source, keeps yesterday's data, and shows the time of the last good refresh in that column. The last_success_at field in the config example is for this case.

Do not retry in a loop until the call works. If the route waits for one source, the other sources cannot write their rows. Keep a separate status for each source instead. Then a source that did not refresh affects one column, and the other columns still update. This is also why the route makes four separate calls. With one batch request, one failure can block all of them. In the interface, each column shows the time of its last good refresh.

How many days 30 reviews cover: measure review speed before you set limit

The right limit depends on how many reviews each competitor gets per day. We measured this with the two App Store responses from round 1. The newest 30 YNAB reviews run from October 12 to November 10, 2026. That is 29.1 days, or about 1.03 reviews per day. The newest 30 Monarch reviews run from November 2 to November 10. That is only 8.6 days, or about 3.48 reviews per day.

So Monarch gets about 3.4 times as many written reviews per day as YNAB (3.48 divided by 1.03). This ratio shows only how many people write reviews on the US App Store. It does not show downloads or revenue.

These numbers set the board parameters. With one refresh per day, Monarch adds three or four reviews. So limit: 30 covers more than 8 days. If the refresh stops for a week, one fetch still gets every review. YNAB adds about one review per day, so 30 reviews cover a month.

We did not raise limit to the maximum of 500. Billing is per call, so the price does not change. But each response would grow from about 20 KB to several hundred KB, and the database writes would take longer. A large limit is useful only for the first fetch, when you load the history. For example, 200 YNAB reviews go back about six months.

The interface must also show one more number: the age of the newest review at request time. In round 1 at 21:31 Singapore time, the newest YNAB review was from November 10 at 20:52 US Pacific time. That was 57.6 hours before the request. The newest Monarch review was 56.7 hours old.

The Google Play Console help page says that new reviews are generally held back for about 24 hours. In both App Store samples, too, the first review was more than two days old. So "new today" on the board can only mean "first fetched today."

Star mix and low-star topics: where each competitor loses stars

The share of low-star reviews is similar in the two samples. YNAB has 6 one-star and 4 two-star reviews in 30, which is 33.3%. Monarch has 8 one-star and 3 two-star reviews, which is 36.7%. About half of each sample is five stars: 16 for YNAB and 14 for Monarch. Few reviews have three or four stars.

The sample is small. One review changes the share by 3.3 points. So the board must show review counts, not only percentages.

The table shows the topics of the 21 low-star reviews. The tagging rule: one person (the author) read all 21 one-star and two-star reviews for the two apps. Each review got one topic, from the first complaint in the text. No second person checked the tags. Each app has only 10 or 11 reviews, so the counts describe this sample only. After launch, a rule or a model can do the same job on the board.

In this sample, 4 YNAB low-star reviews are about price. The YNAB pricing page, read on November 13, 2026, lists $109 per year or $14.99 per month. One review asks for a cheaper tier without bank sync. For Monarch, 3 reviews are about privacy and 2 about accuracy. The counts are too small to describe all users of either app. The board's job is to collect new low-star reviews each day, so that you can read the mix again when you have dozens.

Remember that the three privacy reviews are user opinions. A review does not prove what Monarch's policy says. If your team needs the facts, read the policy itself. The Monarch pricing page says that Monarch never sells financial data. On the board, write only "three reviews say this."

One topic appears for both apps: iPhone Duo. The iPhone Duo reached buyers on October 23, and Apple published a newsroom post about new app designs for it on the same day. In our sample, one YNAB one-star review says that the large screen still forces the phone layout. One Monarch one-star review asks why there is no Duo update. One Monarch four-star review says that only Duo support is missing.

So 2 low-star reviews in the sample mention iPhone Duo, one for each app. A separate tag on the board shows how this count changes in the next weeks.

Only one review mentions AI. On November 2, a Monarch five-star review praised the MCP connector. The review called the connector "a clear differentiator" for Monarch. That is less than two weeks after Monarch reopened the connector on October 21. None of the 30 YNAB reviews mentions AI.

The sample is small, so this does not show that most users care. It shows only that one user gave MCP as a reason for the rating.

The two sources from round 3: one competitor, three sites, three reputations

In round 3 at 22:37 Singapore time, the Google Play and Trustpilot retries worked. For the first time, we had the newest reviews of each competitor on all three sites. The App Store data is from round 1, because all rounds were the same. The Google Play and Trustpilot data is from round 3.

First, in this sample the low-star share is higher on Google Play. For both apps, the low-star share on Google Play is 8 to 10 points higher. It is 43% against 33% for YNAB, and 45% against 37% for Monarch.

The order of review speed did not change. On Google Play, 40 Monarch reviews cover 18.9 days, or about 2.1 per day. 40 YNAB reviews cover 46.4 days, or about 0.86 per day. Monarch still gets more than twice as many reviews as YNAB, the same result as on the App Store. So the rule "set limit from review speed" also works on Google Play.

Second, the two apps look completely different on Trustpilot. YNAB has only 1 low-star review in 20, and 15 five-star reviews. Monarch has 18 one-star or two-star reviews in 20, and only 1 five-star review.

For YNAB, 18 of the 20 reviews have source set to InvitationApi and verification_level set to verified. So the company asked these users to write a review through the Trustpilot invitation API. All 18 have three stars or more. The other 2 reviews are organic (source: Organic): one has one star, and one has five stars.

All 20 Monarch reviews are organic. The newest one is from September 21, 2026, and the 20 reviews cover 323 days.

The Trustpilot developer docs include a business API to send invitations. We have two samples of 20 reviews each. The company that uses invitations has more five-star reviews. The company that does not use them has more low-star reviews. Two companies cannot show cause and effect. But they do show that you cannot compare Trustpilot stars without the source field.

So the Trustpilot column on the board needs two rows, split by source: one for invited reviews and one for organic reviews. To compare two competitors fairly, compare only organic reviews. YNAB has only 2 of those, which is too few for a conclusion.

Company replies are another signal. On Google Play, YNAB replied to 26 of 40 reviews, and Monarch replied to 28. On Trustpilot, YNAB replied to 5 reviews, and Monarch replied to none. You can count replies by checking whether reply_text is empty. For a three-person team, fast replies are a real way to stand out.

Round 3 also covered all three sites for the Fintonic control. On Google Play in Spanish, 34 of its 40 newest reviews have one or two stars. That is 85%, more than the 70% on the App Store. Fintonic replied to all 40. On Trustpilot, we got only 8 reviews over 501 days, and 5 of them were invited (verification_level: invited). So Spanish users mostly speak about Fintonic in the two app stores, not on Trustpilot.

We tagged the 21 one-star and two-star Fintonic reviews on the Spain App Store with the same rule. 7 are about updates and the redesign, and 5 say that the app now sells loans, insurance, and other financial products. 4 are about bank connections, 3 about lost data, and 2 about other things. By app version, all 7 reviews on version 10.0.7 have one or two stars: 3 are about product selling and 2 about the redesign. On the newest version, 10.0.10, 6 of 12 reviews have one or two stars.

For a team in Spain, these numbers show a cluster of complaints about a redesign that turned the app into a sales channel. That is a different problem from the price and privacy complaints about YNAB and Monarch. The test also shows that the same board works for another country. Change country and language, and the fields and the deduplication rule stay the same.

Reddit switching posts: which way users move

In the same round, we ran reddit/search for "YNAB Monarch," sorted by newest. We got 9 posts from October 25 to November 10, with 515 comments in total. By title, 3 posts are about switching. The table shows them with the counts from round 1.

Five posts promote new products. One post with the same title appears in two Canadian startup communities. One of the five promotion posts compares the personal finance feature in Claude with Monarch.

The busiest post is not about switching. It is a discussion in r/MonarchMoney on November 9 about how users feel about AI features in budgeting apps, with 280 upvotes and 179 comments. It appeared four days after Claude launched its personal finance feature. For the board, the useful parts of a post are the title and the comment count. Long threads are for people to open and read, not for full display on the board.

We search only for the two names together. This gives fewer posts, but almost all of them are about choosing between the two apps. Separate searches for "YNAB" and "Monarch" find more posts, but they also bring help requests from each app's users. We did not measure how many. One reddit/search call costs $0.000792, so two more searches add only about 0.16 cents per day. Watch the column for a week before you add them.

The API cost of one refresh per day

We used the catalog price_usd and checked it against real charges. Every successful call charged exactly the catalog price, and every failed call charged zero. In round 3, all 7 board calls worked, and the real charge was exactly $0.009126. One daily refresh makes these calls: one app_store/reviews, one google_play/reviews, and one trustpilot/reviews for each competitor, plus one reddit/search.

One refresh per day costs $0.009126, which is less than one cent. That is about $0.27 per 30 days and about $3.33 per year. An hourly refresh costs $6.57 per 30 days, which is 24 times as much. The test section shows that the 23 extra calls per day almost never find new reviews. Failed calls and calls with 0 rows are free.

On the Cursor side, one Premium seat costs $30 per month, plus cloud agent usage at model rates while the agent builds the board. We did not measure that usage. After launch, the API cost is about $0.27 per month, or about 0.9% of the Premium fee.

How to trigger the daily refresh, and what each option costs

The Apps docs do not mention a built-in scheduler, so a daily refresh needs an outside trigger. We compared three options. Each one uses only features that the docs describe.

Option one is refresh on open. When a page loads, the server checks last_success_at for each source. If a source is older than 24 hours, the server runs one refresh. All other visits only read Postgres. You configure nothing extra.

The cost is that a day with no visitors has no new data. The first visitor on the next day also waits for the API calls. In round 3 of our test, the 7 calls in a row took about 84 seconds, and one Trustpilot call took more than 26 seconds. So show the last data first, and swap in the new data when the background refresh ends. For a small team that opens the board every day, this option is enough.

Option two is an outside scheduler with a Cursor API key. The Apps docs say that private and team apps sit behind Cursor sign-in, and automated tools cannot pass it. A Cursor API key in the x-cursor-app-token header lets a tool use the app like a signed-in user. The key works only as a header, not as a query parameter or a cookie. Cursor marks these requests as automated. A team API key opens only the team apps that you assign to it.

We put the scheduler on the GitHub Actions schedule trigger. It sends one POST /api/refresh every morning.

# .github/workflows/refresh-board.yml — config example
on:
  schedule:
    - cron: "0 1 * * *"   # 01:00 UTC = 09:00 Singapore time
  workflow_dispatch: {}
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - run: |
          curl -sf -X POST "https://<your-app-domain>/api/refresh" \
            -H "x-cursor-app-token: ${{ secrets.CURSOR_APP_TOKEN }}"

This setup uses two keys in two places. GitHub Secrets holds only the Cursor API key, which opens this one app. The EveryInfra key stays in the Cursor Apps secret store, and GitHub never sees it.

Option three is Cursor Automations. The Automations docs say that a scheduled trigger runs a cloud agent in the background, from a preset or a cron expression. A run "may run with a delay but will not start before the indicated time." Billing follows cloud agent usage. So a daily agent that only calls the refresh route costs one model run per day, and the refresh itself needs no model decision.

A Cursor forum thread from September 2026 also says that scheduled runs write results only to run history. To get the results elsewhere, you must attach a delivery tool such as Send to Slack. Our conclusion is simple. Use option one or two for the refresh. Use Automations for a weekly summary that an agent writes from the board, because that step needs a model.

Limits and things to check

Start with the Cursor side. Build Live Apps needs a cloud agent, and Free and Plus do not have one. Teams and Enterprise admins can turn Apps off for the whole team. They can also block API keys from opening apps, which removes option two above. Repos must be on Cursor Origin or GitHub, and GitLab support is "coming soon."

The Availability section of the Apps docs says that hosting is separate from Cursor's services. Hosting is provided "as is." Cursor can remove a subdomain or an app for terms violations or for business reasons. For a board that matters, keep the code in your own repo too.

Next, the data side. All four capabilities read public content only: public app reviews, public Trustpilot reviews, and public Reddit posts.

The official Apple and Google review APIs show developers the reviews of their own apps only.

Apple's Customer Reviews resource is part of the App Store Connect API. It gets "the customer reviews for your app."

The Google Play Reply to Reviews API covers production versions of your own app. It returns only reviews with text, and it has a quota of 200 GET requests per hour. Neither API can show you a competitor's reviews.

The other two sources are similar. The Trustpilot developer docs offer business APIs to send invitations, show reviews, and reply to your own reviews. Access to the full review database is a separate Data Solutions offer. If you want to use the official Reddit API yourself, first read the Reddit Data API Terms, last revised on July 20, 2026.

Reviews also arrive late. The Google Play Console help page says that new ratings and reviews are generally held back for about 24 hours. If Google detects suspicious activity, it can pause all new public reviews for the app. Apple's ratings and reviews page says that a developer can reset the summary rating with a new version, but written reviews stay. So "new today" on the board means "first fetched today." The review itself can be one or two days old, and the interface must say so.

Last, the people. A reviewer nickname belongs to a private person, and the board does not need it. Drop it before you store the row.

When you quote a review, quote the text without the name.

A review can show a product problem. It cannot prove that a competitor broke a law or lied. The three Monarch one-star reviews about privacy are an example. They show that some users believe this. They do not show that it is true. Notes on the board should keep the same distance.

Industry updates: October to November 2026

• November 5, 2026: Cursor ships Build Live Apps (changelog). For you: an internal tool now skips three steps before the team can open it. These steps are hosting, database, and sign-in. For a board that pulls outside data, the key setup is the one part you must still design.
• November 5, 2026: Anthropic launches a Personal Finance beta in Claude (Anthropic, help center, TechCrunch). For you: budgeting apps also compete with a general assistant now. Add a "who do users compare us to" view to the board.
• November 4, 2026: Apple opens retention messages for subscriptions (Apple Developer News). For you: subscription apps get one more chance to speak when a user cancels. Competitor complaints about renewals and cancellation are direct input for that message.
• October 23, 2026: iPhone Duo reaches buyers (Apple Newsroom). For you: in our sample, each competitor has one one-star review about missing iPhone Duo support.
• October 21, 2026: Monarch reopens its MCP connector (Monarch blog, help center). For you: a competitor now sells "works with your AI tools" as a feature. A five-star review in our sample calls MCP a differentiator.
• October 20 and 13, 2026: Cursor ships the Agent SDK and an app marketplace (Agent SDK, Origin App Marketplace). For you: Agent SDK channels can wake an agent on a cron schedule. This fits a weekly summary. The Origin marketplace lists deploy apps such as Vercel and Cloudflare, so the board can move off Cursor hosting later.

Get started

Sign up at EveryInfra and create one key for the board only. Run one test call in the App Store reviews and Reddit search playgrounds. Check the parameters and fields. Check usage and prices on the pricing page. To test in the editor first, add the EveryInfra remote MCP server to Cursor. See the MCP setup page and our Cursor MCP plugin test. Find the right capabilities and parameters in a chat, and then copy the final calls into the refresh route. Do you want a cloud agent that reads your own low-star reviews each day and opens issues? See VS Code Copilot cloud automations: triage app store reviews every day.

FAQ

Cursor build live app builder: is it an app builder, and what kind of app can it make?

(Question from the autocomplete phrase "cursor build live apps app builder", read on November 13, 2026.) Yes. You describe an app, and Cursor builds it, hosts it, and gives you a link. The Apps docs describe web apps with an optional Postgres database and Cursor sign-in. They do not mention native mobile apps. Apps sit behind Cursor sign-in by default, so the feature fits internal tools best. A team-only competitor review board is that kind of tool.

Cursor build live apps not working: why can I not find the app option?

(Question from the Google autocomplete phrase "cursor build live apps not working", read on November 13, 2026.) Check four things in the docs. First, use a cloud agent, because the Apps docs say local agents are not supported. Second, check the plan, because the Cloud Agents docs say Free and Plus do not include cloud agents. Third, an admin can turn Apps off for the whole team. Fourth, the prompt must say "build an app." Also, Cursor adds new secrets only when an agent starts. Start a new agent after you add a secret.

Cursor build live apps React: which framework does the app use?

(From the autocomplete phrase "cursor build live apps react".) The Apps docs do not set a framework. They say only that Cursor scaffolds the web app, adds Postgres if needed, and sets up Cursor sign-in and hosting. You can name a framework in the prompt.

Our config example uses Next.js, which is React. Its server routes and its NEXT_PUBLIC_ rule give a clear way to keep the key on the server. The framework does not change how the app calls EveryInfra. It is one HTTPS POST from the server in every case.

Cursor live apps for Mac or Windows: must I install anything?

(From the autocomplete phrases "cursor live apps for mac" and "cursor live apps windows".) No. A cloud agent builds and deploys the app in Cursor's cloud, and your computer only starts the request. The Cloud Agents docs list seven ways to start one. They are the iOS app, the web app, the desktop app, Slack, GitHub or Bitbucket comments, Linear, and the API. The desktop app on Mac, Windows, or Linux works, and so does a phone.

Cursor live apps free: does the free plan work?

(From the autocomplete phrase "cursor live apps free".) No. The Cursor pricing page, read on November 13, and the Cloud Agents docs show that Free and Plus have no cloud agents. Premium at $30 per month is the first tier with them. The docs do not list a separate hosting fee after you publish. EveryInfra bills per call with no monthly fee. The cost section above gives the daily API cost of the board.

Competitor review monitoring free: is there a free way to watch competitor reviews?

(From the autocomplete phrase "competitor review monitoring free".) The only fully free way is to open each competitor's store page by hand every day. The official Apple and Google review APIs return only your own app's reviews, as the limits section explains. The method in this article costs about one cent per day in API calls in our test, plus a Cursor Premium seat. If you already run a server, you can put the same refresh code in your own scheduler and skip Cursor.

Is this the new v0? How is it different from Lovable or Replit?

(From a question in the Reddit r/cursor thread "Cursor can now build + deploy internal apps".) The idea is close: describe an app, and the tool builds and hosts it. The New Stack compared it with Lovable and Replit and said Cursor aims more at internal company tools. For a review board, two differences matter. Cursor apps sit behind Cursor sign-in by default, which suits a team-only page. The publish-time secret check is mandatory, and even an admin cannot approve a hardcoded secret.

References

1. Build live apps, Cursor changelog, 2026-11-05, https://cursor.com/changelog/build-live-apps
2. Apps, Cursor Docs, https://cursor.com/docs/cloud-agent/apps
3. Cloud Agents, Cursor Docs, https://cursor.com/docs/cloud-agent
4. Cloud Agents security, Cursor Docs, https://cursor.com/docs/cloud-agent/security
5. Secrets & Network, Cursor Docs, https://cursor.com/docs/cloud-agent/security-network
6. Automations, Cursor Docs, https://cursor.com/docs/cloud-agent/automations
7. Pricing, Cursor, https://cursor.com/pricing
8. Start from scratch, Cursor changelog, 2026-08-27, https://cursor.com/changelog/start-from-scratch
9. Agent SDK, Cursor changelog, 2026-10-20, https://cursor.com/changelog/agent-sdk
10. Origin App Marketplace, Cursor changelog, 2026-10-13, https://cursor.com/changelog/origin-app-marketplace
11. Model Context Protocol (MCP), Cursor Docs, https://cursor.com/docs/mcp
12. Most apps never make it off localhost: Cursor takes on Lovable and Replit with fully managed app deployment, The New Stack, 2026-11-05, https://thenewstack.io/cursor-ai-app-deployment/
13. Vercel for Platforms, Vercel, https://vercel.com/for/platforms
14. Cursor can now build + deploy internal apps, Reddit r/cursor, 2026-11, https://www.reddit.com/r/cursor/comments/1xoxyh5/cursor_can_now_build_deploy_internal_apps_hosting/
15. Cron/MCP-only automations: repo warning, no output surface, Cursor Forum, 2026-09, https://forum.cursor.com/t/cron-mcp-only-automations-repo-warning-no-output-surface-broken-add-flow/172146
16. Customer Reviews, Apple Developer Documentation, App Store Connect API, https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews
17. Ratings, reviews, and responses, Apple Developer, https://developer.apple.com/app-store/ratings-and-reviews/
18. Retention messages now available, Apple Developer News, 2026-11-04, https://developer.apple.com/news/?id=fk9ps3gv
19. New age rating content descriptors, Apple Developer News, 2026-11-02, https://developer.apple.com/news/?id=yxkh08us
20. Developers bring incredible new app experiences to iPhone Duo, Apple Newsroom, 2026-10-23, https://www.apple.com/newsroom/2026/10/developers-bring-incredible-new-app-experiences-to-iphone-duo/
21. Reply to Reviews API, Google for Developers, https://developers.google.com/android-publisher/reply-to-reviews
22. View and analyze your app's ratings and reviews, Google Play Console Help, https://support.google.com/googleplay/android-developer/answer/138230
23. Trustpilot API documentation, Trustpilot Developers, https://developers.trustpilot.com/
24. Data API Terms, Reddit, Inc., 2026-07-20, https://redditinc.com/policies/data-api-terms
25. Environment variables, Next.js Docs, https://nextjs.org/docs/app/guides/environment-variables
26. Events that trigger workflows: schedule, GitHub Docs, https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule
27. About secret scanning, GitHub Docs, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
28. INSERT, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-insert.html
29. RFC 9110: HTTP Semantics, IETF, 2022-06, https://www.rfc-editor.org/rfc/rfc9110
30. RFC 6585: Additional HTTP Status Codes, IETF, 2012-04, https://www.rfc-editor.org/rfc/rfc6585
31. Secrets Management Cheat Sheet, OWASP, https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
32. The hottest new vibe coding startup Lovable is a sitting duck for hackers, Semafor, 2025-05-29, https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers
33. Lovable: Secure Vibe Coding, Lovable blog, https://lovable.dev/blog/secure-vibe-coding
34. Introducing Personal Finance in Claude, Anthropic, 2026-11-05, https://claude.com/resources/articles/introducing-personal-finance-in-claude
35. Use Personal Finance in Claude, Claude Help Center, 2026-11, https://support.claude.com/en/articles/18185620-use-personal-finance-in-claude
36. Claude can now analyze your spending with its new personal finance tool, TechCrunch, 2026-11-05, https://techcrunch.com/2026/11/05/claude-can-now-analyze-your-spending-with-its-new-personal-finance-tool/
37. Monarch MCP, Monarch blog, 2026-10-21, https://www.monarch.com/blog/monarch-mcp
38. Monarch MCP Connector, Monarch Help Center, https://help.monarch.com/hc/en-us/articles/50207234679956-Monarch-MCP-Connector
39. Pricing, Monarch, https://www.monarch.com/pricing
40. Pricing, YNAB, https://www.ynab.com/pricing