Why Kreyo has no UI
Every time someone asks us "don't you have a dashboard?", the answer is the same: no, deliberately. This post is that answer, written down.
The question we keep getting
Every demo call eventually hits the same moment: "So where's the dashboard? How do my clients manage their invoices?" And when we explain that there isn't one (Kreyo is an API you embed in software you already own), there's a brief pause while the caller recalibrates.
Sometimes they recalibrate to "this isn't for me." That's fine. Sometimes they recalibrate to "oh, that's exactly what I need." That's the ICP.
The question comes from a mental model: SaaS fiscal compliance tools have portals. You log in, you see invoices, you click send. It's a reasonable model for a certain kind of customer. It's not the model Kreyo is built on.
Two fundamentally different products
There are two ways to build a fiscal compliance tool:
- Vertically integrated SaaS. One product that does everything: stores invoices, shows them in a portal, lets end users manage them, handles compliance in the background. The software vendor and the user interact directly. Works well for individual businesses and small teams that don't have their own software.
- Horizontal API component. A layer that other software embeds. The API handles one thing (compliance, generation, extraction), and the calling software owns everything else: the UI, the data model, the user workflow. The software vendor is the customer; end users never interact with the API directly.
Kreyo is the second type. Every design decision follows from that.
What an ERP already has
The software builders who integrate Kreyo already have:
- Their own invoice management UI
- Their own client database
- Their own authentication and authorization
- Their own reporting and audit trail
The one thing they don't have is a compliant VeriFactu submission layer, or a FacturaE signing component, or a PDF generation engine that handles layout correctly. That's the gap Kreyo fills. Adding a Kreyo portal next to their portal wouldn't fill a gap; it would create a new one: now their users have two places to look for the same information.
The right shape for a component that embeds in existing software is an API with clear inputs, clear outputs, and a guarantee that it stays out of the way otherwise.
Who is outside Kreyo's ICP
To be direct: if you're an individual freelancer without existing accounting software, or a small business looking for a web interface where you type invoices and click submit — Kreyo is not the right tool for you. There are products built specifically for that use case.
Kreyo is for the companies who build those products. Or for developers inside enterprises who already have internal systems and need to add compliance without rebuilding everything.
The consequence: docs and SDKs are the product face
If there's no portal, the thing users experience is the API, the documentation, and the SDK. That's what has to be good.
This is why we publish the OpenAPI spec as the single source of truth, generate docs directly from it so
they can't drift, and maintain SDKs for the languages our customers actually use. It's why the NIF validator
is open source: if we're asking you to trust our compliance logic, you should be able to read it. It's why
every error response has a request_id you can use to debug without opening a support ticket.
Your UI is your product. Our API is our product. When they connect cleanly, neither of us has to compromise.