NIS2 Compliance Outsourcing

Skip key takeaways

Updated September 8, 2026

• NIS2 contains no outsourcing prohibition at all Recital 83 states that the risk-management and reporting obligations apply regardless of whether an entity maintains its network and information systems internally or outsources their maintenance, so there is no NIS2 equivalent of a custody carve-out and no function the directive reserves to in-house delivery.
• Article 20 splits into a hard duty and a soft one Members of management bodies are required to follow training, while for employees Member States are only required to encourage entities to offer similar training, so a purchased training platform answers the second half and the members of those bodies still have to answer the first.
• The build or buy table is our reading, not a published rule No source assigns any Article 21(2) measure to a delivery model, so the buy column structures the directive's silence, while the column of things that stay inside is anchored to text naming management bodies, reporting lines and documentation duties.
• Appointing a provider opens a measure rather than closing one The provider becomes a direct supplier under Article 21(2)(d) and triggers the Article 21(3) diligence duty, and both provisions stop at direct suppliers, with deeper tiers left as something recital 85 says entities could consider rather than must.
• An authority can demand the evidence under the audit, not the certificate Article 32(2)(g) covers requests for the results of security audits by a qualified auditor and the respective underlying evidence, the audited entity pays for an independent-body audit, and an enforcement order can require audit recommendations to be implemented within a reasonable deadline.

Copy takeaways

NIS2 compliance outsourcing is not one decision. It is ten, one per measure heading in Article 21(2). The directive says nothing about who performs a measure and much about who answers for it, so the ten answers differ. This guide assumes the scope question is closed. If it is not, the entity tests sit in NIS2 compliance software requirements and the filing step in NIS2 entity registration. What follows is for the entity that already knows it is essential or important and now has to decide what to buy.

In short: nothing in NIS2 forbids outsourcing any measure. Recital 83 says the obligations apply whether systems are run internally or their maintenance is outsourced, so buying changes who does the work and not what is owed. Article 20 is the counterweight: Member States must ensure that management bodies approve the Article 21 measures, oversee implementation and can be held liable for infringements. Buying also creates fresh work, since the provider becomes a direct supplier or service provider under Article 21(2)(d), which pulls in the Article 21(3) duty to take that supplier's vulnerabilities and practices into account. For the entity types the implementing regulation binds, that becomes selection, contracting and monitoring in a documented form. And a supervisory authority asks the entity.

What outsourcing does not move

Start with the sentence that settles the frame. Recital 83 of Directive (EU) 2022/2555 states that "The cybersecurity risk-management measures and reporting obligations laid down in this Directive should apply to the relevant essential and important entities regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof." That is as close as the directive comes to a position on the question, and it comes in a recital rather than an operative article, so it carries interpretive weight rather than a rule. There is no prohibition on outsourcing a named function and no approval step before a contract is signed, so anyone importing that pattern from another EU regime is importing something NIS2 does not contain.

One structural point, stated once. Article 21 is not addressed to your company in the directive's own voice. It binds Member States, and Article 21(1) reads "shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services". Your operative duty comes from the national law transposing it, so this article describes the Union floor rather than any country's requirement.

ENISA reads the same consequence out of Recital 83, in a footnote of its technical implementation guidance, and states it as its own interpretation rather than as a rule: "The entity remains fully accountable for the integrity, availability and confidentiality of services provided by suppliers. SLAs must be clearly defined, actively managed and aligned with the entity’s business continuity, security and compliance obligations." A service level agreement is a management artifact rather than a transfer of responsibility, and from the day you buy, your evidence file includes somebody else's work, which is harder to keep current than your own.

The two articles that split the work

Article 21 lists measures. Article 20 names the people who answer for them, which is why the decision is bounded rather than free. Under Article 20(1) Member States must ensure that the management bodies of essential and important entities "approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements" by the entity of that article. A second subparagraph carves out public institutions, along with public servants and elected or appointed officials, leaving those to national liability rules. For everyone else the directive does not define what the liability is, so personal exposure is a national question either way.

Article 20(2) is the provision most often flattened, and its two halves carry different force. For the people at the top it is a requirement, because Member States must ensure that "the members of the management bodies of essential and important entities are required to follow training". For everyone else it is an encouragement. The same sentence says only that Member States "shall encourage essential and important entities to offer similar training to their employees on a regular basis". A training platform delivers the second half at scale. The first half attaches to the members of the management bodies themselves, and its evidence is an attendance record. NCSC Ireland describes the same shift as "increasing responsibility for boards and management bodies of organisations;"

Turn to the measures themselves. Article 21 then sets the standard for the measures. They must be appropriate and proportionate, and proportionality is assessed against real variables, so that "due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity". The ten headings are a floor rather than a checklist. The chapeau of Article 21(2) says that "The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following". Buying something against each of the ten meets the minimum enumerated set, it does not finish the job.

What you can buy, by category

The market sells four broad things against Article 21. The mapping is ours rather than the directive's, which assigns no measure to a delivery model. Naming categories rather than products is deliberate: the category decides what evidence lands in your file. Managed detection and response covers monitoring, triage and, in fuller offers, containment, which maps to incident handling at Article 21(2)(b). What it does not cover is the notification, addressed to the entity, or the classification judgment that starts the clock, and the overlap between that clock and the ones in adjacent regimes is a separate problem we took apart in the CRA, NIS2 and DORA reporting overlap. A virtual or shared security operations center is the same function at smaller scale, with thinner evidence behind it. Governance, risk and compliance tooling is bought against points (a) and (f): it holds the register and generates the report, but for the entity types the implementing regulation binds it cannot perform the acceptance the Annex assigns to the management bodies, or to the persons accountable for the risk. External audit is where buying is closest to unavoidable: a team assessing its own effectiveness is a weak artifact.

Two definitions matter when you contract for any of these. Article 6 of the directive defines a "‘managed service provider’ means an entity that provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems", and the definition does not stop there: it goes on to require that the service be delivered via assistance or active administration, on the customer's premises or remotely. The same article defines a "‘managed security service provider’ means a managed service provider that carries out or provides assistance for activities relating to cybersecurity risk management;" Both sit in the Article 21(5) list of types the Commission was told to regulate, so the vendor you are appointing may be a regulated entity itself. Recital 86 is sharper. These providers integrate closely with customers and have themselves been attacked, so "Essential and important entities should therefore exercise increased diligence in selecting a managed security service provider."

That opens a boundary case worth naming. Article 1(2)(b) of the directive covers "cybersecurity risk-management measures and reporting obligations for entities of a type referred to in Annex I or II as well as for entities identified as critical entities under Directive (EU) 2022/2557", and Annex I lists managed service providers and managed security service providers under its ICT service management sector. Subject to the directive's size rules, the provider you appoint can be an essential or important entity in its own right, with its own Article 21 measures, its own reporting duty and its own supervisor. That cuts two ways for a buyer. Its compliance is not yours, and nothing in these sources lets one entity's status answer for another's, so a provider's own audit report is evidence about the provider. But a provider inside the regime is one whose own supervisor can reach the material you may need, which makes its status a selection criterion under the Annex rather than a substitute for your file.

Ireland, as one national example

National implementation is where the answer actually lives. The National Cyber Security Centre Ireland noted, when its page was last updated on 24 June 2025, that "Unfortunately, the transposition deadline for NIS2 of 17 October 2024 has not been met." It also records a precedence rule that matters to any financial reader: "For financial market infrastructures, the Digital Operational Resilience Act (DORA) will take priority;" DORA handles ICT third-party arrangements on a different footing from this one, and we took its architecture apart in DORA compliance software architecture.

Build, buy or outsource, measure by measure

The table below is our editorial reading. No source assigns any Article 21(2) measure to a delivery model, and the directive speaks only to the entity's duty that a measure be taken, so the middle column structures an absence rather than a published rule. The right-hand column is different in kind: every entry is anchored to text naming the management bodies, the entity itself or a documentation duty.

Article 21(2) measure	What the market sells against it	What stays with the entity, and where that comes from
(a) risk analysis and security policies	GRC tooling, policy drafting support	Management bodies accept residual risk, approve the policy on a recorded date and review it annually (Annex points 1.1 and 2.1.1)
(b) incident handling	Managed detection and response, virtual SOC	The Article 23 notification is made by the entity, and an order to fix reporting is addressed to it (Article 32(4)(d))
(c) business continuity and crisis management	Backup and recovery services	Residual risk acceptance and the reporting of review results sit with management (Annex points 2.1.1 and 2.3.3)
(d) supply chain security	Third-party risk tooling, supplier assessment	The entity communicates its own role in the supply chain and sets the selection criteria and contract terms (Annex point 5.1). Buying anything creates work here
(e) acquisition, development and maintenance security	Penetration testing, vulnerability management	Outsourced development falls back under the supply chain and acquisition rules (Annex point 6.2.3)
(f) assessing effectiveness	External audit, independent review	Review results go to the management bodies, and corrective action or risk acceptance follows (Annex point 2.3.3)
(g) cyber hygiene and training	Training platforms, awareness programs	Article 20(2) training is owed by the members of the management bodies, and awareness reaches direct suppliers too (Annex point 8.1)
(h) cryptography and encryption	Key management services, managed PKI	Responsibilities and authorities for the policy are assigned by the entity and communicated to management (Annex point 1.2.1), and the policy itself is approved and reviewed by the management bodies (Annex point 1.1)
(i) HR security, access control and asset management	Identity and access management, background screening	The entity assigns roles and authorities, and one person reports directly to management on security (Annex points 1.2.1 and 1.2.3)
(j) authentication and secured communications	Authentication and communication products	Policy ownership, as above

The Annex references come from Commission Implementing Regulation (EU) 2024/2690, which binds only the entity types named in its own Article 1 and is an illustration for everyone else. Three of its sentences are ones a purchase cannot satisfy. Risk acceptance: "Risk assessment results and residual risks shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies." Reporting lines: "At least one person shall report directly to the management bodies on matters of network and information system security." And the review cycle: "The network and information system security policy shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur." Those describe acts rather than deliverables.

Three criteria decide the middle column in our own practice, and they are our editorial reading rather than anything the sources publish. One is entity size, which the directive itself makes relevant through the proportionality test in Article 21(1). Another is whether you can staff continuous coverage: a measure that only works around the clock, incident handling above all, is where a small internal team produces thinner evidence than a bought service. Last, and hardest to argue with, is who has to be the author of the artifact. Where the Annex names the management bodies or the entity as the actor, buying adds a supplier and does not remove the act, so those rows stay inside whatever the first two criteria say.

The supply chain duty outsourcing creates

This is the part buyers miss. Appointing a provider does not close a measure, it opens one. The provider becomes a direct supplier under Article 21(2)(d), which reads "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;" The diligence follows in Article 21(3), which requires that "when considering which measures referred to in paragraph 2, point (d), of this Article are appropriate, entities take into account the vulnerabilities specific to each direct supplier and service provider", together with the overall quality of their products and their secure development procedures.

Note the perimeter: both provisions stop at direct suppliers and service providers. Recital 85 encourages entities "Essential and important entities should in particular be encouraged to incorporate cybersecurity risk-management measures into contractual arrangements with their direct suppliers and service providers.", and about the tiers beyond that it says only "Those entities could consider risks stemming from other levels of suppliers and service providers." Fourth-party risk is therefore something a careful program may choose to do, not a duty these sources impose.

For the entity types in the implementing regulation's Article 1 the duty is spelled out. The implementing regulation "lays down the technical and the methodological requirements of the measures referred to in Article 21(2) of Directive (EU) 2022/2555" for what it calls the relevant entities, and its Annex point 5 turns Article 21(2)(d) into a policy, selection criteria, a contract clause list and a monitoring cycle. That Annex binds no other entity, so what follows indicates what an authority might consider adequate rather than your obligation.

The policy comes first. Under Annex point 5.1.1 the entity establishes a supply chain security policy governing relations with direct suppliers, and "the relevant entities shall identify their role in the supply chain and communicate it to their direct suppliers and service providers." That second half is easy to skip and hard to fake later: it produces dated evidence outside your own systems. Selection comes next: "the relevant entities shall lay down criteria to select and contract suppliers and service providers. Those criteria shall include the following": the supplier's cybersecurity practices including secure development, its ability to meet your specifications, the quality of what it sells you, and your ability to diversify supply where that applies.

Contract terms the implementing regulation names

Point 5.1.4 of the Annex is the operative text for anyone buying a security service, and its hedging is load-bearing. It says that "the relevant entities shall ensure that their contracts with the suppliers and service providers specify, where appropriate through service level agreements, the following, where appropriate". Two qualifications sit in that sentence, so nothing below is an unconditional term. It is a list you consider and, where you decline, document.

1. Cybersecurity requirements on the supplier, including the acquisition requirements at Annex point 6.1
2. Awareness, skills and training for its staff, with certifications where appropriate
3. Background verification of the supplier's employees
4. Notification of incidents that present a risk to your systems, without undue delay
5. The right to audit, or to receive audit reports
6. Handling of vulnerabilities that put your systems at risk
7. Subcontracting rules, and cybersecurity requirements on subcontractors where allowed
8. Termination obligations, including retrieval and disposal of information held

Three of them decide whether an outsourced setup can produce evidence at all. In the Annex the notification clause reads "an obligation on suppliers and service providers to notify, without undue delay, the relevant entities of incidents that present a risk to the security of the network and information systems of those entities;" Without it you learn about your own incident on your provider's schedule rather than on the clock the directive runs. The audit clause is short, "the right to audit or right to receive audit reports;", and it separates an evidence request you can answer from one you forward. The subcontracting clause reads "requirements regarding subcontracting and, where the relevant entities allow subcontracting, cybersecurity requirements for subcontractors in accordance with the cybersecurity requirements referred to in point (a);" A provider that subcontracts your detection without it has moved your systems beyond your contract's reach.

Signature is not the end of it. Annex point 5.1.6 requires that "The relevant entities shall review the supply chain security policy, and monitor, evaluate and, where necessary, act upon changes in the cybersecurity practices of suppliers and service providers, at planned intervals" and when significant changes or incidents occur. Point 5.1.7 sets out what that monitoring consists of: regular review of reports on the implementation of service level agreements where applicable, review of incidents related to suppliers' ICT products and services, an assessment of whether unscheduled reviews are needed with the findings documented, and analysis of the risks presented by changes to those products and services, with mitigating measures in a timely manner where appropriate. ENISA's guidance adds a sweep across the existing book: "Ensure that, in all relevant new and renewed contracts, the requirements from point 5.1.4 of the Annex to the regulation are included." Renewals are where this quietly fails: terms carried forward unchanged look like continuity in the register and like a gap in an audit. Outsourced development is pulled back too. Annex point 6.2.3 states that "For outsourced development of network and information systems, the relevant entities shall also apply the policies and procedures referred to in points 5 and 6.1."

One sentence converts every judgment call into an artifact. Where the Annex hedges a requirement with "where appropriate", "where applicable" or "to the extent feasible" and the entity concludes it does not apply, Article 2(2) says "the relevant entity shall in a comprehensible manner document its reasoning to that effect." That is where most of an outsourced paper trail is created. A decision not to demand a clause is the kind of thing nobody writes down until somebody asks.

What a supervisor asks an outsourced setup for

Supervision is a set of powers competent authorities must have rather than a schedule anyone is placed on. The power that decides whether an outsourced program can answer is Article 32(2)(g), covering "requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence." The power is broader than a certificate or a vendor summary: it reaches evidence of implementation, and it names audit results and the evidence underneath them as an example. If your provider holds that evidence and your contract does not reach it, the request has no good answer.

The regime is not uniform. For essential entities Article 32(2) lists seven powers: on-site inspections and off-site supervision, regular and targeted security audits by an independent body or a competent authority, ad hoc audits, security scans, requests for information, requests to access data and documents and requests for evidence of implementation. Important entities face six of them, exercised after the fact, on the trigger in Article 33(1): "When provided with evidence, indication or information that an important entity allegedly does not comply with this Directive" Their audit power is targeted audits alone: the regular audits and the ad hoc audits both drop out. In both regimes authorities "have the power to subject those entities at least to": the enumerated items, so these are floors rather than ceilings.

Three details follow, all from the directive's supervision chapter. An authority exercising those powers must state why: "the competent authorities shall state the purpose of the request and specify the information requested." The bill for an independent audit lands on you: "The costs of such targeted security audit carried out by an independent body shall be paid by the audited entity, except in duly substantiated cases when the competent authority decides otherwise." An audit report can itself become an obligation. Enforcement powers include the power to "order the entities concerned to implement the recommendations provided as a result of a security audit within a reasonable deadline;"

What the fine figures actually say

The two figures everyone quotes are national maxima Member States must at least provide for, not penalties an entity pays and not fixed ceilings. A Member State may legislate higher. For essential entities infringing Article 21 or 23, Article 34(4) requires "administrative fines of a maximum of at least EUR 10 000 000 or of a maximum of at least 2 % of the total worldwide annual turnover in the preceding financial year" of the undertaking, whichever is higher. Article 34(5) uses the same construction for important entities: "administrative fines of a maximum of at least EUR 7 000 000 or of a maximum of at least 1,4 % of the total worldwide annual turnover in the preceding financial year" of the undertaking, whichever is higher.

The words "a maximum of at least", read in Article 34, are the whole point. Dropping them turns a floor on national law into a number about your company. Fines sit on top of the other measures rather than replacing them, and no source behind this article contains one actually imposed.

Where ENISA guidance helps and where it stops

ENISA published technical implementation guidance in June 2025. For an evidence file it is the most useful document here, pairing Annex requirements with guidance and examples of evidence.

Two limits matter. The first is scope. the guidance landing page says "This report provides technical guidance to support the implementation of the NIS2 Directive for several types of entities in the NIS2 digital infrastructure, ICT service management and digital providers sectors." so it tracks the implementing regulation's perimeter rather than the whole directive. The second is status, which ENISA states in its own legal notice: "This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to Regulation (EU) 2019/881." The Commission says the same of the NIS Cooperation Group's output, noting that "The group publishes non-binding guidelines and recommendations to support the implementation of the NIS Directive." Following ENISA closely is a strong defensive position. It is not compliance, and no document here makes it so.

How Pharos Production helps

Turning somebody else's control into your own evidence, on a cadence, is a build. We build that layer: supplier registers wired to contract terms, dated approval records, renewal alerts and the reasoning file Article 2(2) asks for. If you want that trail to hold when an authority asks for the underlying material, our cybersecurity services team can work through what your setup has to produce.

Sources: Directive (EU) 2022/2555 (NIS2), Articles 1, 6, 20, 21, 23, 32, 33 and 34, Annex I and recitals 83, 85 and 86 (CELEX 32022L2555). Commission Implementing Regulation (EU) 2024/2690, Article 1, Article 2(2) and Annex points 1.1, 1.2, 2.1, 2.3, 5.1, 6.1, 6.2.3 and 8.1 (CELEX 32024R2690). ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025. The European Commission NIS2 Directive policy page. The National Cyber Security Centre Ireland NIS2 page, last updated 24 June 2025. Read on 7 September 2026. This is engineering guidance, not legal advice.

FAQ

Last updated: September 8, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Can NIS2 compliance be outsourced?

  Copy link Copies a direct link to this answer to your clipboard.

  The work can, the answerability cannot. Nothing in Directive (EU) 2022/2555 prohibits outsourcing any of the Article 21(2) measures, and its recital 83 states that the obligations apply whether an entity maintains its systems internally or outsources their maintenance.

  What does not move is Article 20, under which Member States must ensure that management bodies approve the measures, oversee implementation and can be held liable for infringements, and that members of those bodies follow training themselves. A provider can run detection, testing or backups. For the entity types Commission Implementing Regulation (EU) 2024/2690 binds, it cannot be the one that approves the security policy or accepts the residual risk: the Annex puts that with the management bodies, or with the persons who are accountable and have the authority to manage risks.

• Which NIS2 measures can a managed service provider deliver?

  Copy link Copies a direct link to this answer to your clipboard.

  In practice a provider can carry the operational core of incident handling, vulnerability management, backup and recovery, identity and access management and the tooling that holds policies and risk registers. That split is an editorial reading rather than a legal classification, because no source assigns any measure to a delivery model.

  What consistently stays inside is anything the implementing regulation ties to management bodies, for the entity types it binds and as an indication for everyone else: acceptance of risk assessment results and residual risk, by the management bodies or the persons accountable for the risk, formal approval of the security policy, the direct reporting line on security matters and the annual policy review. Our own three criteria for everything else are entity size, which the Article 21(1) proportionality test already makes relevant, whether you can staff continuous coverage and whether the Annex names the entity or its management bodies as the actor.

• Is a managed security service provider itself in scope for NIS2?

  Copy link Copies a direct link to this answer to your clipboard.

  It may be. Article 1(2)(b) of the directive covers cybersecurity risk-management measures and reporting obligations for entities of a type referred to in Annex I or II, and Annex I lists managed service providers and managed security service providers under its ICT service management sector.

  Subject to the size rules, the provider you appoint can be an essential or important entity in its own right, with its own Article 21 measures and its own supervisor. That cuts two ways. Its compliance is not yours, and nothing in these sources lets one entity's status answer for another's. Appointing it still makes it your direct supplier under Article 21(2)(d), so its regulated status is a selection criterion rather than a substitute for your own evidence.

• What contract terms does NIS2 require with a security vendor?

  Copy link Copies a direct link to this answer to your clipboard.

  The directive itself names none. Commission Implementing Regulation (EU) 2024/2690 does, at Annex point 5.1.4, but only for the entity types in its Article 1 and with doubled hedging: contracts specify the items where appropriate, and where appropriate through service level agreements.

  The eight cover cybersecurity requirements, training and certifications, background verification, incident notification without undue delay, a right to audit or to receive audit reports, vulnerability handling, subcontracting and termination obligations including retrieval and disposal of information. For entities outside that Article 1 list, treat it as a strong template rather than a rule that binds them.

• What evidence does a supervisory authority want from an outsourced setup?

  Copy link Copies a direct link to this answer to your clipboard.

  The same evidence as from an in-house one, which is the difficulty. For essential entities, Article 32(2) requires Member States to ensure that competent authorities have the power to demand evidence of implementation of cybersecurity policies, such as the results of security audits by a qualified auditor together with the underlying evidence, and Article 33(2) carries the same power for important entities.

  An authority states the purpose of a request and specifies what it wants, so the demand is bounded, and nothing in the power limits it to a vendor certificate: the request reaches the underlying material. If that material sits with a provider and no contract clause reaches it, the answer is unavailable rather than merely slow.

• Are essential and important entities supervised the same way?

  Copy link Copies a direct link to this answer to your clipboard.

  No, and the difference matters when you plan an outsourced evidence file. Article 32(2) gives competent authorities seven powers over essential entities: on-site inspections and off-site supervision, regular and targeted security audits by an independent body or a competent authority, ad hoc audits, security scans, requests for information, requests to access data and documents and requests for evidence of implementation.

  Article 33(2) gives six over important entities, exercised after the fact, on the Article 33(1) trigger of evidence, indication or information of alleged non-compliance. The regular audits and the ad hoc audits are absent from that list and targeted audits remain. Both lists are minimums on what Member States give their authorities, so neither is a ceiling.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.