The model bill is a dollar a month, and the hours are what decide it

There is a CVSS 9.3 record against the sentence that sells this business.

An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites. NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.

CVE-2025-48757, National Vulnerability Database

The sentence it fires at is the one I wrote myself, and the one every version of this pitch contains: let the platform own the plumbing, because hosting, database, auth, deployment and infrastructure security are already handled. Read the supplier’s dispute again. Their defence is that data security in a generated app belongs to the person who generated it. That is the correct division of responsibility and it is the exact opposite of what the pitch promises.

Why I am the one telling you this

I have run an unattended system into the ground and I have the commit log.

From 31 October 2025 to 27 April 2026 a worker on my own domain ran on a cron of 0 */1 * * *. Every hour it took 450 characters of an RSS description, passed them to gpt-4o-mini with a rewrite pass on gpt-4o, and committed the output straight to main. AUTO_PR was "false", because I never wrote a review step. It made 842 Add post: commits and 2,922 files across four languages. 180 of the 739 English posts cited a source called “Internal Analysis” that does not exist. I deleted all of it in August 2026 and wrote up the full account.

No alert fired for six months. Nothing was measuring anything, so nothing had a threshold to cross, so the pipeline emitted its worst output at a steady hourly rate until a human finally read it. That is the failure this article is about, and it is not a story about a model writing badly. It is a story about a system with no published number that a person checks on a schedule.

The other thing I did was read the documents. This market’s most-repeated statistic traces to a 2011 magazine article and a 2007 conference deck, both free, and the deck says in as many words that it did not measure the thing it gets cited for.

One piece of housekeeping, because it is the standard I am asking you to hold me to. My original post carried four revenue ranges. They were one creator’s illustrative figures, I could not name the creator, and an income claim from an unnamed third party is the exact shape this site fails its own build on. They are gone. What is left is arithmetic and documents.

1. The plumbing is owned until the record says otherwise

Read the record carefully rather than as ammunition. It is tagged disputed and exclusively-hosted-service, its NVD status is Deferred, and the CISA assessment of 25 June 2025 records exploitation as poc and automatable as yes. Reporting a disputed CVE as settled fact would be the same error this site exists to correct, so: disputed, and the dispute is the point. The vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N. Network, low complexity, no privileges, no user interaction, scope changed. In plain terms the generated app’s own tables were reachable by an unauthenticated stranger. Not a connected CRM, not an integration somebody wired up carelessly. The database the platform handed over.

My original post conceded one thing here: that how client data is accessed, stored and acted on once you connect a real CRM or inbox stays your responsibility. That concession was too narrow by exactly one layer.

Detect it: take the public client-side key your generated app ships in its front-end bundle, and from a machine that has never signed in, request a table the app never exposes in its interface. Users, invoices, submissions. If a row comes back, row-level security is not on for that table. This takes four minutes and it is the single check whose absence the CVE describes.

Design so it cannot recur: treat every table the platform generates as public until you have personally denied it. Default deny, then grant. Run the unauthenticated read as a test you repeat after every schema change, because the schema changes when you prompt for a new feature and nothing tells you which policies came with it.

2. Sixty seconds is not a measurement

I described the product as every inbound lead scored and personally followed up within 60 seconds. That is a product specification, so it is not false. But it borrows its authority from a number nobody quoting it has read.

The 2011 Harvard Business Review article by Oldroyd, McElheran and Elkington audited 2,241 US companies by timing each one’s response to a web-generated test lead. 37% responded within an hour, 16% took one to 24 hours, 24% took longer than a day, and 23% never responded at all. The average among firms that answered inside 30 days was 42 hours.

The published distribution is 586, 143, 90, 81, 90, 61, 7, 133, 538 and 512 companies across the buckets from under five minutes to no reply. That sums to 2,241, the stated sample, and 819 of them answered inside the hour, which is 36.5%. The arithmetic holds when you check it, which is worth knowing before you rely on the next part.

The multipliers come from a separate dataset in the same article: 1.25 million leads at 29 B2C and 13 B2B companies. Firms that tried to contact within an hour were nearly seven times as likely to qualify the lead as those trying an hour later, and more than 60 times as likely as those waiting a day. The article defines qualify as “having a meaningful conversation with a key decision maker.” Not a sale. A conversation.

The famous “21x” comes from somewhere else entirely, and it is the one worth correcting.

Table: What the popular version of the speed-to-lead statistic claims, against what the two primary documents say.

What survives still sells: minutes beat hours, hours beat days, and 23% of the companies audited never replied at all. That is true, it is checkable, and the buyer can verify their own reply time in an afternoon.

Detect it: before you promise a response time, instrument the client’s current one. Send three test enquiries through their own form at different hours and time the human reply. That is your before, it costs nothing, and it is the only number in the pitch that belongs to this client rather than to a 2007 conference deck.

3. Silent compounding has a number, and it is 0.3%

My post said errors compound silently at scale and left it there. Here is the mechanism, with the threshold and the enforcer named.

Google’s sender guidelines, effective 1 February 2024, put a floor under every sender: SPF or DKIM, valid forward and reverse DNS, TLS for transmission, and a Postmaster Tools spam rate below 0.3%. That “or” is load-bearing and easy to read as “and”, so take it from Google’s own two-line summary of the split: “All senders: SPF or DKIM” and “Bulk senders: SPF, DKIM, and DMARC.” Yahoo draws the line in the same place, telling all senders to “implement SPF or DKIM at a minimum” and bulk senders to “implement both SPF & DKIM.”

Cross 5,000 messages a day to Gmail accounts and the second list attaches: both SPF and DKIM rather than either, a DMARC record, a From: domain aligned with the SPF or DKIM domain, and one-click unsubscribe via List-Unsubscribe-Post: List-Unsubscribe=One-Click alongside List-Unsubscribe. On complaints the requirement is the same at every volume, a spam rate below 0.3%, and Google’s monitoring section tightens it: keep it “below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.” Yahoo publishes the same 0.3% ceiling independently, plus a two-day window for honouring an unsubscribe.

Now watch it compound. Suppose a follow-up sequence draws one spam complaint per 500 delivered messages. That is 0.2%: under the ceiling, over the 0.10% Google asks for. At 50 sends a day you clear the authentication bar with SPF alone: no DKIM, no DMARC, no alignment, no unsubscribe header. Add clients until the same sequence sends 5,000 a day and the bar moves under you without one word of the sequence changing: now DKIM as well as SPF, now DMARC, now alignment, now one-click unsubscribe, and the same 0.2% is one bad segment from the ceiling. Cross it and you degrade the sending domain’s reputation. If you did the efficient thing and put every client on one domain, you degrade delivery for all of them in the same week. That is the concentrated-platform-risk argument from my post, applied at the one layer where it is a published number rather than a worry.

Detect it: verify the domain in Postmaster Tools before the first send, and read the spam rate weekly. Alert at 0.10%, not 0.30%. By the time you are at the ceiling you are already being filtered.

Design so it cannot recur: one sending subdomain per client, never a shared one, so a single bad list cannot take the others with it. Process unsubscribes by machine inside two days rather than by hand. Send the unsubscribe headers on every marketing message, not only above the bulk threshold, because the threshold is where enforcement starts and not where the harm does.

4. The margin variable is hours, and model spend is about a dollar

I told readers to subtract platform and model-usage costs. On the evidence, that points at the wrong line.

Table: Claude model IDs and Claude API list prices per million tokens, from Anthropic’s models overview, read on 6 August 2026.

Sonnet 5’s introductory rate runs through 31 August 2026, so anyone quoting it in September is quoting a stale price.

Take a content system producing 20 posts a month, at roughly 2,000 input and 2,000 output tokens each, on Opus 5. Input is 0.04 MTok at $5, so $0.20. Output is 0.04 MTok at $25, so $1.00. Total model spend: about $1.20 a month. Run ten times that volume and you are under $12. Those token counts are my assumptions for that shape of job rather than a measurement, and other vendors price differently, so take the order of magnitude as the finding. The order of magnitude is a rounding error.

Now the line that decides the business.

Table: Gross hourly rate on a $500 monthly retainer, before platform fees, model spend and the acquisition cost of the client.

That is the whole model in three rows. A $500 retainer with three hours of monthly firefighting is a different business from a $500 retainer with ten, and no amount of model-price optimisation moves either row.

Which is why the best idea in my original post was the one with no number attached to it: correction burden. A system whose output the client trusts without editing is the product. The month they start fixing every result by hand, the fee stops making sense to them, and it stops making sense to you first, because their hand-fixing arrives in your inbox as support hours.

Detect it: log hours per client per month from the first week. Watch the trend, not the total. Support hours rising for two consecutive months are a churn notice with a delay on it.

Design so it cannot recur: put scope in writing before the build, naming what the fee covers, what counts as a change request, and the revision limit. Add error alerts that reach you before they reach the client. Ship a monthly results snapshot, because renewal is decided against what the client can see, and firefighting they never heard about is value you burned invisibly.

5. Article 28(4) makes the platform’s failure yours

Anyone building an automation that touches a client’s leads, inbox or customer records is a processor under GDPR. The no-code platform and the model vendor are sub-processors. That is not a metaphor, and Article 28 is short enough to read in one sitting.

The controller may use “only processors providing sufficient guarantees to implement appropriate technical and organisational measures,” and the processing must be governed by a binding contract that names the subject matter, duration, nature, purpose, data types and categories of data subject, and requires documented instructions, confidentiality, Article 32 security measures, conditions on sub-processors, help with data-subject rights, deletion or return of the data at the end, and information made available for audits.

Two paragraphs matter most. Article 28(2): a processor “shall not engage another processor without prior specific or general written authorisation of the controller.” Article 28(4): where a sub-processor fails, the initial processor “shall remain fully liable to the controller for the performance of that other processor’s obligations.”

Read that next to section 1. The platform’s position is that data security in your generated app is your responsibility. GDPR’s position is that the platform’s failures are your liability to your client. Both of those are true at once, and together they turn “let the platform own the plumbing” from a productivity tip into an assumed risk with your name on it.

My post said to get explicit permission before connecting anyone’s CRM or inbox. In the EU that is not etiquette. It is a written precondition, and naming your sub-processors is part of it.

6. Article 22 does not bite where people think it does

The correction runs the other way here, before someone sells you a compliance package you do not need.

Article 22’s right not to be subject to a decision based solely on automated processing applies only where the decision “produces legal effects concerning him or her or similarly significantly affects him or her.” Scoring an inbound B2B lead as warm or cold clears neither bar. Routine lead scoring is not what Article 22 is for, and saying so is more useful than the vague warning most of this market repeats.

The real boundary is where the decision does have significant effect: eligibility, credit-like screening, pricing that materially disadvantages someone. There, where the processing rests on contractual necessity or explicit consent, the controller must provide the right to obtain human intervention, to express a point of view, and to contest the decision. At that point “keep a human in the loop for high-stakes actions” stops being a best practice and becomes an obligation with an article number behind it.

7. The disclosure rule that started applying four days ago

The EU AI Act’s Article 113 sets the general date of application at 2 August 2026. Article 50, the transparency article, is now live.

Article 50(1) requires providers of systems that interact directly with people to make sure those people know they are dealing with AI, “unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect.” Article 50(2) requires synthetic content to be marked machine-readably, and 50(5) requires all of it “at the latest at the time of the first interaction or exposure.” Then Article 50(4), second subparagraph:

Deployers of an AI system that generates or manipulates text which is published with the purpose of informing the public on matters of public interest shall disclose that the text has been artificially generated or manipulated. This obligation shall not apply where the use is authorised by law to detect, prevent, investigate or prosecute criminal offences or where the AI-generated content has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content.

Article 50, EU Artificial Intelligence Act

My post described the content-system offer as one that keeps producing “with you as the editorial backstop.” That phrase, written as sales copy, happens to describe the exemption: human review or editorial control, with a named person holding editorial responsibility. So stop selling it as a convenience and start specifying it as a control. Name the editor in the contract. Keep the record of what they reviewed.

I will state the limit of that reading plainly. “Informing the public on matters of public interest” is not defined in a way that obviously settles whether a client’s marketing blog falls inside it, and I am not a lawyer. The reason I would build to the exemption anyway is that it costs one named person and a review log, and the alternative is finding out.

What I would keep from the pitch, unchanged

Most of it survives, and the parts that survive are the parts that were never carrying a number.

The billing shapes hold. Bill monthly when the value is a system that keeps running, bill once when you hand over an asset the client owns, and use setup-plus-monthly when there is real build cost up front and ongoing value to maintain. Anchor the price out loud against the labour it displaces, so the buyer measures you against a salary rather than a software subscription. Polish belongs to that anchor rather than to vanity: a finished client-facing surface justifies a price a rough script will not.

The build shape holds. Almost all of these systems are one skeleton: capture, qualify and store, automate, dashboard. Build it once properly and re-skin it per vertical. And plan before generating: have the model turn requirements into a data model, workflows and views, read the plan, correct it with your own judgment, then build from the corrected version. One piece of wording I had loose, since I called it a reasoning engine. Anthropic calls Claude Code an agentic coding tool that reads your codebase, edits files and runs commands, and Claude the model family is a different product from Claude Code. Most Claude Code surfaces need a subscription or a Console account, so it is not free either.

Niching down holds, with the absolute removed. I wrote that “lead-gen for local dental practices” outsells “AI automation for businesses” every time. I have no survey and neither does anyone else selling that advice. The defensible version: one niche gives you reusable builds and outreach language that lands, which is a mechanism rather than a measured result.

And one observation, offered as an observation. I have watched people who were one demo away from their first client disappear into a config error for a month. I cannot quantify that and I will not pretend otherwise.

What I have now that I did not have before

Five numbers I can check, and one rule.

The numbers: a CVSS score and a vendor dispute that between them define who owns app data security. A response-time literature that measures outbound phone dials where it names a channel at all, is silent on channel where it does not, and nowhere measures 60 seconds. A 0.3% spam-rate ceiling with a 0.10% target and a 5,000-per-day threshold where the authentication requirement doubles. A model bill of roughly a dollar a month against a support-hours line that decides everything. And a date, 2 August 2026, after which the disclosure question has an article number attached to it.

The rule is the one my own pipeline taught me at a cost of 2,922 files: any system that runs unattended has to publish one number a human reads on a schedule, and if you cannot name that number before launch, you have not built a service. You have built something that will be wrong quietly for as long as nobody looks. Mine was wrong quietly for six months, and the number that would have caught it was the count of citations whose URLs did not resolve, which is now the check that has to pass before anything on this site ships at all.