BeeDI Cloud

Problem

Small suppliers can be forced into retailer EDI workflows without the staff, budget, or vocabulary of a large enterprise integration team.

Description

What I built or investigated

BeeDI Cloud is a live hosted retail EDI portal organized around the work a supplier must complete: receive readable purchase orders, acknowledge them, build ASNs and SSCC labels, create BOLs and invoices, track acknowledgments, certify retailer mappings, and move from sandbox to production.

Iterations

The work did not happen in one jump.

1. 01

   Mapped the product around the supplier’s operational sequence instead of a generic document inbox.

2. 02

   Built the web application and hosting stack on PHP, JavaScript, SQL, Windows/XAMPP, and SSL.

3. 03

   Added a local Ollama-powered workspace for product knowledge, content, outreach, SEO, campaign planning, and coding.

4. 04

   Reworked prompts after small coding models produced malformed marketing output.

5. 05

   Separated the product website, agent tooling, and customer workflow so each could evolve independently.

Result

Where the project landed

A publicly launched product site and application direction with a defined retailer-onboarding flow, hosted document workflow, and custom-integration path.

Lessons

What carried forward

• The product must translate EDI into the user’s job, not ask the user to become an EDI specialist.
• Local AI is useful when it is constrained by a maintained product brain and explicit output rules.
• SSL, deployment hygiene, and onboarding are product features, not hosting chores.

Images & evidence

Work in context