The Situation
"We need a dashboard" is only the beginning.
Imagine you need a KPI dashboard. You do not want a software theory lecture. You want a useful application that shows important business indicators clearly, reliably, and in a way people can actually use.
For example, the dashboard should show cash position over time, incoming orders, closed orders, order execution time, bill-to-cash time, and the ten biggest customers and their revenue over time. The data should come from an existing MS SQL Server database.
That sounds simple at first. But the difficult questions start immediately. Which cash position? From which accounts? Which date counts as order date? What does closed mean? What happens with cancelled orders? Who may see customer revenue?
A dashboard is not just a screen. It is a shared definition of the business.
What Portae Does
Make the work visible before code appears.
Portae is the organized work surface of Siloquy.com. It helps people turn a business idea into requirements, specifications, architecture, review comments, tasks, implementation work, tests, and change requests.
The work is done with the help of named AI Officers, but the human keeps control. You do not need to know how to write software requirements or design a server architecture. Portae gives the Officers a place to do that work visibly.
The point is not that AI secretly builds something while nobody understands it. The point is the opposite: the work becomes reviewable and traceable step by step.
Interviews
First learn what people actually need.
For a KPI dashboard, the first step may be talking to management, sales, finance, order processing, controlling, IT, database administrators, and the people who prepare current Excel reports.
An Officer can analyze those conversations and extract facts, wishes, open questions, contradictions, and decisions. It can notice when two groups use the same word differently.
Many projects fail because people think they agree. Often they only use the same words.
Specification
Turn meeting notes into a clear description.
After the interviews, an Officer can create a specification. A good specification explains what the dashboard is for, who will use it, why each indicator matters, what each indicator means, which decisions are open, and which ideas are out of scope.
For the KPI dashboard, the specification might cover user groups, data sources, indicators, time periods, filters, access rights, visual layout, open questions, and out-of-scope ideas.
If people do not agree what cash position or closed order means, the dashboard will only make the disagreement prettier.
Requirements
Vague wishes become reviewable Cards.
Portae can turn the specification into User Requirements and System Requirements. User Requirements say what people need in business language. System Requirements connect those needs to the technical software.
Examples are simple and practical:
- The dashboard shall show the company's cash position over a selectable time range.
- The dashboard shall show incoming orders based on the date an order was booked.
- The dashboard shall define exactly what closed order means.
- The dashboard shall calculate bill-to-cash time from invoice date to payment received.
- The dashboard shall show top customers by a clearly selected revenue definition.
Each card can carry open questions. Which accounts are included? Should cancelled orders be excluded? How should partial payments be handled? Should customer groups be combined?
Architecture And Review
Decide the cornerstones before implementation.
An Officer can prepare the technical choices in plain language. Should this be a web application or desktop application? Should it run inside the company network? Is direct database access allowed, or must the dashboard use an API? Who can see revenue data? Should the dashboard export PDF or Excel?
After requirements and cornerstones are clear, an Officer can propose architecture: frontend, backend, database access, API endpoints, security, deployment, and testing. Other Officers and humans can review it before coding starts.
Portae slows down the right part: thinking, definition, and review. Then it lets the fast part be fast.
Mockups And Backlog
The project stays understandable when it becomes technical.
Once the plan is good enough, Officers can create mockups: dashboard overview, cash chart, incoming and closed orders chart, execution-time trend, bill-to-cash trend, top customers, filters, and drill-down screens.
Then the work can become a backlog. The backlog might include project skeleton, mock data, charts, calculations, backend API, MS SQL Server connection, access control, export views, tests, and a test deployment.
Many non-programmers lose visibility at this point. Portae is meant to prevent that. The user can see what is planned, what is done, what is blocked, and which Officer is responsible.
Implementation
Keep control without managing every keystroke.
Good software work includes things that are invisible to non-programmers: keeping code in git, committing meaningful steps, separating mock data from real database access, testing calculations, preserving working versions, recording decisions, reviewing code, and deploying first to a test environment.
Portae lets Officers do that work while connecting implementation back to requirement cards. The human does not need to become a programmer. The human needs visibility and control.
AI can code quickly. Portae helps make sure it codes the right thing.
What The User Gets
More than a dashboard.
At the end, the user gets a working application, but also a readable specification, clear user requirements, system requirements, architecture, review comments, decisions, mockups, backlog items, implementation history, tests, and change history.
For a small dashboard, that may sound like a lot. But even small applications become painful when definitions are unclear. For larger applications, this structure is the difference between a controlled project and a pile of unfinished wishes.