analytics
Portafolio de Iván
Projects chevron_right SIGO

Institutional product · public demo

corporate_fare Institutional sector view_kanban Kanban funnel qr_code_2 NPS via public QR task_alt 67 green tests

SIGO: an operations suite for convention bureaus

A convention and visitors bureau chases events: it finds them, bids for them, wins them and evaluates them. SIGO covers that full cycle in thirteen phases, with an executive dashboard and a discovery layer running on local AI.

open_in_new Open the public demo arrow_back Back to projects

Key numbers

13

build phases, each one usable

67

automated tests passing

23

numbered design documents

1

public live demo anyone can open

Tech stack

Laravel 13PHP 8.3PostgreSQL 18React 18Inertia 2TypeScriptTailwindSanctumspatie/laravel-permissionEChartsLeafletdompdfSearXNG
schema

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.

  1. travel_explore Pulse

    Opportunity discovery

    Open-source scanning helped by local AI, with an explicit rule against inventing.

  2. person_add CRM

    Prospect

    An accepted opportunity becomes a prospect inside the CRM.

  3. view_kanban Funnel

    Bid

    A Kanban board where the bureau competes to host and tracks progress.

  4. emoji_events Event

    Won event and event sheet

    The event moves into operations with all its information in one place.

  5. insights Close

    NPS and executive dashboard

    Evaluation via public QR and aggregated metrics for management.

store

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.

report

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.

rule

Key decisions

01 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.

psychology 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.

02 Import with an undo, not with faith

The CSV importer allows reverting a full load.

psychology 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.

03 Real permissions, not decorative roles

Role-based access control through a dedicated library, and token authentication for the API.

psychology 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.

04 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.

psychology 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.

construction

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.

emoji_events

Results

lightbulb

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.