Project facts
- Type
- My own product for convention and visitors bureaus (CVB)
- Timeline
- June – August 2026
- Status
- Public live demo, built across 13 phases
- Role
- Product, system design, build and documentation
- Documentation
- 23 numbered design documents
Context
A convention and visitors bureau works like a mix of a sales team and a public body: it identifies congresses and events that could be held in its destination, prepares bids to compete for them, supports the ones it wins, and reports on results.
That work usually lives across spreadsheets, email and institutional memory. When the team changes, the knowledge of why a bid was won or lost simply disappears.
SIGO is my own product for that sector, with a public demo anyone can open. It is not an anonymous client's system: it was built to be shown.
The problem
What you learn from a lost bid is worth as much as what you learn from a won one, and it is the first thing to disappear.
A bureau's funnel is long: years can pass between spotting an event and hosting it. Without a system holding that memory, each cycle starts almost from scratch and decisions rest on who remembers what.
The discovery side has a problem of its own. Looking for events that might come to the destination means scanning scattered sources, and automating that with a language model carries an obvious risk: the system starts proposing congresses that do not exist, with plausible dates and invented organisers.
And underneath it all was the institutional requirement: real roles, auditable permissions, and data that can be imported and corrected without fear.
Key decisions
AI discovers, but neither invents nor decides
«Event Pulse» scans open sources using a model that runs on the server itself. Its results allow only three actions: accept, discard or convert into a prospect. The «no inventing» rule is written explicitly into its design.
A discovery tool that hallucinates events does not save work, it multiplies it: everything it proposes must be verified. By limiting AI to proposing candidates a person accepts or discards, the system adds reach without risking credibility.
Import with an undo, not with faith
The CSV importer allows reverting a full load.
In an institution, data arrives in spreadsheets made by several people over years. A load always goes wrong the first time; without an undo, fixing it by hand costs more than the work it saved.
Real permissions, not decorative roles
Role-based access control through a dedicated library, and token authentication for the API.
In the institutional sector, «who could see or change this» is a question answered to third parties. An improvised permission system does not survive that conversation.
A versioned API for the sibling system, with no shared tables
Integration with another system goes through an explicitly versioned API, not by granting it database access.
Sharing tables is the fastest integration to set up and the most expensive to maintain: any schema change breaks the neighbour without warning. A versioned API lets both sides evolve at their own pace.
An event's life cycle
Each stage has its screen and its data. What comes in as a detected opportunity ends as an evaluation feeding the executive dashboard.
Opportunity discovery
Open-source scanning helped by local AI, with an explicit rule against inventing.
Prospect
An accepted opportunity becomes a prospect inside the CRM.
Bid
A Kanban board where the bureau competes to host and tracks progress.
Won event and event sheet
The event moves into operations with all its information in one place.
NPS and executive dashboard
Evaluation via public QR and aggregated metrics for management.
The solution
SIGO was built in thirteen phases, each delivering something usable: prospect CRM, Kanban funnel, bids, won events, event sheet, NPS evaluation via public QR code, executive dashboard, CSV importer with undo, opportunity discovery, and the API for the sibling system.
The foundation is Laravel with PostgreSQL and a React interface served through Inertia, with charts and maps for the executive side and document generation for whatever has to be delivered printed or as PDF.
The process is documented in 23 numbered design documents, which is what lets a thirteen-phase product still make sense months later, and a suite of 67 tests holding the agreed behaviour in place.
Results
- A complete product in 13 phases, with a public live demo anyone can open and walk through.
- 67 automated tests passing and 23 numbered design documents.
- Opportunity discovery with AI running on the server itself, unable to convert anything without a human decision.
- Reversible data import and auditable role-based access control.
- Integration with a sibling system through a versioned API, with no shared tables.
What I learned
That in institutional products traceability is a feature, not decoration. Being able to say who did what, and to undo what went wrong, is what gets the system adopted.
That artificial intelligence needs a job with edges. «Propose candidates a person accepts or discards» is a brief it can do well; «keep the funnel up to date» is not.
And that documenting while building is cheaper than documenting afterwards. Twenty-three documents sound excessive until you have to revisit phase four while standing in phase twelve.
