Buying & running custom software

Buying custom software is one of the least transparent expenses a company faces. You don’t see what you’re buying until you have it, quotes vary by a factor of ten for “the same job”, and the moment you sign is also the moment you know the least. The result is that a lot of people get hurt: budgets burned on the wrong prototype, no-code that stalls at 80%, “finished” projects that die in six months, vendors who disappear with the code on their laptop. This guide collects the articles that give you the metre: what you’re really buying, when it’s worth building and when it’s worth buying ready-made, how not to get burned, and what it takes for the software to stay alive after launch.

The principle: the value sits in the 20% the ready-made doesn’t do

The thread that ties every article in this guide is a single idea, repeated from many angles: ready-made and no-code take you to 80%, and the real value is in the 20% they don’t do. That last 20% is your specific logic — your way of working, your rules, your joints — and it’s exactly the part that decides whether the tool changes the company or ends up in a drawer. Buying well means understanding which of the two cases you’re in: if you’re in the standard 80%, a ready-made SaaS is the smart choice and saying so is part of the job; if your value sits in that 20%, then custom is worth the money it costs.

The other idea that runs through everything is honesty about the hidden cost: not the one written on the quote, but the cost of buying badly — inertia measured in euros, the project rebuilt twice, the vendor prison. Every article lines up these numbers, because the right question isn’t “how much does it cost?”, it’s “how much does buying badly cost me?”.

Deciding whether and what to build

Before spending a euro, the game is played on the perimeter:

• «I have an app idea and I’m about to sign» — the 8 questions to answer before burning the budget on the wrong prototype: what to do before building an app.
• «I want an MVP, but a real one» — what you can actually do in 90 days, and what happens after launch: the 90-day MVP that isn’t a slide.
• «No-code has stalled on me» — when and how to call whoever builds, after ready-made has taken you to 80%: the limits of no-code in a company.
• «What’s inside a quote?» — the buyer’s guide to reading the line items, ownership, maintenance, and understanding why it isn’t “a 3,000-euro website”: what a custom build includes.

The cost of inertia: why move (and why sometimes not)

Sometimes the real problem is standing still:

• «How much does NOT having the app cost me?» — the estimate in hours, errors and lost clients that makes an invisible haemorrhage visible: the cost of not digitizing processes.
• «I spent tens of thousands on an AI PoC that ended in a drawer» — why prototypes die and how not to repeat it: the failed AI proof of concept.
• «My gestionale is a 2008 Access» — when rewriting legacy pays and when it doesn’t: rewriting legacy ERP software.

The operational problems that push you to custom

Often the need is born from a concrete daily pain:

• «Sales keep the pipeline in their heads» — having ONE number instead of three different versions of the same reality: the single sales pipeline.
• «Leads arrive and die in 48 hours» — you’re missing the dashboard that makes them get worked, not “more traffic”: leads that don’t get worked.

The relationship with the vendor and the after-launch

Buying well isn’t only choosing today: it’s staying free tomorrow:

• «The “finished” project dies in six months» — maintenance, who has the keys, and how not to stay hostage to a vendor who disappears: maintenance after go-live.
• «I have to answer a 40-page RFI» — how to separate the requirement from the theatre and not sign a suicide (from the seller’s side): answering a software RFI.
• «Sales promised a feature that doesn’t exist» — how to close the gap between sales and product before it costs you a client: the promised feature that isn’t there.
• «I sell hours and I’ve hit the ceiling» — from consulting to product, for whoever builds and not only for whoever buys: from consulting to product.

Why one pair of hands beats three vendors

There’s a structural reason custom projects go badly, and it comes back in almost every article: they get split across different vendors — one does the data, one the backend, one the frontend, one “the AI” — who, when something doesn’t add up, blame each other. You, in the middle, pay in months and nerves for the lack of direction. The biggest cost of software is almost never the build: it’s the stitching between pieces designed separately. One pair of hands that holds data, backend, frontend and — where needed — AI together isn’t cheaper on the single piece, but it removes the largest hidden cost, the one of the whole that doesn’t fit.

The other technical thread is the honest role of AI: it assists, prepares, finds, proposes — it doesn’t decide the things that matter in place of a person, and it isn’t reliable where a mistake costs. Distrust whoever sells you magic; the value sits in the solid product around the AI, not in the promise.

How to use this guide

Start from the article that describes your pain — you don’t need to read them in order. Each one includes the cost of inertia in euros, what you actually get, the honest timeline, the “it’s for you if / it isn’t for you if” section, and the honesty about when ready-made is enough — because buying well, sometimes, means not building at all.

When you want to think through your case with someone who starts from the questions and not from the quote — and who knows both sides of the table, the buyer and the builder — the starting point is the project portfolio or two lines in contacts.

Below you’ll find all the articles in this guide.