Your First Enterprise Customer's Requirements List: What Each Line Means and Where It Goes

An enterprise customer, in the sense this page uses the word, is the company that wants to buy from you, not the car rental firm or the starship that share the name. SOC 2 here means the report a buyer asks a software supplier for, not the accounting sense of those letters and not the room full of screens. The moment is narrow and specific. Your app works, people pay for it, and somebody at a much larger company has just sent a list of requirements with a date on it that you had no part in choosing.

Most lines on a list like that are answered from documents that already exist, either yours or the platform’s you build on. A smaller number need something inside the app to change. Often one line is the reason the deal has not closed, though nothing here was counted against a sample of reviews, so treat that as a possibility to test rather than a rule: list every line that is still open, who owns each, and what evidence it needs, then ask the buyer which one is deciding it. Working that out takes a day rather than a quarter.

What follows takes the lines that turn up on these lists one at a time, says what the buyer is actually asking for on each, and says which of four owners can settle it. Where another page here already answers a line in full, this one points at that page instead of repeating it, because a hub that re-answers its own members is just a longer version of them.

Most of an enterprise requirements list is paperwork you already have or your platform already publishes. A smaller part needs a change inside your app. One line often decides the deal. Sort the list by who owns each answer, then ask the buyer to confirm which line is the blocker.

Every line below is described from the documents a buyer’s own request points at: two platform documentation pages and two builders’ trust addresses, one publishing a machine-readable profile and one rendering almost nothing, each read raw on 3 September 2026, the whole page including its navigation, each named in the sentence that uses it, plus one fixed set of applications this site has read at the code level, and the pages here that already own a line, linked rather than repeated. Nothing was built, hosted, configured, tested, audited or run for this page, no requirements list was answered for anybody, and no sentence here is legal advice, nor a judgment about whether one app or another satisfies a standard.

The list, and which line is actually blocking the deal

Four owners settle every line on one of these lists: a document your platform already publishes, a change inside your own app, an outside firm that has to be booked and paid, or a term in a contract. Sorting by owner beats sorting by how hard each line looks, because the owner tells you what a week can move and what it cannot.

The platform lines are the cheapest. Somebody else has already done the work, published the result, and your job is to find the page, read it, and quote it back with the date you read it on. The app lines are the ones with real work behind them, and they are the reason this list arrived at an owner rather than at a compliance department. Outside-firm lines cost money and calendar time, and no amount of writing will shorten them. The contract lines are signatures, and they usually wait for whoever is going to read them properly.

Two things are worth doing before you answer a single line. Ask the buyer which lines are conditions of purchase and which are preferences, because most lists mix the two and almost none of them label which is which. Then read your own list against the owner column above and count how many lines are already sitting on a page somebody else maintains. On a first list, that is usually most of them, and the fear that the whole sheet is a quarter of work tends to survive about twenty minutes of looking.

The paperwork lines: the report, the trust page and the questionnaire

When a buyer writes SOC 2 on a list, what sits at the end of that road is a report an outside firm produces after examining your company, which makes it a booking and a bill rather than something you can write at your desk this week. That matters mainly because it changes what you say back: a date and a plan are a real answer to that line, and a promise to send the report next Tuesday is not. Whether a report is even the ask, or whether this buyer would accept something smaller, is a decision in its own right, and it comes ahead of any of the work. So is the question of which type the buyer wrote down and what a first one settles now against what a second one settles later. What that bill looks like once it is broken down into who actually gets paid is a separate question again. If the buyer named a different standard instead, the same decision runs the same way and the same page covers it.

A trust page is the self-serve version of this entire conversation, and it is worth understanding what one contains before you decide whether you need one. Bolt publishes a trust page at trust.bolt.new. Read on 3 September 2026, its machine-readable section carries a profile address, a profile identifier, a published timestamp and a last-updated timestamp both stamped 8 July 2026, and a certifications list naming SOC 2 Type 2, GDPR and CCPA. That is the whole idea in one page: a reviewer who can open something like that, read it and take what they need does not send you a list in the first place. What a platform’s own certificate settles for a buyer, and what it leaves sitting with you, is worked through on what a platform’s compliance status actually covers.

The same read is worth running against whatever platform you build on, because a trust page can exist and still hand an automated reader nothing at all. Lovable’s trust address at trust.lovable.dev returned twenty characters of text, the words Lovable Trust Center, to a plain request and to a browser-shaped one on 3 September 2026. That is one address on one day to an automated read, and it says nothing about what the vendor will send a customer who asks in writing. It is the reason a line on a buyer’s list is answered by asking the vendor directly and dating the reply, rather than by pointing at a page and hoping.

Some buyers send a form instead of a list, or a form after the list. A form usually comes from a vendor risk function rather than from the person who wants to buy from you, which is why it reads as though it were written for a company with a security department: it was. The form itself, taken row by row, moves to a pattern of its own and has its own ways of going wrong, and it is covered in full elsewhere on this site.

The login line: what single sign-on means on a buyer’s list

On a buyer’s list, single sign-on means their staff getting into your product with the same work account they use for everything else, so that the day somebody leaves, one action in one place shuts every door at once. That is what is being bought. Several different asks travel under that one phrase, though, and they are priced nothing like each other: the button that lets someone sign in with a work account, the arrangement where the customer’s own identity system decides who gets in, and the automatic creation and removal of accounts as staff join and leave. Which of them you were sent, and what each one changes inside an application put together with AI tools, is settled in its own place. The only thing to carry away from this paragraph is the warning: do not agree to the phrase before you know which of the three the buyer meant, because two of them are small changes and one of them is not.

The audit-log line, and the two different things that share the name

Two entirely different records get called audit logs, and a buyer’s list nearly always means the second one.

The first is a record of what happened in the tool the app was built in. Lovable’s enterprise documentation, read on 3 September 2026, describes its audit logs as “Searchable workspace activity logs for membership, roles, groups, SCIM, SSO, integrations, project lifecycle events, secrets, and prompts”, with entries that “include actor, IP address, user agent, and structured JSON” and are “Retained for 13 weeks (approximately 90 days)”. The same page marks that feature “Enterprise only” and says features marked that way “require a contract”. Every event in that description happens in the workspace where the software gets built. None of them is one of your customers using your product.

The second is a record of who read, changed, exported or deleted one particular customer’s records inside the running app. That is the one on the list. A reviewer asking for audit logs is asking whether, if a person at their company misuses your product, anybody could tell afterwards. It is a change in your own software rather than a line item on somebody’s price list.

The database underneath helps less than owners expect. Supabase’s logging documentation, read on 3 September 2026, ties how long those logs survive to the plan a project sits on and sends the reader to its own pricing page for the windows. The same page routes statement-level query logging through a switch somebody has to throw: enable the pgAudit extension, then configure pgaudit.log, whose stored value the page says “determines the classes of statements that are logged”. Until that is done the platform is not keeping the record the buyer asked about, and once it is done the entries describe statements rather than people, which is a different thing from a name beside a record at a time.

So the honest shape of this line is that part of the answer is a plan and part of it is work. How long a platform keeps its own logs, and why the record of who read a customer’s record stays yours to write covers the platform half in detail for an app holding health data, including the retention a plan buys you. This page adds only the naming problem, which is the part that costs owners a week: agreeing to audit logs while thinking of the record the builder sells is how you end up promising something nobody has built.

The data lines: what the model keeps, what the agreement says, and where the rows sit

Three separate lines usually sit in this part of a list, and they get confused with one another constantly.

The first is zero data retention, which in a buyer’s sense is a written term about what a model vendor keeps after your app sends it something, not the settings toggle inside a chat product or a coding editor that wears the same words. It is the model vendors’ own published terms that answer it, and what each of them publishes about retention, and how the term is asked for, is set out where those pages are read closely.

The second is a data processing agreement. The initials collide with a data protection authority, a durable power of attorney and a deferred prosecution agreement, and the buyer means none of those: they mean a contract between the company buying from you and the company running the app, about how customer data is handled and which other companies get to touch it. Signing one commits you to a list: what you process and why, the security you keep, how you handle access, correction and deletion requests, how fast you report an incident, what happens to the data at the end, and which other companies touch it, which is where naming your own vendors honestly comes in. A contract lawyer or whoever owns your customer contracts should read it before you sign. What a customer’s version of that agreement usually asks for, and which of the services your app already calls end up written into it, is a subject on its own. If the data in question is health data, which builders and platforms will sign the letter that goes with that, and on which plan, is mapped separately again.

The third is where the rows physically sit, which is the same question as the servers line below and is answered there.

The servers line: when a buyer wants it running in their own environment

This line arrives in several different strengths. A named region is one thing, an account the buyer controls is another, and a copy running inside their own network is a third, and the wording that arrives in the email seldom says which one. What decides the answer is which layer would have to move: the running application, the database under it, or the tool the whole thing is built and edited in. What a request to run it yourself actually splits into takes that apart for one builder, including which layer will not move at any price. Whether one customer requirement justifies moving off the builder entirely is answered by the five triggers that send owners looking for the exit, three of them fixable without moving, and it resolves to a no more often than owners expect. A buyer who makes their own infrastructure a condition of purchase changes the shape of the whole deal rather than one line of it, and that case is worth reading up on separately before you answer.

The outside-test line

A request for a penetration test is one of the few lines you cannot satisfy by opening a document. The exact wording of the request decides what will be accepted, and the gap between a scan, a read of the code and a test run against the live product is usually what the wording is choosing between without saying so. What a customer or an examiner will actually accept when they ask for a test works through the wordings and what each one costs to satisfy. Nothing on this page changes that decision, and the only mistake worth naming here is buying the cheapest of the three and discovering the buyer wanted a different one.

The line that asks you to prove the code was built properly

The vaguest line on most lists is also the one owners dread most. It asks, in one wording or another, whether the software was built to a reasonable standard, whether anybody outside has reviewed it, or lately whether AI wrote it. There is no document that answers this one, which is why it gets left until last.

What the line is really testing is whether anybody outside the owner’s own head has ever read the code. That is worth knowing before you panic about it. Across the fixed set of 26 applications this site read at the code level in June and July 2026, made up of 11 third-party applications examined closely, 10 more that had not been seen before and 5 built by the founder, each finding confirmed against the code itself rather than matched by pattern, four came out of that read with nothing confirmed as critical. The fixed set of 26 and the ledger behind it is where those counts are kept and how they were reached.

Four out of 26 is not a comfortable number and it is not meant to be one. What it does say is that a first read of an application nobody has read is not automatically a disaster, and that the outcome of this line is genuinely unknown until somebody looks. Owners tend to assume the answer, in both directions. The ones who assume it is fine have usually never had the database rules tested with two accounts. The ones who assume it is a catastrophe are often carrying a list of unfinished work rather than anything a buyer would refuse to sign over.

The practical move is to treat this line as a question with an answer rather than a verdict waiting to land. Whether an outside read of an AI-built app is worth buying, and what it does and does not settle is the decision, and it is worth making on its own terms rather than because a buyer used the word review. How much of what a buyer files under compliance turns out to be code rather than written policy, in a company with nobody whose job that is, is a question of its own.

What to send back this week

Three habits make a first reply work, and none of them is about writing well.

Name the blocker out loud. Tell the buyer which line you believe is the one deciding this, and ask them to confirm it. Reviewers will usually tell you, and a week spent on the wrong line is the commonest way a first deal like this stalls.

Never answer a line from memory. Open the page, or the setting, look at what it says today, and write the date you looked beside the answer. Vendor documentation changes without anybody being told, and a dated answer is the only kind that survives somebody else editing their own page next month.

Put a date on anything that is not true yet. A line you cannot say yes to is rarely fatal at this stage. A line you say yes to and cannot support three months later is a different kind of problem, and it is the one worth spending the week avoiding.

AxonBuild answers no requirements list, writes no policy, sits no examination for anybody and produces nothing a customer could file. What it does is change the app itself when a line on the list turns out to need code: an access control, an audit log, a data export. None of that is legal advice, none of it certifies anything to anybody, and none of it is a test run against a product that is live.

Common questions about a first enterprise customer’s requirements

What is the difference between security and compliance when a customer asks for both?

They are different questions with different judges. Security is about what the software actually does when somebody tries something it was not built to expect. Compliance is about whether you can show an outside party that agreed practices are being followed, in a form that party accepts. An app can be sound and have nothing written down, which fails a review, and an app can have every document in place and still let one customer read another’s records. A buyer’s list usually mixes the two without labelling either, which is why sorting the list by who owns each answer is more useful than arguing about which of the two words applies.

Is the customer asking for paperwork, or for something in my app to change?

Both, but not in equal amounts. On a first list most lines are paperwork: pages your platform already publishes, practices you can write down in an afternoon, contract terms somebody signs. The lines that need software to change are usually few, and they cluster around who can get in, what gets recorded, and where the data sits. Telling them apart is quickest if you ask, line by line, whether the answer would change if you edited a document, or whether it would only change if somebody edited the application. The second kind is where the week goes.

Which of these requirements can actually be settled in a week?

Nearly all the paperwork ones. Reading your platform’s published pages and quoting them with dates, writing down what you already do, filling in the buyer’s form and signing contract terms are usually a week’s work for a single product, longer if the answers depend on a platform document you still have to find or a term the buyer’s lawyers push back on. What cannot be done in a week is an examination by an outside firm, a test run against the live product by somebody qualified, or moving the running application into another company’s infrastructure. Those three have calendars and invoices attached, which is exactly why finding out which line is blocking the deal matters more than answering everything quickly.

My customer sent a list rather than a form. Is that a different job?

It is the same job in different clothing, and the list is usually the easier of the two. A list tends to be written by the person who actually wants to buy, so it carries the requirements that matter to them. A form is written centrally for every supplier a company might ever use, which is why it asks about warehouses and data centres that have nothing to do with a small software product. Both are answered the same way: from documents, from pages you have opened, and with dates written next to the answers.

Answering the form version, row by row, has a shape and a set of traps all of its own, and there is a page here that works through it.

What does a buyer mean by enterprise ready?

Nothing standard, which is why the phrase is worth turning back into lines. In practice a buyer using it means some combination of the same handful of things on this page: a report, a way for their staff to sign in, a record of who did what, a signed agreement about data, and somewhere they can read your answers without emailing you. Ask them which of those they meant. A buyer who cannot answer has told you something useful about how firm the requirement is, and a buyer who can has just handed you the list this page is about.

Do I have to answer every line before they will buy?

Usually not, and answering everything before asking which lines count is the most common way a week disappears. Most reviews carry required lines and preferred lines and print them on the same sheet in the same font. Naming a line you do not have yet, with a date attached and a next step, costs far less than agreeing to everything on the sheet and being asked to demonstrate it after the contract is signed. Ask which lines are conditions of purchase, answer those first, and put honest dates on the rest.

What should I ask the customer before I answer anything?

Two things before anything else. Which lines would stop the purchase if the answer were no, and what date the answers are genuinely needed by, which is often later than the date printed on the email. A third is worth adding when the list came from a large company: whether somebody there is allowed to accept an answer that is not a yes. Almost every review has a person in that role, and knowing whether they exist tells you whether an unanswered line ends the deal or starts a discussion.

Does any of this change because the app was built with AI tools?

Only in one place, and it is not the one owners fear. The paperwork lines do not care what produced the code. The line asking whether anybody outside has read it does, because an application assembled quickly by a tool has often never been read by anybody, including the person who owns it. That is a real gap and a fixable one, and it is why the section above about proving the code was built properly exists at all. The rest of a buyer’s list is the same list a small team writing every line by hand would receive.

Where this leaves you

Sort the list by who owns each line before writing a word of the answer. Ask the buyer which lines are conditions of purchase and which are preferences, because the sheet will not tell you. Answer the platform lines from pages you have opened, with the date beside each one. Then spend what is left of the week on the single line that is genuinely blocking the deal, which on a first list is usually one line, and almost never the one printed at the top.