Custom internal software and system integration for SMEs

Yes, and it is the work I do most often. The starting point is always the same: I look at how you work now, and work out whether your process is genuinely unusual or whether it resembles something a product already covers. If an off-the-shelf product suits you, I say so and I don't sell you a project. If the part that sets you apart is also the part nobody handles, the software gets built around the process you have: application, archive, users and permissions, with the code and the infrastructure in your name.

It depends on how standard your process is, not on how big the company is. If what you do is done the same way by everyone else, a product costs less and you can buy it tomorrow. If the way you work is the reason customers choose you, a product forces you to bend it, and customisations on top of the product become the line that gets out of hand. The real financial difference is not the initial price: it is a subscription that grows with users on one side, and spend concentrated at the start on the other. That judgement is the first output of the analysis, before any quotation.

I have no price list, and I would be wary of anyone who has one for bespoke work. Four things set the price: how many systems are touched, whether they expose decent APIs or have to be reached another way, how many entities are synchronised and in which direction, and whether users also need an interface. After the analysis you get a fixed figure for the project, not an open hourly rate. If the analysis shows the spend makes no sense against what the manual work costs you today, I tell you and we stop there.

As an indicative estimate, not a commitment: an integration between two systems with usable APIs usually takes three to eight weeks from analysis to the first flow in production; a B2B portal, six to twelve. The variable that moves dates most is not the code: it is how long it takes for access, credentials and answers to arrive from your ERP vendor. The real dates are set at the end of the analysis, when we know what is actually inside the systems.

Analysis, architecture and code review I do myself and do not delegate: that is where it is decided whether the project holds up. For development, when the volume calls for it, I rely on a small network of people I have worked with for years — but every line that reaches production passes through my review, and the person you deal with is still me. There is no account manager in between.

I work on Central European Time, which overlaps with the whole of Europe and the UK for a full day and with the east coast of the United States for the afternoon. Work is remote by default: repository, ticket tool and calls on whatever you already use, in English. For the analysis phase I travel where it is worth it, because watching people work is worth more than ten calls — but it is a few days, not a permanent presence, and travel costs are agreed in advance rather than appearing on an invoice.

The infrastructure is in your name from day one, so the data stays with you: I am a processor working on your systems, not a place where your data is kept. Hosting can be pinned to an EU region — or to another region if your own rules require it — and that decision is written into the architecture document together with what is logged, for how long and who can read it. Where personal data is involved, the flows are designed to carry the minimum needed, which is both a GDPR requirement and the simplest way to keep the system small.

I am an Italian sole trader invoicing in euros, and the project is a fixed price against a written scope rather than an open hourly rate. I am happy to work under your contract and your NDA; I don't have a template I need you to accept. VAT treatment depends on where your business is registered, and I confirm it before the first invoice rather than after it.

That is exactly why an integration is built in layers. The logic of your processes lives in the middleware, not inside the ERP: when you change system you rewrite the connector to the new one, not everything else. That point is explicit in the architecture document, so you know in advance what a change would cost and what it would not.

Almost always yes. APIs are the best route, not the only one: you can work on the database, on scheduled file exports and imports, on feeds dropped on SFTP or into a mailbox. The quality of the integration changes — with files you lose real time — and I tell you that during the analysis, before quoting, not after.

The source code, the technical documentation, the credentials to every service and piece of infrastructure, and the architecture document. All in your name. No encrypted components, no usage licence that forces you to stay, no service that stops working if you stop working with me. If one day you hand the system to another supplier, they have everything they need to work on it.