How a LegitScript application is actually reviewed

It helps to know what happens to a submission, because the shape of the review explains almost everything about why applications stall. It is not a queue of forms being checked against a rubric. It is a small number of analysts building a picture of a business from whatever sources they can reach, and asking questions when the picture does not resolve.

The four factors that set the pace

LegitScript declines to estimate review times, and its published position names what the length depends on: the order in which applications are received, the complexity of the application, how responsive the applicant is, and whether the answers provided are sufficient and transparent.

Read that as two clocks rather than one.

The first clock is the queue, which is how long before anyone opens your file at all. That one is purchasable: expedited processing moves the application forward so that review begins within two business days of submission. It buys a start, not a finish.

The second clock is the review, and it runs as long as the questions take to resolve. Nobody outside the certifier controls it, and two of the four factors that drive it, your responsiveness and the sufficiency of your answers, are entirely yours.

What the reviewer is assembling

Roughly in this order, though the work is not linear:

Identity and structure. Who owns the business, what entity operates it, where it is registered, who the principals are and what else they are or have been connected to. Prior enforcement history attached to a principal is discoverable, and it is better disclosed than found.

The clinical model. Who prescribes, under what licences, in which states, after what kind of patient interaction. Whether there is a synchronous encounter, whether an asynchronous model is permitted where you operate, how follow-up works, how adverse events are handled.

The supply chain. Which pharmacy dispenses, how it is registered, what it is permitted to compound, how the product reaches the patient. The distinction between a traditional compounding pharmacy and an FDA-registered outsourcing facility matters here, and stating the wrong one is a correction that costs a round trip.

The website, line by line. Every claim about a product, every implied outcome, every comparison to a brand-name drug, the pricing structure, the subscription and cancellation terms, the privacy disclosures, whether the provider relationship is described accurately.

The public record. Licence lookups, corporate filings, pharmacy registrations, complaint databases, prior warning letters.

The request for information is the mechanism

Almost every non-trivial application generates at least one request for information. It is not a bad sign. It is how the review is conducted, and treating it as an exam result rather than as correspondence is the most common way applicants make things worse.

What a request typically asks for is one of three things: a document that was not supplied, an explanation of something that appears inconsistent, or a change to the website. The third is the one that catches people, because it means the review is now blocked on your engineering backlog.

The arithmetic of a request is worth internalising. An answer that goes back the same day costs a day. An answer that waits for the one person who knows it to return from holiday costs a fortnight, and if that answer raises a second question, the file that was days from a decision is now weeks from one. This is the rework loop in its simplest form.

What a fast review looks like from the inside

Applications that are decided quickly share a shape. Every domain was disclosed before anyone asked. Every claim on the website was already defensible. Licences, registrations and the pharmacy relationship were documented in the submission rather than promised in it. The application and the website told exactly the same story about the business.

That is not a trick, and it is not an argument for optimism about timelines. It is the observation that a reviewer with no questions has nothing to wait for. Applications we have prepared and filed have been approved in as little as 3 days, and roughly two weeks from submission to a decision at the outer end. Those are our own recorded outcomes across completed applications, not typical results, not a commitment, and not something the certifier has agreed to. The decision and its pace belong to LegitScript alone.

What you can actually control

Three things, and they are worth being blunt about because everything else is noise:

• The state of your website when you submit. Fixing claims copy before submission costs a sprint. Fixing it during a review costs the review.
• The completeness of the submission. A document supplied up front is a document nobody has to ask for.
• Your turnaround on questions. Name the person who will answer, before you file, and make sure they will be reachable.

Everything else, the queue, the analyst's workload, the depth of the investigation your particular model warrants, belongs to the certifier.

After the decision

Approval is a state rather than an event. Certified merchants are monitored, and the certification is assessed against the website as it is, not as it was on the day it was granted. Merchants whose profile warrants closer watching may be certified on a probationary basis, with heavier monitoring attached.

Which means the discipline that gets you through the review is the same discipline that keeps you certified, and the handover from "we passed" to "nobody owns this any more" is where certified merchants most often get into trouble.

How to answer a request for information

Since the correspondence is where reviews are actually won and lost, it is worth having a house style before the first one arrives.

Read it twice and answer every part. Requests frequently bundle three questions into one paragraph. An answer that addresses two of them consumes a cycle and invites a sharper follow-up.

Attach rather than describe. "Our pharmacy is licensed in those states" is a claim. The licence list is evidence. Supplying the document closes the question; describing it opens a second one.

Say what you cannot supply, and why. Silence on part of a request reads as evasion. An explicit "we do not hold that, here is the equivalent" is a normal answer and it keeps the file moving.

Do not argue the standard. If a page has to change, change it. A reply explaining why the existing wording is defensible costs a round trip and rarely changes the outcome.

Send it the same day. This is the single highest-leverage habit in the whole process, and it is the one a business running the application between other priorities is least able to sustain.

Before you submit, decide who owns it

One person, named, available for the duration, with access to the corporate documents, the licence list and the pharmacy agreement, and with the authority to get a website change deployed. If nobody in the business fits that description, the review will be slower than the file deserves, and that is worth knowing before you file rather than after the second request arrives.