e-Invoicing and the tax portal
Sending invoices into the national system and reading back their status, with certificate-based authentication and rejection handling — the part usually discovered at the first refused invoice.
Integrations with the systems you depend on — and the running afterwards
Most applications do not die because the code is bad, but because nobody maintains them any more. The supplier moved on, the certificate expired, the tax authority changed the format, and the person who knew the password no longer works there.
We do that part too: the connections to outside systems — tax authority, invoicing, payments, authentication — and then the day-to-day running, including for applications we did not write.
- e-Factura ANAF
- SPV
- Keycloak / SSO
- SmartBill · FGO · Oblio
- Stripe
- Terraform
01
What we cover
Integrations we have already built and keep in production, not a theoretical list.
Invoicing and accounting
The link to the invoicing provider the company already uses, so the invoice leaves the application instead of being retyped into another program in the evening.
Payments and subscriptions
Card payments, recurring subscriptions, retries on failed charges and subscription status visible inside the app. Through Stripe or a local processor.
Central authentication
One account across the organisation’s applications, with role-based permissions and the option to link existing accounts from Active Directory or another provider.
Taking over an existing application
We read the code and the infrastructure, write down what we found and propose a plan: what gets fixed first, what gets rewritten, what stays. Without promising rewrites that are not needed.
Monitoring and operations
Alerts when something breaks, backups verified by restoring them, security updates and someone who answers when the system stops.
02
What you get
Integrations that get fixed, not reinvented
When a partner changes the format, one isolated piece changes, not half the application. That is why we keep them separate from business logic.
Infrastructure described in code
Servers, DNS and certificates are written in Terraform, not clicked together in a console. They can be rebuilt identically, and history shows who changed what.
Backups that have been tried
A backup counts only if someone has restored from it at least once. We verify the restore, not just the existence of the file.
Handover without hostage-taking
If you want to leave, you leave: the accounts are yours, the infrastructure is described, and the operations documentation is handed over with the credentials.
03
How a takeover starts
First we learn the system, only then do we touch it.
- 01
Inventory and access
We list it all: where it runs, who has access, which certificates expire, which backups exist. The first surprises usually show up here.
- 02
A period where it just runs
We take over operations with no changes: monitoring, alerts, incident response. We learn the system while it runs, not from documentation.
- 03
A repair plan
Only then do we propose what changes, in what order and at what risk. In stages, not "we rewrite everything".
Questions about this service
Will you take over an application built by someone else?
Yes, it is one of the most frequent requests. We start with an inventory of access and infrastructure, then a period in which the system simply runs under our hands. We do not promise a rewrite before we understand why it was built that way.
What does monthly operation cost?
It depends on how many systems there are and how fast we must respond to incidents. It is set as a subscription with the response time written into the contract — not hourly, because nobody wants to think about the invoice while the system is down.
What happens if the tax-authority integration breaks?
Formats and authentication requirements change periodically. Our integrations keep what was sent and what came back, so processing resumes exactly where it stopped, and the format part changes in isolation without touching the rest of the application.
Do you work with our infrastructure or yours?
Either. If you already have servers or a hosting provider, we stay there and describe in code what exists. If not, we build the infrastructure ourselves, also described in code, in your provider account — not ours.
Who has access to our data?
Strictly the people working on the system, with named accounts rather than a shared password. Access is revoked when someone leaves, and what was accessed stays in the log.
Contact
Have an application nobody maintains any more?
Tell us what runs and where. We will look and tell you honestly whether it is worth fixing or replacing.
Office: Barajul Dunării 3, District 3, Bucharest