SaaS development in Luxembourg City — built for institutional buyers

#SaaS development in Luxembourg City: building a product that survives your customer's compliance review

Shipping subscription software from the Grand Duchy is not the same exercise as shipping it from Paris or Berlin with a different flag in the footer. Two facts shape every architecture decision here: a domestic market of roughly 680,000 residents, which makes a single-country product economically impossible, and a buyer base that is largely supervised, which means your technical file gets scrutinised as hard as your interface. At Nehos, a SaaS MVP starts at €13,952 excl. VAT and goes live in eight to twelve weeks; a complete platform starts at €50,000 excl. VAT.

The general method lives on our custom SaaS development page, and the mechanics of the subscription model are covered in our SaaS software guide. This page is about what changes in Luxembourg — and these are not differences of vocabulary. They are decisions taken in the first sprint that cost ten times more to reverse eighteen months later.

#Your second customer will not be Luxembourgish

English is the working language of the fund industry here, which fools a lot of founding teams into thinking the product is already international. It is not. Internationalisation is a property of your data model, not a translation file added before the first German demo.

Concretely: language must be a dimension of the content you store, not a layer bolted on at the end. Company identifiers differ by country — an RCS number, a VAT identifier, a national business register reference, and for fund clients an LEI. Address and date formats vary. Invoices must be issued in several currencies and under several VAT regimes. Contract templates and consent wording change by jurisdiction. A product designed monolingual and translated under pressure for a first Belgian or German prospect costs roughly three times what the same capability costs when planned from the start.

One detail almost everyone discovers too late: structured electronic invoicing. It is already mandatory for Luxembourg public contracts through the Peppol network and is progressively becoming the norm in neighbouring markets. If your SaaS issues invoices, or generates them on behalf of your customers, designing for a structured format costs a few days at the outset. Retrofitting it onto a data model that assumes a PDF costs weeks.

#Selling to a supervised entity makes you an ICT third-party provider

This is the point that genuinely separates a Luxembourg SaaS project from an equivalent one in Lyon or Rotterdam. The moment a management company, a private bank, a central administrator or a transfer agent uses your product, they have to fold you into their operational resilience framework under DORA: an entry in their register of information on ICT third-party service providers, a contract that is explicit about where processing happens, audit rights, the sub-contracting chain, and an exit strategy. Their IT outsourcing governance under CSSF Circular 22/806 is now read alongside DORA, and both point at the same evidence.

Your product therefore has to answer questions no end user will ever ask. Where is this specific tenant's data physically stored? How do you demonstrate — not assert — that it is isolated from other tenants? How is it exported in full, in a format another vendor can ingest? What is the degraded mode when a third-party component fails? How quickly does an incident notification reach the customer, given that their own regulatory clock has already started? Who are your own sub-processors, and since when?

There is also a Luxembourg-specific legal layer: professional secrecy under Article 41 of the amended law of 5 April 1993 governs how an institution's client data may be exposed to a third party. That is a question for your counsel and your customer's compliance function, not for your engineering vendor. Our job is to make sure the architecture keeps every option open.

Our conviction, formed on this market: none of this is a compliance cost. It is a sales accelerator. The vendor file — isolation architecture, processing locations, sub-processor list, service level commitment, incident notification procedure, reversibility plan, latest penetration test results — is built once, versioned, and sent within forty-eight hours. Against a competitor with a comparable product who needs six weeks to assemble the same pack, you win the account. So we treat that file as a product deliverable, shipped with the code and updated whenever the architecture moves.

#Multi-tenant isolation: the decision is made in front of your customer's CISO

Three strategies exist. The generic doctrine does not transfer cleanly to a market where the buyer's security review is the real gate.

Strategy	Operating cost	Evidence of isolation	Restore granularity	When we recommend it
Shared schema, tenant identifier	Lowest	Application-level, harder to demonstrate	All tenants at once	Products sold to SMEs, professionals, public bodies
Schema per tenant	Moderate	Demonstrable to a security reviewer	One tenant, without touching the others	Default choice once data belonging to a supervised entity's clients transits the platform
Database per tenant	Highest	Strongest, physically separable	Fully independent	A large account that accepts the operating overhead, or a hard data-location requirement

We say this plainly when a founder wants dedicated databases across the whole portfolio: it is the fastest way to triple the running cost of a product that does not yet have ten customers. Schema-per-tenant is our default for financial-sector buyers precisely because it converts a promise into a demonstration.

Whichever you pick, isolation must be tested automatically. An integration test that deliberately attempts to read another tenant's records, executed on every deployment, is worth more than a paragraph in an architecture document — and it is exactly what a serious security review will ask you to produce.

#Subscription billing when the customer is an institution

Card-on-file with automatic monthly charging works for a self-service product. It does not survive the first institutional contract. Buyers on this market work with annual commitments, purchase orders, bank transfers, invoicing split by legal entity — a fund group can represent forty distinct legal entities under a single commercial contract — and accounting calendars that react badly to automatic suspension.

So we systematically model the billing account as an object distinct from the technical tenant. One contract can cover several environments, one entity can be invoiced separately, a renewal can follow an anniversary date unrelated to the creation date. This decoupling looks theoretical while you have ten customers. It becomes the difference between a finance team that operates autonomously and a billing run reconstructed by hand every quarter.

Another specificity of products sold into the fund industry: the billing unit is rarely the seat. It is more often the fund, the sub-fund, the document processed, or a band of assets under administration. That demands metering that is reliable, auditable and reconcilable against the invoice line. Without it, every renewal turns into a negotiation over numbers nobody can substantiate.

#Putting AI in the product without derailing the compliance review

AI embedded in a SaaS sold to the financial centre obeys one rule: it must be verifiable. An answer that cannot be traced back to its source document is unusable by a compliance officer, however plausible it reads. We therefore design AI features with citation down to the source page or clause, logging of the model version and instructions used, human review on any committing action, a per-tenant switch, and a contractual commitment not to train on customer data.

On the regulatory side, you are the provider of the AI system and your customers are deployers — they will come to you for the documentation they themselves must produce. We deliver that notice with the feature, in a format their compliance team can reuse directly. Our AI agency in Luxembourg handles scoping and regulatory qualification of these use cases, while AI agents for the financial sector cover the automation of your customers' internal processes — adjacent topics, but distinct from AI sold inside your own product.

For a sense of the bar your buyer will have in mind, our sovereign AI copilot rolled out to 1,200 advisers at a mutual bank runs on a self-hosted retrieval architecture with full source traceability. That is the reference point a banking buyer applies when assessing the AI feature in your product.

#Taking over an existing SaaS rather than rewriting it

A good share of our Luxembourg engagements start the same way: a product launched a few years ago by a small team, working, with paying customers, that stalls on its first banking contract because the codebase cannot answer the contractual annexes.

Our audit covers tenant isolation, secret and access management, technical debt and test coverage, the deployment pipeline, GDPR posture, log completeness, and the consistency between what the code meters and what the contract sells. Three outcomes are possible, and we tell you which one we would pick: take over run and evolutions as-is, modernise module by module without service interruption, or rewrite only the critical component. A full rewrite is rarely justified — a SaaS in production carries years of undocumented business rules, and rediscovering them almost always costs more than working with what exists.

#What it costs when Luxembourg is the market

Two numbers set the boundaries of a normal build. An MVP — scoping, core domain, multi-tenancy, authentication, subscription billing, first production release, eight to twelve weeks — starts at €13,952 excl. VAT. A complete platform, with enterprise SSO, a documented public API, third-party integrations and advanced administration, starts at €50,000 excl. VAT.

Two more numbers exist specifically because your buyers sit under supervision. Building the DORA vendor file as a dedicated programme — register entry, contract clauses on processing locations and audit rights, exit strategy — runs from €15,000 excl. VAT rather than living as a checkbox inside the main build. For whoever already has a model embedded in the product, an AI Act compliance audit and remediation pass starts at €3,000 excl. VAT.

Once the product is live, running it — monitoring, security patches, version upgrades, small enhancements — starts at €750 excl. VAT a month.

Every figure above is a floor pulled straight from our published price list, not a marketing number; what your specific scope costs comes out of a free scoping conversation, within 24 hours. To sketch a budget before that call, the free interactive Nehos tools do the rough arithmetic without a sign-up.

#What working with Nehos actually looks like

Track record first, because it is the easiest thing to check: 47 engineers across software, AI, data and cloud, 200+ delivered projects since 2014, and an average measured ROI of 340% at twelve months — a number that holds because every scope starts from a quantified gain rather than a wishlist of features.

The handover is not a slide at the end of the contract. You get architecture documentation, the reasoning behind each technical decision, and an environment your own team can stand up without us in the room — because a vendor file that says "reversible" only means something if reversal has actually been rehearsed.

Pricing sits in the open for the same reason the vendor file does: a DSI who sees €13,952 for an MVP and €50,000 for a full platform on our price list knows within a minute whether the conversation is worth having, before anyone has spent a week on a discovery call that goes nowhere.

When a buyer's security review requires it — European hosting, data residency, an auditable chain of custody — the product ships on OVHcloud infrastructure, up to SecNumCloud. That is a decision made for your architecture when your market demands it, not a default we impose or a claim about our own premises.

On presence: correspondence and in-person meetings run through our Luxembourg address at 19 rue de l'Industrie; the engineering work itself happens in our studio, as one team without a sub-contracting chain, and a trip to sit with your users or your customer's security reviewer gets scoped into the engagement when it genuinely moves the project forward — not assumed as a standing arrangement.

Our group-level approach to SaaS vendors and scale-ups covers growth, activation and retention topics that sit outside this page; the Nehos Luxembourg City page covers everything else we do in the Grand Duchy.

The fastest way to see where you actually stand: pull up the last vendor due-diligence questionnaire a prospect sent you, and mark which answers your product can back up with a live demonstration rather than a line in a slide deck. Whatever is left unmarked is the real scope of the work — everything above is just context for that list.