The project blueprint — fill it at the start of any project

For: a partner, a customer's own IT team or our Custom Development team starting a project for an iVendNext customer, before quoting it and before building. Reference: the demand-to-ladder map (the sampled needs and the ladder classes), the extension-point catalogue (guide chapter 9, The extension-point catalogue and requests), guide chapters 3 and 15 (The ladder, Customer archetypes) and the feedback forms (../feedback/).

A blueprint is one page per project that answers six questions: what does the project do, which door does each need use, how big is it, what does it connect to, which extra work does it switch on, and what could go wrong. It is the same page for a three-store shop and a fifty-store chain. The needs decide what the project gets, never the customer's size: "Standard" and "Enterprise" describe a customer, and they route nothing.

How to fill it

1. Copy the template below into your project.
2. Write section (a) first. Then list every need in (b), one row each, in the customer's words.
3. Place each need on the ladder. Find the nearest sampled need (or, if none is near, the nearest request class) and take its ladder class. Pick the door. Set the status from the table in section (b).
4. Fill (c) and (d) with real figures, or with a stated guess. A guess is fine if it is marked as one.
5. Read (e) against the first four sections. Each module that applies is switched on, and its extra work joins the project.
6. Write (f). A risk you did not write down is one you will meet on the day.
7. Keep the blueprint up to date as scope changes. Attach it, or link it, to any point request, sample request or kit defect that concerns the project.

The ladder classes (the same names as the demand-to-ladder map):

The doors, in order: configuration · outside app (the API and the event feed) · till key · manifest · sandboxed function · a request for an extension point. A rung is used only when the one above cannot do the job. The four rules (guide chapter 3) apply to every row.

The template — copy from the line below

# Blueprint: <project name>

Prepared by: <outside partner | customer IT team | Custom Development team>
Date: <date> · Version: <n>
Kit version: <the version of the kit you worked from>
Sandbox / staging site: <the site you tried it on>

## (a) The project in two lines
<What the customer wants, and what you will deliver. Two lines, no more.>

## (b) Fit-gap on the demand-to-ladder map
| # | Need (customer's words) | Nearest sampled need or request class | Ladder class | Door | Status | Note |
|---|---|---|---|---|---|---|
| 1 | | | | | | |

## (c) Scale profile
| Measure | Value | Basis (counted / estimated) |
|---|---|---|
| Stores | | |
| Tills per store, by kind (counter · phone · tablet · Handheld) | | |
| Active products (and variants) | | |
| Customers on file | | |
| Sales per day per till — an average day | | |
| Sales per day per till — the busiest day | | |
| Lines per sale (average) | | |
| Peak-hour share (share of a day's sales in the busiest hour) | | |
| Offline hours expected per till per week; the longest single outage | | |
| Integration event volume per day; at the peak hour | | |

## (d) Integration map
| System | Direction | Door | What moves | Volume (per day / peak hour) | Who owns the far side | Our connector or your app | Identity map kept by | If the far side is down |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |

## (e) What this blueprint switches on
| Module | On / off | Because (row or figure) |
|---|---|---|
| Joint extension-point lane | | |
| Scale proof | | |
| Release gate in the customer's CI | | |
| Dedicated bench (Custom Development only) | | |

## (f) Risks and open questions
| # | Risk or question | Touches | What would settle it | Who can answer |
|---|---|---|---|---|
| 1 | | | | |

(a) The project in two lines

Say what the customer wants and what you will deliver, in business terms. If it takes more than two lines, it is two projects.

(b) Fit-gap on the demand-to-ladder map

One row per need. The columns:

Status, from the ladder class and the catalogue:

⛔ A need that can be met only by breaking one of the four rules is not a row with a door. Rewrite the need ("what must be true for the customer") and place that.

(c) Scale profile

The profile says how big the estate is and how hard it is pushed, in numbers a test can reproduce. The scale-profile kit (tools/scale_profile/) books real till sales on a bench and reports the profile against what it measured — and, every time, what it did NOT measure (concurrency, many stores, a large catalogue, offline drains). Its figures are sequential, and no load test exists anywhere else, so a stated profile is the only way anyone will know the estate was ever sized. python3 tools/scale_profile/report.py <your profile.json> <the measurement> turns this section into that report.

Work out the peak. From the figures above:

sales per day               = stores × tills per store × sales per till per day
sales in the peak hour      = sales per day × peak-hour share
sales per minute at peak    = sales in the peak hour ÷ 60

Do it once for the average day and once for the busiest day. Then check it against the known limits (below).

Known limits to check your profile against (guide chapters 15 and 16):

(d) Integration map

One row per outside system. The door is the event feed, the API or a file. A system with two directions gets two rows.

• Our connectors first. Where one of our connectors fits (the online shop, the ERP), name it. A connector replaces a row of your own work.
• Identity map. Every sync that keeps records on both sides needs someone to hold the map of record ids. Say who holds it.
• If the far side is down. Say what waits, where, and what catches up. The event feed holds what you have not collected.
• Who owns the far side is a role ("the customer's IT team", "the ERP vendor"), not a person.

(e) What this blueprint switches on

The needs decide, not the size. Each module below is switched on by something in sections (b) to (d), and by nothing else. The triggers are the proposed ones; a module you switch on adds work, and one you leave off is a risk to write in (f).

(f) Risks and open questions

Write what you do not yet know, and what could stop the project. Use these prompts:

• A row's bound that the customer has not yet accepted.
• An extension point the project waits on, and what you do if it slips.
• A figure in (c) that is a guess.
• A far side whose rate or availability you have not seen.
• Offline: what the stores do in a long outage.
• What the customer's gate will refuse.
• A need you could not place.

Each item names what would settle it and who can answer. Items that are questions to us go to the right form.

A filled example — a generic mid-size retailer

Invented for illustration. It is a specialty retailer with fourteen stores in one country, its own ERP and its own loyalty programme, and an online shop run by a separate team. No real customer.

Blueprint: Estate roll-out and own-systems link for a fourteen-store specialty retailer. Prepared by: customer IT team · 2026-10-04 · version 1 · kit of 2026-10-04 · the team's own sandbox site.

(a) The project in two lines

The retailer runs its stores on iVendNext POS and keeps its own ERP and loyalty service. We deliver the configuration, a manifest for the loyalty records, an outside service that links the ERP and the loyalty service, and the release gate.

(b) Fit-gap

(c) Scale profile

Peak. Sales per day = 14 × (180 + 3 × 40) = 4,200. In the peak hour: 4,200 × 14% = 588, or about 9.8 a minute. On the busiest day: about 24.5 a minute. That is above the 2.75 sales a minute that one of our Acumatica connections books, so the ERP leg must be sized by the retailer's own ERP intake, not by that figure (the retailer's ERP is its own, and is the far side in (d)).

(d) Integration map

(e) Switched on

(f) Risks and open questions

This page in the kit