Company
Cidesa Group
More than thirty years inside the financial and administrative operations of governments, private companies and health networks — and one platform built out of everything that taught us.
Where SIGA One came from
Cidesa Group started as a consulting firm: evaluating systems, redesigning administrative procedures and building software for institutions whose accounts have to survive an external audit. That work put us inside the same problems over and over — a budget system that could not talk to the ledger, a payroll that had to be re-keyed, a procurement process that lived in a spreadsheet, and a reporting deadline that arrived every quarter regardless.
SIGA One is the answer we built once we had seen enough of them. It is not a product we found a market for. It is a market we worked in for three decades, turned into a product.
years modernizing public and private administration
functional modules on one shared ledger and organizational model
sectors served by one configurable platform
A new product, not a new coat of paint
The domain knowledge in SIGA One is old. The software is not.
An earlier generation of these systems ran for years inside public institutions — budget execution, treasury, payroll, procurement, under real audit and real deadlines. That is where the rules in this product come from: which controls have to block rather than warn, what an oversight body actually asks for, which shortcuts look reasonable in a requirements document and fall apart in a closing period.
SIGA One is a ground-up rebuild of that understanding on an architecture that did not exist when the first version was written: cloud-native, API-first, one configurable codebase across sectors and countries instead of a branch per client. Nothing was ported. What carried over is the part that took decades to learn, which is not the code.
What we hold to
One codebase, configured
We do not fork a product per client, per country or per sector. Every difference between one deployment and another is data or configuration — because forks diverge, and diverged systems are how clients end up stranded on a version nobody maintains.
The system of record has to be the system
If the real numbers live in a spreadsheet next to the software, the software failed. Every module we build ends in a posted transaction, not in a report.
Say what is actually true
About what is built and what is not, about what a migration will cost, and about what we would not recommend doing. It is a shorter sales cycle and a much longer relationship.
Where we are
Offices in Miami and Orlando, Florida, working across Latin America with teams close to the institutions we serve.
Work with us.
Tell us what you are trying to change and we will tell you how we would approach it.