When a Delivery Estimate Is Really a Rate: The Small Print After the Number

Sixty-one deadlines and thirty-nine rates

A delivery estimate looks like a promise about time. Read the whole line and a good many of them turn out to be promises about time per something else. The VIT MARKET catalogue publishes an estimate for each of its 100 services, and VJOURNAL extracted them by a rule simple enough to state in one sentence: strip the clock symbol, take the first quantity and the unit attached to it, and treat whatever text is left over as a condition. Sixty-one listings leave nothing over. Thirty-nine do.

That residue is not decoration. In the largest group of cases it names the unit the number is charged against — one module, one source, one location, five hundred pages — which changes what the estimate is. A number that applies to a unit is a rate, and a rate becomes a delivery date only after somebody fixes how many units there are. The estimate is complete. The project is not.

The conditions cluster where the work repeats

The 39 are not spread evenly. SEO, content and traffic carries 16 conditions across its 25 listings; automation, parsers and bots also carries 16 of 25. AI solutions for business carries 5. Website development carries 2, which means 23 of its 25 estimates are bare numbers with nothing after them.

The split follows what the work is. A website is sold as an object: one landing page, one store, one admin panel, and when it is finished it is finished. A parser, a content pipeline or an SEO programme is sold as throughput, and throughput has to be quoted against a quantity or it means nothing. VJOURNAL reads the two web-development exceptions as proof of the same rule rather than against it — the two are email template layout, quoted per letter, and a template built to be sold repeatedly on a marketplace, quoted for the first template. Both are the web group's only pieces of repeat manufacturing.

Five kinds of small print, counted

Sorting free text is a reading, not a measurement, so here is the priority VJOURNAL applied: a residue that mentions a diagnosis or a separately priced plan was filed first, then one naming a unit of scope, then one adding recurring time after delivery, then one splitting the number internally, then one naming a factor that moves it. Each of the 39 lands in exactly one family.

By that rule: 26 attach a unit of scope, 4 name a condition that moves the number, 3 add a continuing tail, 3 buy a diagnosis before the work, and 3 explain how the quoted time divides internally. The scope-unit family is where the substance is, and its units are worth listing because they are so specific: per letter, per module, per source, per page, per video, per SKU, per first template, per site of up to 1,000 pages, per catalogue of up to 5,000 SKU, per database of up to 50,000 records, per 500 pages, per 1,000 to 3,000 search queries, per pilot of 500 to 1,000 pages, per two sites, per three sites, per three to five sites, per three to four data sources, per three to four email chains, per network of three to five locations, per five to eight step scenario, per five to seven templates, per pipeline. Twenty-six listings, and only two of those units appear more than once: the number depends on how much of it you want, and nearly every listing measures that in a currency of its own.

The unit is the part you have not agreed yet

Two automation listings in this catalogue publish exactly the same headline duration of 1 to 3 days. On one it is the whole job: an internal team bot with checklists, duties and reminders. On the other it is 1 to 3 days per module — custom code for n8n or Make, written where the standard nodes run out. The two numbers are identical and the two commitments are not remotely comparable, and nothing in a side-by-side listing view distinguishes them except the words after the digits.

That is the practical failure mode. A buyer comparing estimates reads the quantity, not the qualifier, because the quantity is where the eye goes. Yet in 26 of these listings the quantity is a coefficient, and the multiplier sits on the buyer's side of the table: how many modules, how many sources, how many locations, how many pages. Where the unit is a physical count the buyer already knows — three sites, two platforms — the estimate is a real date. Where the unit is a design decision nobody has taken yet, such as how many modules a bespoke integration needs, the estimate is an invitation to find out together.

What the catalogue lets you compute about the second unit

Four listings publish enough on their own line to price the marginal unit, and all four say the same thing: the first one is expensive and the next ones are cheap. The lead generator from open sources is quoted at 1 to 3 days per source, then half a day for each further source, which puts the second source at between 17 and 50 per cent of the first. The technical SEO audit is quoted at 1 to 2 days for a site of up to 1,000 pages and 3 to 4 days for 10,000 or more; taking the midpoints of both bands, a tenfold increase in pages buys a 2.33-fold increase in time. Local SEO is 1 day for a single location and 2 to 3 days for a network of three to five, so at the midpoints four locations cost 2.5 days — about 0.63 of a day each, roughly 37 per cent less per location than the first one. The price guard listing is 3 to 6 hours, plus 1 to 2 hours if a parser already exists, an add-on worth 17 to 67 per cent of the base.

None of these four is a law and VJOURNAL does not present them as one; they are four rows out of a hundred, chosen because they are the only ones that state two quantities on the same line. But the shape they share is the reason per-unit estimates exist at all. Setup dominates. The buyer who negotiates hard on the first unit is negotiating over the expensive part, and the buyer who assumes the tenth unit costs what the first one did has overpaid for a project that has not started.

The estimates that stop where your work starts

Four listings, all of them in the AI group, quote the construction of a machine rather than the delivery of an outcome. Batch generation of product cards is 3 to 7 working days to set up the pipeline, then hours per batch. Batch generation of advertising images is 4 to 8 working days for the pipeline, then hours per batch. SEO rewriting of product descriptions is 3 to 6 working days per pipeline, then in batches. Translation and localisation that preserves tone is 5 to 10 working days for the pipeline. In every case the published number ends at the moment the recurring work begins.

Two SEO listings describe the same arrangement from the other end. SEO for YouTube is quoted at 15 to 30 minutes per video after the pipeline is configured; SEO cards for marketplaces at 20 to 40 minutes per SKU after the template is set up. These are the only two minute-denominated estimates in the catalogue, and they publish the marginal unit while leaving the setup in the qualifying clause — the exact mirror image of the four above. Add the three continuing tails, among them 3 to 5 days to start and then 3 to 5 hours a week to run, and nine of the hundred listings are describing an ongoing relationship inside a field labelled duration.

What the small print cannot tell you

The five families are VJOURNAL's reading of free text and not a field in the data. Several rows could sit in two families at once — the lead generator names a unit and then adds a tail — and they were resolved by the priority stated above rather than by anything in the catalogue. Another editor applying a different priority would publish slightly different counts, and the 39 itself is the only figure here that is mechanical.

Two further limits matter more. The extraction takes the first quantity in the line, so where a listing puts its larger phase second the headline understates the job: the Core Web Vitals listing reads 1 day of diagnostics plus 1 to 3 days of implementation, and a machine reading the first number alone records a one-day service. And nothing in this data records delivery. There is no evidence here about how many modules a typical integration turned out to need, how many sources a typical lead list ended up using, or whether the per-unit rates held once the quantities grew. The catalogue publishes what work is offered at, not what it came to.

Turning a rate back into a date

Three moves convert a per-unit estimate into something you can put in a plan. Fix the quantity in writing before the price is agreed, because the quantity is the term the estimate leaves open, and a supplier willing to name a number of modules or sources is a supplier who has thought about your case rather than about the category. Then ask which side of the setup you are buying: if the estimate says after the pipeline is configured, the published figure covers the part you pay for once and says nothing about the part you will live with.

Third, ask what the second unit costs. Four listings in this catalogue answer that question in public, and all four discount the marginal unit heavily against the first. A supplier who cannot answer it either has not built the thing before or intends to charge you setup prices twice. Neither is a reason to walk away. Both are worth knowing before the scope is written down rather than after the second module appears.

Decision framework: per-module project estimates

An estimate stated per module is a rate, not a project duration, until the module count and completion rule are known. Repetition rarely stays linear when modules share data, design, review or deployment work.

The buyer must distinguish reusable setup, truly repeated work and exception handling. Multiplying one unit price by an unknown count hides both economies of scale and integration risk.

Ask for minimum batch, included setup, module definition, complexity exceptions, acceptance per unit and a capped total for the currently known inventory before approving the rate.