Document Generator
A document platform with two halves: a template editor the bank maintains itself, and an API that turns the bank's own data into a finished document.
LiveFrontend => Vue 3, GrapesJS, TailwindCSS
Backend => NodeJS
- Sector
- Banking
- System
- Document generation
- Environment
- Regulated
The client
Salt Bank is a bank operating in Romania. The documents a bank produces for its customers are not marketing material: what the software generates has to be correct the first time, and has to still be explainable a year later.
The problem
The documents a bank sends its customers — statements, contracts, notices — are produced from templates that legal and compliance have to approve, and that change more often than anyone plans for.
When those templates live inside application code, every change is a developer ticket and a release. The people responsible for the wording are not the people who can edit it, and the gap between the two is where the delay sits.
Project overview
The platform has two halves.
A template editor, where the bank builds and maintains its own document layouts, with control over both the design and the variables that get filled in. And an API: it takes a request carrying the data for one document and returns the finished file.
It runs on serverless infrastructure with the services in containers, so capacity follows demand instead of being provisioned for the busiest day of the year. It connects to the systems the bank already runs, so the data behind a document is not entered a second time.
Constraints
The platform runs inside a regulated banking environment. That shapes the software rather than sitting beside it: who may see which data, what gets recorded each time a document is produced, and the requirement that the same input still produces the same document later.
Execution
-
01
Separating layout from data
We went through the documents the bank produces and drew the line between what is layout and what is data. That split is what decides whether a template can later be maintained without a developer, so it was settled before anything was built.
-
02
The template editor
A visual editor where a document is built once and the variable parts are marked as placeholders. The people who own the wording change it themselves, and a change does not wait for a release.
-
03
The generation API
One endpoint: it receives the data for a single document and returns the finished file. How the document looks comes entirely from the template, so the system calling the API never has to know anything about layout.
-
04
Into the bank's environment
Deployed on serverless infrastructure with the services in containers, connected to the systems the bank already runs, and handed over with the documentation needed to operate it.
Project results
- [figure]
- Time to publish a template change
- [figure]
- Document types live on the platform
- [figure]
- Documents generated since launch
DRAFT - replace with the real figure, or delete this metric, before the page goes public.
DRAFT - replace or delete.
DRAFT - replace or delete.
The bank's own people maintain the document templates. A change to wording or layout is made in the editor and applies to the next document generated, instead of waiting for a release.
On the other side, a document is produced from data the bank already holds. Nothing is re-entered anywhere to make one.
Team & timeline
The engineers who scoped the platform are the ones who built it and took it into production. There was no account management layer between the bank and the people writing the code.
[DE COMPLETAT: câți oameni, ce roluri, în câte faze și pe ce perioadă.]
Gallery
Our collaboration with MVP Solution was outstanding. They built a custom solution from scratch tailored to our neo banking needs, showing professionalism and flexibility throughout. Their input was valuable at every step, and the platform now scales to millions of requests per minute. Communication was smooth, and deadlines were always met.
