Purchase Orders Arrived By Email And Phone

Purchase orders arrived by email and by phone. That is the entire intake process for a contract manufacturer whose customers are brand owners placing orders that turn into formulation, batching, filling, quality control and shipping. There was no electronic data interchange anywhere, and no evidence any customer had ever asked for one, which is worth saying because the expensive answer here is usually electronic data interchange and the expensive answer was not the right one.

What the customers did have was a legacy read-only viewer, and the number that made the case was its adoption: thirty one of around one hundred and twelve active customers had ever been given a login. The team's own conclusion, written before we built anything, was that adoption rather than features was the success metric. That framing shaped the build more than any requirement did.

So the thing we built is a separate application in its own trust zone. It shares the manufacturer's database and it never exposes a staff surface, which is not a policy, it is an architecture. Customers sign in against the existing user table, and it reads the legacy password hashes directly, so no customer had to be told to reset anything as the price of an upgrade. They submit a purchase order with catalogue lookup, tier pricing, reorder from their own history, a ship to address, notes and attachments, and those attachments are only ever served through an authenticated route scoped to their own customer number.

The detail we like most is the order timeline. Submitted, approved, in production, quality control, shipped, invoiced. It is derived from status signals that already existed rather than from a field somebody has to remember to update, because a manual status field is a promise the busiest person in the building has to keep. Then, when an account manager genuinely needs to say something the signals cannot, there is a free text status and a two way message thread alongside it.

On the staff side the submission lands in a review queue, where it is promoted into a real open order. Promote and approve are deliberately two separate gates. A customer submitting a purchase order is not the same event as the manufacturer accepting it, and collapsing the two is how a portal turns into a liability.

The security posture is where we would point a sceptic. Scoping is enforced by tests: there are test files whose entire job is to assert that one customer cannot read another's rows, and the customer number is denormalised onto every message row so a purchase order number alone is never accepted as proof of ownership. An independent review by a different model raised twelve findings, two of them critical, and the fixes went in. One of those fixes, requiring a current relationship at login, immediately locked out seven obsolete customer accounts that had working logins nobody had noticed.

It was built against a stale development copy of the database because production access did not exist yet, which we wrote down as a decision of record rather than a workaround, and then carried a verify on production checklist into the cutover. All fifteen tables were confirmed present on production before it went live.

We have no adoption number for after. The before number is the honest one we hold.