The team building Quido

Behind Quido are people from finance and from technology, with one clear idea: repetitive work gets automated, judgement does not.

In the photograph are Francesco Calia, Lorenzo Bergadano, Ilaria Bolla, Gianluca Maiorino, Emilio Crespi, Mattia Cossa and Andrea Losavio. It is not the full team: Julian Pichler, Founder Associate, was away that day, along with others who were unavailable. The group is also growing: the photograph captures a moment, not the boundary of the company.

Who is here, and what they do

Francesco Calia, CEO, leads strategy, product and customers. Lorenzo Bergadano, CTO, is responsible for the platform's technology and architecture. They are Quido's two founders.

Ilaria Bolla, Lead Data Scientist, leads the AI models and the data quality behind the analyses.

Gianluca Maiorino, Founder Engineer, builds the analysis engine, from raw data to report.

Emilio Crespi, Founder Engineer, builds the platform's data pipelines and integrations.

Mattia Cossa, Customer Success Engineer, supports clients from onboarding to daily operations.

Andrea Losavio, Frontend Developer, owns the platform's interface and user experience.

Julian Pichler, Founder Associate, supports the CEO and the team on operations and business development. He was not present on the day of the photograph.

The idea that holds the group together

The company's stated mission is to free analysts and partners from repetitive work, and to put time back where it creates value: the investment thesis, the relationship around the deal, the decision.

Put like that it reads as a line from a website. In practice it is an operating criterion, and it applies every time a decision is made about what to build.

Work in private capital divides into two categories. The first is collection and normalisation: finding the company, retrieving filed accounts, reclassifying them, reconstructing ownership, lining up the news, laying it all out in a readable document. That work is necessary, it demands care, and it contains no judgement. The second is interpretation: working out whether the margin holds, whether the comparison with peers stands up, whether the corporate structure hides a complication, whether it is worth proceeding.

Every capability in the platform is measured against that distinction. If it absorbs work from the first category, it is worth building. If it tries to replace the second, it does not get built — not out of caution, but because it would be a product no serious professional would use for work that carries their own signature.

How the work is divided, from raw data to report

The roles listed above look generic until they are put in order. Put in order, they describe a path: the one a piece of information travels from being a filed document to being a line in a report somebody discusses in a meeting.

At the start are the data pipelines and integrations. It is the least visible part and the most decisive: bringing the material in, keeping it current, connecting it to the tools clients already use. If this part is fragile, everything downstream inherits the fragility, and no amount of elegant interface compensates for it.

Then comes the analysis engine, which turns raw data into reports. It is where line items get mapped onto a common scheme, comparison becomes possible, and the material takes the shape in which it will actually be used.

Alongside sit the models and data quality. They are two faces of the same problem, which is why they live in a single role: a model applied to dirty data produces a convincing error, which is the worst category of error. Data quality is not a checking stage at the end; it is a constraint that precedes the model.

Then comes the interface. A correct analysis that takes six clicks and a search on the page to find does not, in practice, exist. Work on user experience, in a professional product, is not cosmetic: it decides how many times a day the tool gets opened.

At the end is customer success. It is the role that closes the loop: it accompanies the client from onboarding to daily operations and brings back into the company what does not work in real use. It is also why setup, training and support are included in the fee rather than billed separately: if adoption is an additional cost, whoever bought the tool stops extending it.

Above all of this sit the founders' two responsibilities — strategy, product and customers on one side, technology and architecture on the other — which exist to keep that path coherent end to end. That coherence does not maintain itself: each link in the chain, left alone, tends to optimise its own piece, and the sum of five local optimisations is not a coherent product.

Finance and technology in the same room

The team's composition is not accidental, and it is probably the factor that shapes the product most.

A purely technical group, however good, builds what is elegant to build. In a vertical product elegance is not the criterion: the criterion is whether something removes half an hour a day from a person who currently spends it retyping numbers. Recognising that half hour requires knowing the profession from the inside.

A purely domain group, at the opposite end, tends to ask for the digitisation of the existing process: the same work as before, with a few screens in between. It is the most reliable way to build software nobody uses, because it changes the cost of nothing.

The value sits in the friction between the two perspectives. It is productive friction and it should be maintained rather than resolved: the moment one side stops objecting, the product starts to resemble the people who build it instead of the people who use it.

What "Founder Engineer" means

The title recurs in the team and is worth explaining, because outside this environment it does not say much.

It does not indicate an equity stake or seniority. It indicates a way of working: the person does not receive a specification to implement, they receive a problem to solve, and defining what should be built is part of their job.

It makes sense in a specific context — a small group working on a complex domain, where the distance between whoever decides and whoever builds would be the main bottleneck. It makes far less sense in a large organisation, where the same autonomy would produce divergence.

The flip side is that it requires people to understand the client's profession, not only the technology. An engineer who does not know why reclassifying a set of accounts matters will make reasonable, wrong decisions.

The road so far

In February Quido closed a €1.6 million funding round, led by Vertis Sgr with the participation of Cdp Venture Capital Sgr through the Frontech programme, SevenData, Edrom and a pool of business angels and partners active in strategic consulting and Italian private equity. The transaction is covered in the article on the funding round.

A round serves many purposes, and the most immediate is this: it allows you to build the group the product requires rather than the group you can afford. In a vertical that is a substantial difference, because the competences needed — financial domain, data engineering, models, product — are not concentrated in a handful of people and cannot be bought one at a time.

What the platform the team builds actually does

To place the roles described above, it helps to recall what the team builds.

Quido automates financial analysis for private equity, investment banking and advisory. Concretely:

• Multi-criteria search across millions of Italian companies by sector, size, geography and financial signals, with filters and results ranked by relevance.
• Company profile with reclassified accounts, KPIs, peer comparison, news and corporate structure, generated automatically and kept up to date.
• AI agent reasoning over the platform's data and returning sector analysis, target shortlists or summary memos, with sources.
• Shared deal flow, with custom stages, filters, ownership and follow-ups.
• Automated reports — one-pagers, reclassified accounts and memos — in the firm's format.

The data comes from Italian public sources — the Chamber of Commerce and filed accounts — and from proprietary data kept up to date in real time, with every item traceable to its source.

Three constraints the team has set itself

Some decisions are not renegotiated feature by feature, and they explain much of how the product is shaped.

Traceability comes before summarisation. Every item must be attributable to the source it came from. This is not a compliance choice: it is the condition under which the material produced can enter a document discussed in an investment committee. A figure that cannot be traced to a source is not an acceptable approximation — it is unusable material, and it forces somebody to redo the check by hand.

Output is born in the format in which it will be used. A tool producing excellent analysis which then has to be retyped into the firm's template moves the work instead of removing it. It is why reports come out already in the firm's format rather than in a proprietary format to be converted.

Client data does not feed the models. The infrastructure is European, data is encrypted at rest and in transit, processing is GDPR compliant, and client material is not used to train models. It is the first subject questions arrive on from people working on confidential transactions, and it deserves to be a firm answer rather than a setting.

How a client observation becomes a change

The path described above runs in the direction of the data. There is a second one, running the other way, and in a vertical product it matters just as much.

It starts from something noticed in use: a step that takes three clicks too many, a comparison that is missing, a report somebody exports and then tidies by hand before sending. These signals are small and uneven, and they almost never arrive phrased as requests: they arrive as asides in the middle of something else.

The role closest to that flow is customer success, because it is the person who sees the tool in the hands of people actually using it, in daily operations rather than in a trial session. From there the observation has to reach whoever can act: the interface if the problem is one of navigation, the analysis engine if the problem is in the report's content, the pipelines if the problem sits upstream, in the data.

The delicate part is translation. A client describes the symptom, not the cause — "I have to fix this report every time" may mean an item is missing, the order is wrong, the format does not match their firm's standard, or the document is being used for something other than what it was designed for. Those are four different problems with four different solutions, and getting the translation wrong produces a change that fixes nothing.

It is also the practical reason for keeping the chain short: that translation is done by people who talk to each other, not by three handovers of documents — and it is the first thing to defend as the group expands.

Data quality is a role, not a final check

This point is worth returning to, because it is the most counter-intuitive for anyone looking at the product from outside.

Instinct suggests data quality is a verification: build the pipeline, compute the analysis, and at the end somebody checks the numbers add up. In a product working on the filed accounts of thousands of companies that approach does not hold, for a simple reason: the errors that matter are not the obvious ones.

A missing figure is visible. An absurd figure is visible. What is not visible is the plausible, wrong figure: a line item mapped onto the common scheme reasonably but incorrectly for that particular type of company, a formal sector classification that does not match the real activity, an ownership chain reconstructed well for 95% of cases and badly for a less common corporate configuration.

None of these errors trips an alarm. They produce an analysis that looks right, and they are discovered — if they are discovered — by a professional who knows that company and notices something is off. That is the worst possible moment to find them, because the damage is not the wrong number: it is trust in the tool.

From which it follows that data quality has to sit at the start of the path rather than at the end, inside the role that governs the models rather than beside it. And it is why traceability is not only a guarantee for the client: it is also the mechanism by which, internally, a suspect figure is traced back to its source instead of being corrected by hand.

What this work asks of people

This is not a list of requirements for applying — that is not what this article is for. It is an observation of what the work demands, drawn from how it is structured.

Understanding the client's profession. It holds for every role, including those furthest from the client. Someone building a data pipeline who does not know why reclassifying a set of accounts matters will make reasonable, wrong decisions, and will make them at a point in the path where nobody will review them.

Tolerating unglamorous work. The part of the product that generates the most value for the client is also the least visible: normalising, reconciling, keeping current. It is slow work, hard to talk about and impossible to skip.

Accepting that judgement stays outside. There is a recurring temptation, in anyone building analytical tools, to take one more step and suggest the conclusion. That is exactly the step that makes the product unusable for a professional who has to sign off on that conclusion. Stopping one step earlier is a discipline, not a technical limit.

A growing group, and what has to be protected while it grows

The team is expanding. That follows naturally from what the product requires: the competences needed — financial domain, data engineering, models, product, client relationships — do not fit into a handful of people.

The interesting question is therefore not how large the group becomes, but what risks being lost along the way. Because a small group has real advantages, and almost all of them are fragile.

The first is that everyone knows what everyone else is doing, and nobody needs permission to talk to a client. The distance between an observation picked up during an onboarding and a change to the product is measured in days, not quarters. That advantage is not lost all at once: it erodes one handover at a time, almost always for sensible reasons.

The second is the overlap between roles. The boundaries described above are less rigid than the list suggests — whoever builds the pipelines understands the analysis engine, whoever owns the interface knows what happens upstream. In a small group that overlap arises on its own, simply because there are not enough people to specialise completely. Later on it has to be cultivated deliberately.

Growing is necessary, and necessary soon. But it is worth being explicit about what is being protected while it happens: the closeness between the people using the tool and the people building it, which is why the product resembles the profession rather than itself.

Who is not in the photograph

The team is larger than what is visible here, and it continues to grow. The photograph is missing Julian Pichler, Founder Associate, and the other people who were unavailable that day: it is right to say so rather than let the image speak for the whole company.

The full, current list, with names and roles, is published on the About page. That is the source to check for who is at Quido today: that page changes when the team changes, an article does not.

What this article is not

A few boundaries, as always.

It is not a hiring announcement, nor a list of open roles.

It is not a product announcement: the capabilities mentioned are those already available to client organisations.

It is not an org chart: the roles described say how the work is divided, not a formal reporting structure.

It is not a definitive picture of the team: for the current composition the About page applies, not this text.

Frequently asked questions

Who founded Quido?

Francesco Calia and Lorenzo Bergadano. Francesco Calia is CEO and leads strategy, product and customers; Lorenzo Bergadano is CTO and is responsible for the platform's technology and architecture.

Who are the people in the photograph?

Francesco Calia, Lorenzo Bergadano, Ilaria Bolla, Gianluca Maiorino, Emilio Crespi, Mattia Cossa and Andrea Losavio. It is not the full team: Julian Pichler, Founder Associate, was away that day, along with others who were unavailable.

Is the team growing?

Yes. The group is expanding across every competence the product requires. This article does not list open roles: for who is at Quido today, the current source is the About page.

Where can the current team list be found?

On the About page, which lists the names, roles and responsibilities of everyone working at Quido.

What does "Founder Engineer" mean?

It is a way of working rather than a title: the person receives a problem to solve instead of a specification to implement, and defining what to build is part of their job.

What does Quido do?

It automates financial analysis for private equity, investment banking and advisory: company research, analysis, reporting and up-to-date data in a single platform, with every item traceable to its source.

Where does the data come from?

From Italian public sources — the Chamber of Commerce and filed accounts — and from proprietary data kept up to date in real time, with every item traceable to its source.

Is client data used to train models?

No. The infrastructure is European, data is encrypted at rest and in transit, processing is GDPR compliant, and client data does not feed model training.

How long does a new client take to get started?

A team is typically productive in under a week. Setup, training and support are included in the fee, and it is the part customer success looks after.

Does Quido integrate with the tools a firm already uses?

Yes: CRMs, deal flow systems and the Office suite, with export to PDF, Word and Excel and a REST API for custom integrations. It is the part of the product that lives in the pipelines and integrations.

Who can access the platform?

Access is restricted to client organisations. Anyone wishing to evaluate it can request a demo from the site.

In summary

The group building Quido brings finance and technology together around a division of work that follows the path of the data: pipelines and integrations, analysis engine, models and data quality, interface, customer success — with the founders' two responsibilities keeping that path coherent.

The criterion behind the choices is always the same: automate the repetitive work and leave judgement untouched, because that is where the profession of the people using the platform continues to exist.

The current list of people is on the About page. Background on the company and its investors is in the article on the €1.6 million funding round, and questions on sources, security, pricing and integrations are answered on the FAQ page.