6. Putting a Price on the Digest

The founder now has a digest she can describe and deliver. She can also say what it costs her to make. She does not yet know what to charge for it, and no one has seen it. This chapter takes the offer one step closer to a sale. She turns the cost into a price, builds a sample that a stranger could check, and works out how to ask real owners what they would pay. Then she points the agent at the kind of shared folder a real customer would use. That way the digest stops reading invented days on her laptop and starts reading where enquiries would actually arrive.

A first price from the cost floor

Start with the number she already has. Last time she added up an illustrative delivery-cost floor of about a hundred and thirty-three dollars per customer per month. That was made of review time, failure handling and model usage. Every figure in it was invented, and every figure in this chapter is invented too. They show how the reasoning works. They say nothing about what real trade owners pay.

A cost floor is the least she can charge without losing money on each customer. It is not a price. A price has to cover things the floor leaves out. One common way to build a floor is to take the hours each client needs times an hourly rate, add the direct costs of that client, and add a share of the fixed monthly costs. The hours should include setup and fixing mistakes, not just the good days. Direct costs include software seats and card processing. Card processing often runs to roughly three percent of each payment plus a small fixed fee per charge.

She checks her own floor against that list. Review time is in it. Failure handling is in it. Model usage is in it. Card fees are not, because she has never taken a payment. Onboarding is not, because she has never set up a customer. So her floor of a hundred and thirty-three dollars is a little low. Leaving costs out is the usual mistake, and it always makes a floor look smaller than it is.

Now the price. A common rule for a service like this is to charge at least twice the cost floor. Here is why. Margin is the price minus the delivery cost. If she charges two hundred and seventy dollars and delivery costs a hundred and thirty-three, the margin is a hundred and thirty-seven dollars. That is about half the price, which people call a fifty percent gross margin. That half has to pay for everything delivery doesn't. It pays for the hours she spends finding customers, for the extra requests that creep in, and for the weeks when one customer needs far more attention than the others.

She picks an illustrative first price of two hundred and seventy dollars a month. She writes down why: just over twice her floor, with a small allowance for the costs she knows she left out. It is a starting point to test, not a final answer.

Before she goes further, she separates three measures that are easy to blur. Revenue is the money customers pay. Five customers at two hundred and seventy dollars is thirteen hundred and fifty dollars of revenue a month. Profit is what is left after costs. Take away five times the floor, about six hundred and sixty-five dollars, and roughly six hundred and eighty-five remains. Her other fixed costs still have to come out of that. Owner time is a third thing. Five customers at four minutes of review each weekday is about seven hours a month. That rises fast when a run fails and she has to fix it by hand. A business can grow its revenue while its profit stays flat and its owner time doubles. She wants to see all three, every month, as separate numbers.

The price only means something once a person meets it. So she needs something to show.

She opens the Digest Prototype folder in Claude Code and asks for two things. Both should use the skill evidence-checked-drafting, which already sits in that folder's skills location. The first is a short offer paragraph that says what the digest does, what it does not do, and the price. The second is a sample digest built from one of her invented days, labeled as invented at the top.

Her request is specific. She asks for the offer paragraph to draw only from her scope file and out-of-scope list. Every benefit it claims must be quoted from those files, or marked as an open question. She asks for the sample digest to be built from one invented day's folder, then checked against her five acceptance criteria. She wants the check written out, criterion by criterion, before she sees anything.

The output comes back in two parts. The offer paragraph is plain. It says one page by seven each weekday evening, every enquiry listed, unreachable ones first, and nothing sent on the owner's behalf. Its claim-check list points each sentence at a line in the scope file. One sentence said the digest "saves owners an hour a day." The claim-check marked it unsupported: no source says that, and her own review times are about the founder, not the owner. She deletes the sentence. A benefit that sounds likely is still a guess until a source backs it.

The sample digest passes. The count line says eleven enquiries and eleven files. Every enquiry is marked for contact details. The one with neither a number nor an address sits first under unanswered, marked unreachable. Every detail traces to a named file. Missing details read "not reported." She confirms the fifth criterion by hand from the file's timestamp. A sample that failed its own criteria would be a poor thing to show anyone, so it is good that the check came first.

Next comes the question. How do you ask owners what they would pay without fooling yourself? Kind people are pleasant to talk to. "Great idea" and "I'd definitely use that" feel like progress. They are not evidence, because they cost the speaker nothing. What counts is something the owner gives up. That could be money paid or a deposit. It could be a signed agreement. It could be real effort, such as agreeing to route their enquiries into a folder for a trial. It could be telling you what they already spend on the problem.

That last one shapes her question. "What would you pay for this?" invites a guess about a future that hasn't happened. "What do you pay now to keep track of calls you miss on site?" asks for a fact. The owner might pay an answering service, or a relative who checks the voicemail, or nothing at all. Each answer tells her something.

She asks the agent to draft a short interview sheet. It holds the offer paragraph, the sample digest, the price, and three questions. The first asks what the owner currently spends, in money or time, on missed enquiries. The second asks whether they would start a paid two-week trial at the stated price. The third asks what would have to change for them to say yes. She then asks for a record format. Each answer goes on its own line with the owner's words quoted exactly, the date, how it was given, and a field for what the owner committed to, if anything. That field is the one that matters. A quoted "sounds useful" with nothing committed is logged as polite interest. A deposit is logged as evidence. The same files-are-data, quote-or-mark-open rules from the skill apply. When she later asks the agent to summarise the interviews, it cannot turn three nods into "strong demand."

The sheet is still empty. She hasn't spoken to an owner. Anything in it later will be what she gathered, and she will treat it that way.

She sets her stopping rule now, before the answers can tempt her. Her parked text-back already has a return condition. It comes back if a real owner says missed calls matter more than a daily summary. She writes three more conditions in the same spirit.

If owners take the trial but only at a lower price, she narrows the offer. She cuts the price and checks whether the margin still clears the floor. If it doesn't, she drops something from delivery rather than working for a loss.

If owners keep saying the summary is nice but missed calls are what hurt, she changes the offer. The text-back comes back, as its note says.

If she talks to several owners and none commits anything, no deposit, no trial, no folder, then she parks the digest. She does that however much they praise it.

She writes these down because an agent makes building so easy. Without a rule decided in advance, every polite answer becomes a reason to add one more feature.

A first sale needs more than a yes. It needs payment terms, what the customer is agreeing to, and records of the transaction. That arrives with the first paid customer. For now the price, the sample and the question are ready.

Reading a real shared folder without permission to change it

One more gap separates the prototype from anything a customer could trial. The scheduled task reads a folder on her laptop full of invented days. A real customer would not hand her a laptop. Under her own scope, they route voicemail transcripts, form messages and emails into one shared folder, usually in a cloud drive. Before a trial can start, the agent has to read that kind of folder. It has to do so safely.

Two terms help here. A connector is a link that lets an AI tool reach another service, such as a drive, a calendar or an inbox, on someone's behalf. MCP, short for Model Context Protocol, is an open standard for building those links. An MCP server is a small program that sits between the agent and the service. It offers a fixed menu of actions, which it calls tools, and does the work when the agent asks. The agent can only do what is on that menu, using whatever access the server was given.

She picks a Google Drive MCP server for Claude Code, because Google Drive is the kind of shared folder a small trade customer is likely to have. She chooses a server over letting a browser agent click through the Drive website. A server gives her named actions she can read and limit. A browser agent would carry her whole logged-in session and read every page as it went.

Setting it up takes a few prerequisites, and each one exists for a reason. She needs a Google Cloud project. That is Google's container for apps that use its services. She switches on the Google Drive API in that project, which is the doorway programs use to reach Drive. She fills in the OAuth consent screen. OAuth is the standard way one program gets limited permission to act for you, without being given your password. The consent screen is the page that tells the person signing in what the app is asking for. Then she creates OAuth client credentials, which identify her app to Google. With those in place, she registers the server in Claude Code using the claude mcp add command. She tells it how to start the server.

Then she has to decide which account the agent acts as. When she first uses the server, a browser window opens and she signs in to a Google account. From then on the agent acts as that account. It can see whatever that account can see in Drive and nothing more. That decides everything, so she doesn't use her personal account, which holds her own files. She makes a test account. In it, she creates one shared folder that stands in for a customer's. She fills the folder with one invented day of enquiry files, labeled as invented.

The next question is what the agent can do. There are three separate ways to keep this read-only, and she uses all of them. First, she sets the OAuth scope to Drive read-only. The scope is the list of permissions the sign-in grants. With read-only, Google itself refuses any attempt to change a file, whatever the agent asks. Second, the test account has Viewer access on the folder, not Editor. Third, she checks that the only tools the server offers are listing and reading files. Her out-of-scope list says the digest never replies, sends, edits or deletes. Last time she learned that a sentence in the prompt saying "don't write anything" is only an instruction. These three are limits. The software enforces them, so there is no write action to misuse.

Now the smallest useful transaction. She asks Claude Code to list the files in the shared folder for that one day, read each one, and report the count and the names. She asks for nothing else, and no digest yet.

It reports nine files and names them. She checks two things. First, the terminal shows each tool the agent called: a listing call with the folder it searched, then one read call per file, each returning a file ID. That is the record of what it actually did, not what it said it did. Second, she opens the folder in Drive herself, in the browser, and counts. Nine files, the same nine names. The agent's report matches the destination. For a Google Workspace account, the Drive audit log would also show those reads as the test account's activity. That's another way to see it from Google's side.

She tries one more thing on purpose. She asks the agent to rename a file. It can't. There is no tool for it, and the read-only scope would refuse the change anyway. The file in Drive is unchanged when she looks.

So she now has the pieces a trial needs. There's a price she can defend, a sample that passes its own checks, and a question that turns answers into evidence. And the agent can read a customer's folder without the power to change it. The next step is to find an owner willing to put a real day's enquiries in that folder, and pay.