Frequently asked questions

Both: a software house in Turin that designs and develops custom software, and a partner that supports companies in their technology choices.

We follow a digital product from design strategy to release and evolutionary maintenance, and we also do technical auditing and tutoring. We work on SaaS platforms, management systems, web and mobile applications and artificial intelligence systems built into business processes.

Partner is not a figure of speech: it means understanding goals and constraints before proposing anything, and telling you when a choice risks costing you dearly.

The company was founded in Turin in September 2022; the experience of its people goes back much further.

The founder has worked in software for more than twenty years, and every collaborator is a senior professional with at least ten years of practice. Volcanic Minds was born out of those years spent with large companies, startups and SMEs, and out of a recurring observation: companies were not short of suppliers, they were short of a technology partner they could count on.

We deliberately keep the age of the company and the experience of the people who work in it separate. It is the same reason why we state that we do not hold ISO certifications yet.

Industry, large companies and service companies, healthcare, banking and finance, digital evolution, green and mobility, advertising.

Our typical clients are SMEs, startups and industrial groups. The published case studies range from audits run with AI agents to digital healthcare, from mechanical workshops to telecare, from ESG supply chains to workforce planning.

It is our division dedicated to AI, because integrating agentic flows and processes is now a business and strategic choice before it is a technological one.

That is why it devotes time to continuous training, passed on to our partners, which is what we call the clients we build products with. It also works on AI maturity assessment in industrial, corporate and process settings, multi-agent architectures and governance under the EU AI Act, and it is the most recent step in our growth strategy.

Because transparency is better verified than declared.

The Playbook describes in English how we work: history and culture, project management, quotes and payments, how people grow and the limits we set ourselves. Anyone considering working with us can read what we commit to before signing, and hold us to it afterwards.

It is a living document: every section is reviewed at least once a year and carries the date of its last revision at the bottom. It is not a sales document, and where a practice is still imperfect it says so.

The Trust Center sits alongside it on commitments, gathering warranties, handover and exit conditions on a single page.

Five service lines, used together or on their own.

• Design Strategy: research, UX and UI and product definition, before a line of code is written.
• Digital Factory: end-to-end design and development, web and mobile, backend, cloud, DevOps and integrations.
• Project Leading: analysis, agile coaching, product ownership and technical guidance, for those who need the method more than the hands.
• AI Orchestration: workflows where AI agents carry out complex tasks, connected to real data and systems.
• AI Enablement: practical AI programs for technical teams and for decision makers.

Because custom software adapts to your processes, while standard software asks your processes to adapt.

It is worth it when the way you work is an advantage worth protecting, or when the standard product forces you into double data entry and side spreadsheets. A tyre shop manages seasonal storage, a bicycle workshop manages components and maintenance cycles: different flows ask for different software.

It is not always the right answer. Many processes need a well built form and a clean database, not a new system, and in that case we tell you so. You can also start from a single module.

With an introductory call, free and with no commitment.

You tell us about the project, we ask the questions we need to understand whether it is work we can do well. If it calls for skills we do not have we say so and, where we can, we point you to someone else. If the analysis shows that the request does not solve the problem, we say so before the quote, not after signing, let alone after delivery.

It depends on how defined the work is: fixed price if scope and timeline are clear, capacity if they are not yet.

A fixed-price project has scope, timeline and deliverables set in the quote, and it is the model for initiatives that already have a shape. With capacity you reserve team time in advance: it works for workload peaks or when the specifications are still moving, so availability does not become the bottleneck.

The one-month warranty after release applies to fixed-price projects.

Yes: we bring in the right suppliers from our network and manage the ones you have already chosen.

Over the years we have built a network of specialized companies and professionals, and coordinating them inside a single project reduces friction and delays. If part of the work is assigned to external collaborators you know before the start, and responsibility for the result stays with us.

You know the names and roles of the team before the start, and people are not rotated for our convenience.

The team is made of senior professionals, and continuity matters more than resource optimization: if someone has to change you hear it from us, in advance, with a handover. You have a single point of contact, and if something in the relationship is not working you can say it to them or to the person above them. An uncomfortable call in week three beats a polite one at the end.

In person when it matters, remote by choice for the operational work.

A relationship is not built through a screen alone: at the start we meet the people, shake hands and set goals and commitments together. The operational work then goes on remotely, with focused meetings around the key milestones and the ceremonies the project calls for. Organizing work in an agile way lets us collaborate with the best professionals, wherever they are, with lower costs and balance. Our office is in Turin, at Corso Vinzaglio 24.

Both: as a rule we design the whole ecosystem, but we also take on a single part.

The case studies contain all three cases: an end-to-end project, from analysis to the database and on to licenses and payments; a frontend built on the partner's wireframes while another supplier completed the backend; analysis, UX and dashboards on top of a solid backend the client already had.

Yes, and saying so up front protects the project more than any contract clause, as well as our reputation.

We do not take on work outside our domain, work that does not interest us or work we cannot do well. We do not accept deadlines we consider impossible: we propose a scope that fits the date or a date that holds the scope. We do not build before the problem has been validated, we do not sell AI where AI is not the answer and we do not create dependencies: no lock-in, no undocumented infrastructure, no code only we can read.

We keep checking these limits for the whole duration of the project, not only at the start.

Yes, even without a project, and it is run by the same people who design those systems and put them into production.

That is the reason to choose us over a training company: whoever explains a token cost or a human control has had to design one for real. No theory for its own sake: we leave that to others. If you are looking for certifications or training credits we point you to the two training bodies we work closely with. A program that concludes that AI is not worth it is a successful program.

Half a day for decision makers, several sessions spread over time for sales and technical teams.

Knowing how to code only matters in the technical programs; those on decisions and governance are designed for management, legal and compliance. The goals are set before the start, for example being able to assess a use case, read the cost of an operation or recognize when a human control is needed, so at the end you can check whether the program was worth it. The use cases are yours: real tasks your team deals with every day.

With an analysis of the real requirements, which produces a detailed quote: no off-the-cuff or convenience prices.

We could give you a figure on the spot, but it would be inflated or wrong, and it is not the right way to start getting to know each other. The quote always contains a cost range instead of a figure pretending to be certain, the payment terms with their milestones, the detail of what will be delivered and the recurring costs. The budget covers development, testing, release and handover.

With the quote in hand you decide whether to go ahead with the whole project or step by step.

An MVP starts at 15,000 €, an Enterprise platform at 50,000 €.

These are entry thresholds, not a price list: they are there to tell you straight away whether the project sits in your order of magnitude. A custom management system for a workshop, for example, starts at around 15,000 € in its essential versions and reaches higher figures in the more advanced systems.

The analysis measures what makes the figure move: the integrations with existing systems, the artificial intelligence components, the security and compliance requirements, the number of roles and flows. In the quote every item that raises the figure is justified, not added as a lump sum, and the exact value comes with its range.

It does not happen: if the initial requirements do not change, the price stops at the top of the range, already written into the contract, and we absorb the excess.

If instead the scope or the timeline changes, we tell you the impact on budget and deadlines immediately, before going ahead, together with a replanning proposal. Nothing is developed, and nothing is invoiced, without your approval.

Hosting, third-party licenses and AI model usage, all declared in the quote and kept visible while the system runs.

They are your costs, so it is only right to know them in advance: we spell them out straight away, so your total cost of ownership (TCO) is clear. An investment makes no sense if the cost of external services makes it unsustainable in everyday use: that is why we design those costs to be visible from the start. There is no license fee on the software we develop for you. Corrective and evolutionary maintenance, if you want it, is a separate contract with explicit SLAs.

By milestone: a deposit, payments tied to progress and a balance at the end of the work.

The structure is calibrated on the complexity of the project and on how clear the requirements are, and it is agreed before the start. For a typical project, lasting on average about four months:

• a deposit from 25%, for clients we have worked with for years, to 35%, for highly complex projects or ones with very evolving requirements;
• intermediate milestones tied to the phases, always with a milestone at the end of development, before quality control and testing;
• the balance invoiced a few days after the acceptance session, to leave you time to assess the release: no "sold as seen", because we deliver complex systems, not off-the-shelf products.

Every milestone you pay transfers to you the ownership of the part of the project it covers: what you pay for is yours straight away, well before the end of the work.

On fixed-price projects, one month of warranty for blocking bugs and minor work.

The distinction is clear cut: bugs are covered by the warranty, new features are quoted. Handover and acceptance sessions are already included and stated in the contract. Once the month is over, maintenance continues only if you want it, with a dedicated contract and SLAs, and with no obligation to keep choosing us.

Yes to both, right after the first introductory call.

We show you a sample contract, with wording that adapts to the justified needs of the project. For confidentiality we have our own bilateral NDA template; we are glad to review and sign the one from your legal department, as long as it is fair and does not create asymmetries between the parties.

Yes, with a professional indemnity policy and a cyber cover.

The cyber cover applies to damages and cyber attacks. We provide the policy details on request at contract stage: usually it is the purchasing department or legal who ask for them.

Sometimes yes, but it stays an exception: our work is building projects.

We consider taking a stake in ambitious projects, usually ones already growing or in maintenance, as an alternative form of funding for those looking for it. Every proposal is assessed on the alignment of goals, and we turn most of them down.

A typical project lasts about four months on average, but the real estimate comes out of the analysis.

Four months is a historical average, not a promise: timelines depend on the scope, and we do not hand out ready-made deadlines. Two examples from the case studies: an audit platform with AI agents completed in about four months, with a first working MVP between six and eight weeks; a workforce planning platform, which typically takes between three and six months with a dedicated team.

In any case you do not wait months in the dark: deliveries are incremental and you see working software all the way through, because your feedback and your vision of the product are what let us move fast.

By setting milestones that are realiztic rather than attractive, and telling you immediately if a date is at risk.

Dates come out of a rigorous analysis of scope, timing and the roles needed. We would rather lose a deal at estimate stage than miss a deadline invented to win it. If a delay becomes likely you hear it straight away, with a replanning proposal, not on the delivery date. And if a deadline looks impossible to us, we propose a smaller scope or a different date.

A change request is opened: we assess the impact together and you decide.

Change is part of every real project. For every new need we estimate the effect on timing and cost, and together you decide whether to bring it in straight away, reprioritize it or postpone it. If the change stays inside the agreed scope the cost does not change; if it goes beyond it, you know before deciding.

Nothing is developed, and nothing is invoiced, without your approval.

In Scrum, with regular meetings: your involvement throughout the project is a condition, not an optional extra.

The journey has four phases: goals, scope and timeline are defined; design and features are confirmed with prototypes and early feedback; development runs in increments; the solution is released and then evolves. Inside them, the Scrum ceremonies: sprint planning, short daily alignments, a review with a demonstration of the work done and a retrospective.

We meet you roughly once a week, to go over progress, issues and the needs of both sides. The goal is that you can always look at working software, not at a report.

With a testing phase run together before the release, and a final session that checks the whole system.

Quality control before the release involves both sides, with checks and reports: it is the phase that avoids surprises. At release we run a full pass over the whole system. The final invoice does not go out immediately: we leave a few days for your own assessment behind closed doors. During the following month, on fixed-price projects, we stay available for blocking problems and minor work.

Yes, and it is often the approach we recommend.

The part that hurts most is released first, and the priorities that follow are decided by real use instead of an assumption made at a desk. The quote is also designed for proceeding step by step, and the prototype phase serves to confirm design and features before investing in development. On the audit platform with AI agents, a first working MVP arrived between six and eight weeks.

With indicators agreed at the start, tied to business value and not to the fact that the software works.

The absence of bugs is a requirement, not a result. Before we start we define together the KPIs you want to reach: automated processes, fewer errors, working time recovered, performance, the ability to grow. Those are what tells you whether the technology spend has become an investment.

Yes: we design to WCAG 2.2 level AA, and up to level AAA when the project calls for it.

Contrast, full keyboard navigation, roles and states exposed to assistive technologies. Accessibility enters the requirements from the start, because added at the end it costs much more and returns less. And it does not only serve people with a disability: on a console used for a whole shift, an accessible interface makes everyone's work better. You can start assessing us on this site: the accessibility statement reports what it meets, what is missing and how we verified it.

Only if you ask for them or if the contract requires them.

Internally we work towards goals with deadlines, we trust people and we do not ask for timesheets. When we work with artificial intelligence tools, the hours those tools save us are not invoiced to you.

Yours, 100%, with no license fees and no vendor lock-in, in black and white in the contract.

Ownership passes milestone by milestone: every milestone you pay transfers to you the part of the project it covers. It is the premise of the contract, not a concession at the end of the work.

So that you are not tied to us we use standard, documented technologies, and we hand over accesses, repositories and API documentation in Swagger/OAS format.

Yes, third-party components, which stay under their own license.

Libraries and products under an open or closed license cannot be transferred by us, because they are not ours. We name them before you commit, and any recurring license costs appear in the quote.

Everything you need to maintain and evolve the software without us.

The repository with its whole history, the API documentation in Swagger/OAS format, the accesses to the services and systems, when you have not created them yourself from the start as we recommend, the process documentation, the DevOps infrastructure configuration, the backup restore procedures and training sessions for your team or for whoever takes their place.

If you keep working with us it has to be because you want to, not because you cannot do without us.

Nothing blocking: the code is already yours and the rest is designed to be picked up by someone else.

The software runs on widespread technologies that any competent team knows. The data sits in standard databases that can be exported without going through us and without closed formats. The business logic does not depend on a single AI model provider, so that part stays replaceable too.

Continuity is a consequence of the architecture, not a contractual promise.

Yes, on large-scale initiatives, with terms defined in the contract.

It makes sense where the investment and the operational impact make continuity a risk to be handled formally; the depositary and the release conditions are set case by case. Escrow, though, is mostly useful with suppliers who do not hand over the code: with us the source becomes yours milestone after milestone, so it covers a residual risk, not the main one.

We size them on the damage an outage would do to your company, and we agree them before going into production.

There is no standard value for RTO and RPO: it depends on what an hour of downtime or of lost data costs you. Along with the backups we hand over documented restore procedures and the methods to keep a copy on your own servers. A backup only the supplier can restore is not a backup, it is another dependency.

Only the people you authorize, with named accounts you can revoke at any time.

The accounts are created by the client: we do not create our own users on your environments, we ask to be authorized on the existing ones or to be added to your team. You can review or revoke our accesses without going through us and without the system stopping, for infrastructure, backups and DevOps pipelines. At the end of the project we ask for them to be revoked anyway.

The release is the beginning: if you want, we carry on with maintenance, explicit SLAs and training.

We offer corrective and evolutionary maintenance contracts with clear service levels on response times, plus quality control and support contracts tailored to the project. Bugs stay distinct from new features: the first are under warranty, the second are quoted. Training and handover are there to make your team self-sufficient in day-to-day use.

Based on the problem and on the business goals, never for fashion or for our own convenience.

Cloud native, microservices or a headless CMS are different answers to different questions: the right one is whatever will give you an advantage. We choose standard, widespread and documented technologies, because another team has to be able to take over without rewriting. Node.js, TypeScript, React, React Native, PostgreSQL and Docker containers recur in our recent projects, with mobile-first architectures ready to grow.

Yes, it is a central part of our work.

We connect to ERP, CRM, MES, MRP, APS and legacy systems through REST APIs, batch, WebSocket, MQTT, AMQP and other secure channels. We design API-first architectures, so external services or dated systems can join the ecosystem too. The accounting system stays where it is: data moves from one system to another with no double entry.

Yes, starting from what each piece of equipment exposes and without touching the hardware in the field.

We analyse the APIs, serial ports, files and services the manufacturer exposes, and we connect through REST APIs, WebSocket, MQTT, AMQP or batch. For proprietary protocols we write a dedicated adapter. In a telecare project, for example, new devices are added over Bluetooth with a wizard in the mobile app.

Usually no, at least not straight away.

We first build the part that is handled worst today and connect it through APIs to the tools you have. If replacing something turns out to be worth it, that is decided later, with usage data in hand. Even the external services we integrate are designed to be replaceable, not to be foundations.

Yes, with a decoupled approach: a new interface connected through APIs to the system you already have.

Many companies have solid backends and interfaces that slow the work down. Rebuilding only the frontend cuts the cost of a full rebuild, reduces the risk and extends the life of the software. The API contracts are agreed with whoever manages the backend, the work runs on simulated responses until the connection is ready, and everything is typed with TypeScript. We have done it, for example, for a field service dashboard and for a telecare one.

Yes: the web apps are responsive, and when needed we build cross-platform native apps.

We design mobile-first, which does not mean squeezing the desktop version onto a small screen: on a phone the information has a hierarchy of its own, thought out for the people using it there. When the use case calls for it we develop cross-platform native apps, for example in React Native, as in the digital healthcare platform.

Yes, if the architecture provides for it from the start, and that is how we design them.

Containerized SaaS platforms scale their resources with requests and users, and heavy operations go onto dedicated microservices. In multi-company architectures a new company is a configuration, not a rewrite; multi-tenant ones keep the workspaces and data of different clients separate. Costs and performance stay adjustable.

Wherever it needs to live: on the cloud chosen together or on your own infrastructure.

We are not tied to a single provider: we regularly work with OVH, AWS, Hetzner, DigitalOcean, Seeweb, Aruba and Azure, and often on the client's own infrastructure, with Kubernetes, containers or Debian and Ubuntu Linux machines. European cloud, national sovereign cloud, your own cloud account or on-premise: the choice is made at the start on regulatory, contractual and budget constraints, not on our convenience.

Depending on the context: credentials, corporate Single Sign-On, multi-factor authentication or one-time codes.

We integrate with the corporate identity provider for Single Sign-On, we enable multi-factor authentication, including with TOTP apps, and for people who log in rarely we use one-time OTP codes by email. On web apps the session tokens live in HttpOnly cookies and not in localStorage, so an XSS attack cannot read them.

With security designed in from the start: role-based access, least privilege and isolated services.

The usual measures are mandatory HTTPS, multi-factor authentication, role-based permissions with the principle of least privilege, isolation of services in containers and protection of personal data inside agentic systems too. The decisions that matter stay traceable. We do not hold a company ISO 27001 certification, and we say so.

When the requirements call for it, they are designed to lose nothing: a disconnection is visible, and the data realigns when the network comes back.

Losing the connection is a visible event, not silence. Events are queued and realigned on reconnection. Where the network is slow or drops packets, as in many workshops, we study the topology and design the calls and the data exchanged to hold up on it.

Yes: a TypeScript and Node.js suite we use in our own projects, plus some public experimental projects.

The suite includes a backend framework based on Fastify, tools for multi-factor authentication and for sending email and an administration panel; we also publish experiments on Mastra and on AI governance. The suite already handles multi-tenancy and provides embeddings and vector search (pgvector) for RAG. The fact that it is open source is what makes a framework of ours compatible with the commitment not to use proprietary technologies: the code is public and anyone can maintain it.

Both.

In new systems compliance is a non-functional requirement of the architecture, from the first line of code. For systems already running we start from a gap analysis against the obligations of Regulation (EU) 2024/1689, so we can plan only the necessary work, with no unnecessary rewrites.

No: the obligations have to be translated into controls inside the software.

A PDF or a dashboard license can flag a risk, but they do not stop an agent from breaching a policy or writing to a database without supervision. That is why you need controls engineered into the system. We work alongside legal advisers, not in their place: they interpret the obligations, we put them into practice.

No, not yet, and we do not claim certifications we do not have.

Volcanic Minds was founded in September 2022. We follow recognized practices and we rely on cloud providers that do hold those certifications, but that is a different thing and it has to be said. We are open to starting a certification path for the projects and clients that genuinely need one: if your purchasing process requires it, it is worth saying so on the first call.

Yes, because we build the control model on your own framework.

ISO 27001, NIS2, the EU AI Act or an internal risk management model, combined too. Every piece of evidence is tied to the control and the period it refers to at the moment it is produced, with a trace of who uploads it and who approves it, and recurring audits are planned. One distinction to keep in mind: we build compliance tools, we are not the ones who are certified.

Probably yes: the case studies deliberately cover very different industries and problems, to show how well we adapt.

We have published projects on audits with AI agents, corporate training and compliance, digital healthcare, field service, mechanical workshops, data for prediction markets, ESG supply chains, telecare and workforce planning. For some areas, such as alarm systems, risk management and workshops, there are dedicated pages too.

Yes, and it is exactly why you choose custom software.

Inside the same industry the flows change: a tyre shop manages seasonal tyre storage, a bicycle workshop manages components and maintenance cycles. Custom software follows those differences instead of flattening them.

Yes, even when there are particular tax rules or access models.

In a digital healthcare platform the backend recognizes the tax regime of each professional and is integrated with Stripe and Fatture in Cloud. In an ESG platform the clients pick and change plan on their own, paying by card or bank debit. In a Web3 context subscription access goes through Sign-In with Ethereum and time-limited NFTs.

Yes, built into the platform and without external tools.

For a digital healthcare platform we built video calls with real-time chat, transactional emails and reminders at the end of a consultation, together with a React Native app the professionals use to receive alerts, accept appointments and manage invoices and fees.

The domain expertise stays yours or your adviser's; making it automatic, repeatable and verifiable is our job.

In the ESG platform, for example, the procedures for calculating emissions under the GHG Protocol and ISO 14064 were provided by a partner who is an expert in the field: we turned them into software, tracking for every data point the moment, the unit it came from and its validation status. It is the same principle we work by on the EU AI Act alongside legal advisers.