The walkthrough, one point of view at a time
The same screen means different things to whoever invests, builds, invoices and supervises. This walkthrough goes person by person rather than feature by feature, so each one finds their part without hunting for it.
The screens below are mockups built with the product's own design system, not screenshots. They move with the platform instead of ageing alongside it.
The investor
Arrives through the public dashboard, goes through the invitation and KYC, and only then sees the terms. The order is not paperwork: it is the legal control that allows a private offering to be advertised at all.
- /transparencia
Step 1 of 6
Looks at the project without signing up
The public dashboard shows construction progress, executed spend with its receipt, solar generation and on-chain attestations. Everything a private offering may publish, published.
No economic terms are visible: no minimum ticket, no rate, no unit price. That is not a product limitation, it is the condition that holds the safe harbor up.
- /app/invitacion
Step 2 of 6
Redeems an invitation
A named invitation with counted seats. The platform tracks acquirers and invitees per project, because the RG 1088 caps are measured by headcount.
There is no open sign-up to the offering: without an invitation the terms are unreachable, and the system checks that in the database rather than on screen.
- /app/kyc
Step 3 of 6
Completes KYC
Identity, jurisdiction and investor status. The jurisdiction is checked against a policy sourced from official lists, and the outcome is versioned with the exact text that was accepted.
No identity document images and no raw IP addresses are stored. What remains is the outcome of the check, not the material it was made from.
- /app/oportunidades/sku-001
Step 4 of 6
Sees the full opportunity
Only with an invitation, approved KYC and an allowed jurisdiction do the financial profile, the cash flow, the disbursement schedule and the data room appear.
Access can lapse. If it does, the terms stop being visible, while what was already signed and the interest already expressed remain theirs.
- /app/oportunidades/sku-001
Step 5 of 6
Signs a manifestation of interest
A four-step wizard: amount, terms read to the end, a summary of what is signed and of the terms the series declares, and a signature by name. It produces a PDF with its hash, anchored and downloadable.
It is not a subscription or a payment commitment, and it moves no money. It is a manifestation of interest, and it can be withdrawn.
- /app/posicion
Step 6 of 6
Follows their position
A capital account with its ledger, a share of each distribution, and the transfer board where they can post a willingness to transfer.
The board is not a secondary market. The platform does not execute the transaction, moves no funds and guarantees no counterparty or price.
The developer
Loads the structure, certifies the work, records the spend and signs off. Everything loaded ends up public or auditable, which is the deal.
- /admin/emisiones/sku-001
Step 1 of 5
Defines the offering and its series
Vehicle structure (one or two), series with their term, seniority, preferred rate and conversion discount, and the tiers of the distribution waterfall.
They cannot declare a structure their series contradict: the database refuses one vehicle when the series sit across two.
- /admin/certificaciones
Step 2 of 5
Certifies construction progress
Each certificate with its period, physical progress, retention withheld and stockpiled materials, plus the supporting PDF. The hash is anchored on the test network.
Physical progress is not inferred from certified money. They are two different measures and the platform publishes them separately, because stockpiling moves money without moving work.
- /admin/gastos
Step 3 of 5
Records executed spend
Each payment with its receipt, payee and concept, measured against the budget by category.
Labour payments are published by amount and period, without names: an identified person's wage is their personal data, not project information.
- /admin/desembolsos
Step 4 of 5
Follows the disbursement schedule
Each tranche with its conditions and the evidence behind them, and their works-director sign-off where it is theirs to give.
The platform holds no funds and transfers none. Verifying that a condition was met is not releasing the tranche: whoever administers the funds decides, outside this platform.
- /transparencia/sku-001
Step 5 of 5
Sees what the public sees
Everything loaded feeds the project's public dashboard, with the same methodology and the same stated limitations.
There is no inside version and outside version of the progress figures: the difference between the two screens is the economic terms, not the facts.
The supplier
Confirms or disputes the payments that name them. This is the piece that turns the expense book into something a third party verified, rather than the developer's word about themselves.
- /admin/proveedor
Step 1 of 3
Opens their panel
They see only the expense lines where they are the payee, on the projects they are linked to.
They do not see the rest of the project's spend, nor the offering terms, nor the other suppliers.
- /admin/proveedor
Step 2 of 3
Confirms or disputes each payment
Confirms the payment happened as described, or disputes it with a note. They can attach their own receipt.
The developer cannot write that confirmation for them: the platform prevents it at the column level, not on screen.
- /transparencia/sku-001
Step 3 of 3
Their confirmation is published
The state of each line appears on the project's public dashboard, and disbursement conditions count only spend that was actually confirmed.
A dispute is not hidden. A dashboard where everything is confirmed would not explain what disputing is for.
The compliance officer
Reviews identities, runs the jurisdiction policy and reads the audit log. They work on what the system denies everyone else, not on what it asks of them.
- /admin/compliance
Step 1 of 4
Reviews the KYC queue
Each case with its outcome, its risk findings and its history. Approving or rejecting leaves a record with the reviewer and the moment.
They cannot approve themselves or operate without a second factor: the back office requires session step-up and the platform checks it on every request.
- /admin/compliance
Step 2 of 4
Raises and clears findings
Risk findings are recorded with severity and stay attached to the case until someone clears them with a reason.
Clearing a finding does not delete it. The record is append-only and the platform offers no way to edit it.
- /admin/jurisdicciones
Step 3 of 4
Runs the jurisdiction policy
Which countries are allowed and under what condition, with the source behind each decision.
The policy fails closed: a jurisdiction with no decision on file does not allow, rather than allowing by default.
- /admin/auditoria
Step 4 of 4
Reads the audit log
Who did what and when, including on-chain publications and role changes.
Nobody edits or deletes it, not even from the database: a trigger rejects updates and deletes, and the truncate privilege is revoked.
The outside verifier
An observer with read-only access to aggregates, and anyone at all with the ability to check what the platform publishes for themselves.
- /admin/veedor
Step 1 of 2
Sees aggregates without seeing people
Placement, progress, spend and compliance, with no access to investors' personal data or individual terms.
The observer role is not an administrator with fewer buttons: the database hands it aggregates, not rows per person.
- /transparencia/sku-001
Step 2 of 2
Checks the attestations independently
Every certificate and every telemetry period publishes its hash and the link to the transaction, so anyone can recompute it from the document.
The hash proves the document has not changed since it was anchored. It does not prove the measurement is correct, and the methodology says so in those words.
Every step also says what does not happen. On a platform that moves no money, custodies no private keys and promises no returns, what it does not do is half the explanation.