FAQ

Take a look at the "About" page to get to know me better: today COalesCE is a single person, with years of hands-on experience across Italian companies of every size. You can also check out my interactive Curriculum Vitae.

It depends on the problem, and I'll start with the part nobody tells you: very often the best answer is not AI. Every automation costs something to build and something more insidious to maintain over time: in a good share of cases it never pays for itself, and installing it anyway moves the problem rather than solving it.

What I look at is your margin, not how much technology I can sell you. For each problem I work out what the best solution actually is: sometimes an AI agent, far more often a process to rewrite, two systems to make talk to each other, or a report that needs to land on Monday morning instead of a month later.

That is exactly what the assessment is for: putting the cost, risk and feasibility of every possible route on the table, including the route of doing nothing, so you choose with the numbers in front of you. If the conclusion is that you need none of what I do, I will tell you.

Four questions, and they apply to me as much as to anyone else. Do they stay until production, or hand over a document and disappear? Do they write the code, or pass it to a team you didn't choose? Are they vendor-independent, or do they have a license to place? And above all: have they ever told you that you don't need something?

That last one is what actually separates them. Anyone proposing the same solution whatever the problem isn't consulting, they're selling. The practical test is to ask, at the first meeting, what they would do in your place if the budget were half: the answer tells you everything.

If you need a brochure site, a web agency is a fine choice and cheaper than me. Calling me makes sense when the software has to talk to the systems you already run, your ERP, warehouse or accounting, and when the hard part is not the design but the integration.

The first thing I do is assess feasibility and tell you whether it's worth building at all, rather than selling you a standard package. And technical SEO and citability on AI engines are handled from the first commit, because going back over them later means touching URL structure, content and markup on a site that's already indexed: it can be done, but it costs more than doing it upfront, and you don't win back all the ground you lost.

On a complex project the bottleneck is almost never the number of people: it's how many of them know the context. I write the code and work alongside the people writing it in house, and when the work needs a specialist skill I don't have, I bring one in: I choose them and I answer for them. Whoever joins, the person who knows every detail of the project doesn't change.

There is one exception to that "almost never": if the project needs several teams working different fronts at once, I am not the answer, and I say so before we start rather than halfway through. On the projects I do take, what I commit to is a documented system, in a state where someone else can pick it up, with the access in your hands.

Yes, I work with companies across the whole country and abroad as well: with video calls and the cloud there is no need to be in the same room to write code together. When it matters, though, I come in person, because some things you only understand by watching how the people who will use the system actually work.

I've worked with companies in very different sectors: manufacturing, retail, finance, energy and public administration. That versatility pays off most when one sector finally catches up on a practice that's long been routine in another: retail, for instance, can apply forecasting logic born in manufacturing to its own inventory.

I write the code myself, or work alongside the people who write it in house. I don't sell hours from people you've never met: if it needs to scale I bring in collaborators I pick myself and answer for personally, and from analysis to production you always talk to me.

It depends on what you need, and there are cases where the company is the right call: if you need round-the-clock cover, out-of-hours availability, or the certainty that someone can take my place from one day to the next, a company gives you that and I don't. When that's your case I say so, and I don't try to talk you out of it.

With me you get something different: one person who knows your system end to end and who answers you directly. No account manager relaying messages to whoever does the work, no junior billed as a senior, no internal handover that loses half the context. On a project that has to go into production inside processes that are already running, that counts for more than headcount.

On references I'm straightforward: I don't publish client logos or testimonials, because many projects are covered by confidentiality agreements and because a logo doesn't prove anything about the actual work. If you need a reference I can put you in touch with a previous client privately. In the meantime, judge me from a free first call: if after that I'm the one who thinks it isn't worth continuing, I'll be the first to say so.

When you need senior technical decisions but not a full-time executive, which in an SME is almost always the case. The costliest decision is the one nobody makes: I work as a part-time CTO/CDO/CIO for the moments that matter (platform choice, vendor contracts, architecture review), with the same hands-on Forward Deployed Engineer approach, just at a different pace.

Because most attacks do not pick a victim, they look for an open door. SMEs get hit because they are often the weakest link in a larger client's supply chain, and because ransomware that halts your production for a week does not need to be sophisticated.

I assess the real risk: which systems would stop, how long it would take to restart, and what is worth fixing first. If you want to dig in, the glossary covers ransomware.

In most cases no, and when the answer is yes I tell you before we start, not after. The honest goal is to free up time from manual, repetitive work: sometimes that reduces the people a process needs, far more often it moves the people already there onto work that actually creates value, analysis, client relationships, decisions.

Every agent ships with human oversight, explicit limits on what it may do alone, and a record of what it did. A system that decides with nobody able to check it isn't automation, it's risk accumulating.

A governance project done properly does not disrupt your processes. I don't sell governance as a project of its own: I build it into the cloud data platform work, with a non-invasive approach. Every company already has a "shadow" governance, people who de facto guarantee data quality and reliability: the work makes it explicit, with clear roles on who touches what and measurable quality rules, built on your existing processes instead of overturning them.

The hard part isn't the technology: it's the cultural change. That's why I always pair it with training and involvement of the people, from management to whoever uses the data every day.

In most cases cloud, for one reason: almost no SME has someone in-house who gets up at two in the morning to bring a server back online. I work on GCP, AWS and Azure, where costs are visible line by line, backups can actually be tested, and permissions are written once.

If you already run your own servers, they work and someone looks after them, or you have regulatory constraints that keep certain data inside your own walls, I won't push you to migrate on principle: you move what is worth moving, and the rest stays where it is.

Almost always yes, and almost always without replacing either of them. But what it costs and how long it takes comes down to one thing, and it isn't how good I am: how open the systems you already run are. If both have a documented interface, as several Italian ERPs do, it is days of work. If one of them is closed, or its documentation doesn't really exist, the road is longer and I tell you upfront.

And it often takes less than you'd think: it depends on how quickly you need the data to be current, and in many cases a continuous connection isn't necessary.

It depends on what happens if the connection fails one day and nobody notices. If the answer is "not much", Zapier or Make are a fine choice: they cost tens of euros a month, you can set them up without me, and it would be dishonest of me to charge you for code that replaces them. That is the case for moving a contact from a form into the CRM, or sending a notification.

A custom integration earns its keep when the volume pushes the per-run bill above what writing it would cost, when the data belongs to customers or employees and has to stay inside a perimeter you control, or when the connection has to do work those services cannot: reconciling, handling failures without losing anything, resuming from where it stopped. The real difference is not the monthly price, it is who owns the logic when the vendor changes its pricing.

Yes, and it is almost always the first thing worth fixing, because double entry doesn't only cost time: every time a person retypes something, the two systems drift apart, and from then on nobody knows which of the two is right.

One honest warning, because it is the mistake I see most: if the two archives already hold the same customer spelled two different ways, connecting them without cleaning up first multiplies the problem instead of solving it. Deduplication comes before the connection, and how big a job it is depends on how many years of data are in there.

Almost never, and anyone offering that as the first answer is selling you their own product. Replacing it is the most expensive and riskiest answer to "I'd like to see the numbers in one place": it stops the office for weeks and starts you over on software your team doesn't know.

In most cases the ERP stays where it is and gets read from the outside: the numbers you need land in one place, next to the ones coming from the other systems. How easy that is depends on how yours is built, and it is the first thing I check: if your case is one of the ones where it isn't worth it, you know straight away.

Absolutely not. As a vendor-independent and technology agnostic professional, I won't tell you to rip out what already works. I'll tell you honestly whether a new tool earns its place next to it.

I look at what you already run and tell you what is worth keeping. If something new is needed, it has to pay for itself: if it doesn't, I say so before you buy it.

Yes, and it is one of the things I do most. You were right to use an AI tool: in a week you had something to show, and you would not have got there on your own. The missing jump is everything between something that works on your screen and something twenty people can work on at once without it falling over.

I look at how it is built, tell you what is worth keeping and what is better rewritten, and take it to production documented. The details, with the list of what I hand over and what drives the cost, are on the Software Rescue page.

Yes, that's exactly why the Legacy System Migration service exists. I run an honest assessment of the existing code: if it's salvageable I put it back in order without throwing away what works; if starting over a piece is the better call, I'll tell you clearly upfront, not halfway through the work.

If both programs have a supported way to exchange data, a connection is days of work and lands less than the roughly €5,000 a full engagement starts from. If one of them has no such route, or if the duplicates have to be cleaned up first, it moves into weeks and the price follows.

You don't have to guess which of the two your case is: half a day looking at both programs settles it, and that check is part of the assessment, which starts at €750 and leaves you a quote with the real number. If it turns out a setting you can change yourself is enough, I'll tell you and show you where.

I use three formulas depending on the project: a fixed fee for an assessment with a defined scope, a fixed monthly retainer for a Fractional CTO/CDO, and a variable share tied to a measurable outcome (e.g. reduced cloud spend, query response time) for optimization work.

In every case the rate is tied to the actual value I bring, not to the number of services I can sell you: I earn if I make you earn, and if the project stalls I lose money too, so I have every reason to stay until it actually ships.

The numbers, so you don't have to ask: an assessment starts at €750 and ends with a document that is yours, whether you carry on with me or not; an engagement starts at around €5,000 and rises with how many systems it has to touch; a Fractional CTO is a fixed monthly retainer, sized on the days you actually need.

Both, and there is in fact a third. But the shape is not chosen up front. On a project basis when the scope is clear and there is an end to it: it starts, it reaches production, and I close on a result you can verify. As an ongoing engagement when the problem is not a project but the fact that nobody in the company decides on technology: that is the Fractional CTO/CDO/CIO, on a monthly retainer. The third is training, when you don't want to buy the work but to put it in your own people's hands.

The starting point is the same for all three: a free first call of 30 minutes, and if the problem deserves a serious look, an assessment that ends with a document rather than a promise. The shape is decided there, once it is clear what is actually inside the systems: deciding earlier means picking a contract blind.

In practice they blend. After a project-based engagement a light ongoing presence often stays on, for maintenance and for the decisions that come afterwards. Responsibility does not close on release day, and that is where you see it.

Not by the total, but by what is written around it. A serious quote states what is in scope and what is not, breaks the work into milestones with one verifiable result each, spells out how it integrates with the systems you already run, and says who owns the code at the end.

The two lines almost always missing: maintenance after release, which is a recurring cost and not a detail, and what happens if the requirements change halfway. If a quote is silent on both, the price you read is not the price you will pay.

Click "Contact me" and fill in a short form. I get back to you within 24 working hours and we set up a free first call, where we work out whether your case is something for me and what tackling it would take. If you would rather form your own view before talking to anyone, you can request access to the AI Readiness Assessment: I send you the 24 questions by email, again within 24 working hours.

Yes, and I am the one recommending it. A pilot project costs little, lasts a short time, and shows you how I work without tying you to a big commitment decided before you have seen anything.

The engagements that have been running for years nearly all started that way: one small, precise problem, solved first. And if even a pilot feels early, you can request access to the AI Readiness Assessment and stop there: what comes out of it is yours to keep, whether or not we end up working together.

Yes, but not by default: it depends on where you send the data. The point almost nobody checks is that many AI services run on servers outside Europe, and pushing customer or employee data into them is a processing activity like any other, with a legal basis, a privacy notice and retention periods to put in writing.

Before connecting anything I look at three things: which data leaves, where it ends up, and whether the vendor uses it to train its models. When the data is sensitive, the way to go is keeping the model inside the European perimeter, or not letting the real data through at all. That is privacy by design applied to AI: decided up front, not after the first incident.

The same goes for shadow AI: in most companies someone is already pasting confidential documents into a free chatbot, and that is the concrete risk, not the AI you have not bought yet.

I do, but not as a generic subscription: I agree with you on what to monitor (pipelines that break, cloud costs that creep up, data that loses quality over time) and a direct line to me so things get fixed when it matters, not a ticket sitting in a queue.

If a project doesn't need active maintenance, I'll tell you, and I won't sell you a contract you don't need.

The assessment takes a few days and ends with a document that is yours. From there, a typical engagement runs from a few weeks to six months, depending on how many systems it has to touch. We set the intermediate milestones together, so you can see progress without having to ask.

That's my problem, not yours. A solution that isn't adopted isn't a success, no matter how elegant the architecture: that's why the production phase includes time to fix, train and adapt, not just to hand over and disappear.