Business systems, internal tools and client areas are the same thing seen from two sides: same data, same states, same documents. Building them separately means keeping them in step by hand forever — and the hand doing it is yours.
system --status --job 2041
quote ............. approved 12/03, signed with OTP
deposit ........... received, receipt issued
files ............. 14 documents, last one yesterday 17:42
[ok] the client sees the same status without calling you
system --tickets --open
1 open · average response time 4h
waiting
$ ./portal --archive --all
Email, certified mail, WhatsApp, the bank, Drive, the phone. Today a client's work sits in six places and you are the glue. A client portal is where that work reassembles itself.
// when you need it
There is no particular day it starts, but the signs are always the same. Recognise three of them and the time you lose bridging the gaps has already cost more than closing them.
// what we build
The inside face makes the team work; the outside face makes the client do the work for you. Underneath sits the same data — and that is what removes the reconciliation.
Jobs, records, states, permissions. Built on the process you actually have, not the one an off-the-shelf package assumes — because the process is what brings the money in, not the software.
The same progress, filtered to what the client is allowed to see. They stop calling to ask where things stand, and you stop working as a switchboard.
Documents signed from the portal with a one-time code and a record of who signed, when and from where. Deposits and balances tracked, with the status updating itself when the money lands.
Accounting, stock, mail, calendar. The new system talks to the old ones in both directions, instead of becoming one more place to update by hand.
// how we get there
This is where the method shows: the development quote comes after the prototype, not before. A number given without having seen the process is a bet.
We list where every piece travels today: the system, email, certified mail, WhatsApp, the bank, shared folders. It is the exercise that surprises people most, because there are always more channels than anyone remembered.
Who sees what, and more importantly who does NOT. A portal where the client can see your margins or your supplier costs is a problem, not a feature.
The real screens, clickable, tested with the people who will use them — your team and your clients — before any final code exists. This is where the missing step turns up, while changing it costs an afternoon.
We switch on the part that eats the most time first, almost always signatures and payments, and add the rest afterwards. Nobody should wait a year to stop digging through email.
$ cat stack.json
$ ./domande --frequenti
The variables that matter are how many screens are needed, how many integrations to outside systems, how many distinct roles, and whether the client-facing side is included. We give a number after the prototype, when the scope is visible: a quote given before that is a bet dressed up as an estimate.
A first usable module in 6 to 10 weeks. From there it grows release by release, instead of waiting a year to switch everything on at once and discover at the end what does not add up.
Almost always, and it is often the right call: the portal becomes the face the client sees and your existing system stays the source of the data. It needs to expose an API, or at least some way to read and write; we check that during discovery before promising it.
It qualifies as an advanced electronic signature when the process is built properly: identification, one-time code, and an unalterable record of what was signed and when. For deeds that require a qualified signature — notarial ones — you need a different route, and we tell you that beforehand, not after.
We do, under an agreement written before we start. The right to use the software is yours and does not expire; ownership of the source code stays with us, and can be bought separately if you want to be free to have anyone maintain it. Servers, accounts and data are in your name either way.
That happens when the portal asks more effort than the channel it replaces. Which is why we start from the two moments where the client has a strong reason to log in — signing and paying — and add the rest once the habit exists.
fymera init --project "yours"
Thirty minutes on video to map your process and the channels you use. If the spreadsheet is still enough for you, we will say so.
