NIS2 Compliance Software Requirements
NIS2 never names a software company as a regulated type. This piece sorts a software vendor into the route that actually applies, then lists the artifacts each route asks it to keep on a shelf.
21 min read
26 views
Key takeaways: NIS2 compliance software requirements 5
Why no Annex row names a software company, the two functional definitions that reach one anyway, what differs between essential and important entities, the supply chain diligence duty that binds you without regulating you and what the implementing regulation adds for eleven named types.
- NIS2 is a Directive: your obligation comes from your national transposing law Your own obligation comes from your national transposing law, not from the directive itself, except for Commission Implementing Regulation (EU) 2024/2690, which binds eleven named entity types directly.
- No Annex row names a software company; two functional definitions reach one anyway You reach scope through the managed service provider definition (Article 6, point 39) or the cloud computing service definition (Article 6, point 30, recital 33), which explicitly includes Software as a Service.
- Essential and important entities owe identical obligations; supervision and fines differ Essential and important entities owe identical Article 20, 21 and 23 obligations. What differs is supervision (random checks against ex post reviews), fine ceilings and an essential-entity-only management ban.
- Supply chain diligence can bind you commercially without making you a regulated entity Even when you are not an in-scope entity yourself, Article 21(3) supply chain diligence makes your security posture a contractual condition for any in-scope customer, with no filing or fine attached to you directly.
- The implementing regulation turns ten measure headings into roughly 153 numbered requirements Where Commission Implementing Regulation (EU) 2024/2690 applies to you, Article 21's ten measure headings become roughly 153 numbered Annex requirements, our own count as read on 16 August 2026, several of which map directly to artifacts a modern SDLC and CI/CD pipeline already produce, such as security testing records, patch decisions and environment separation.
NIS2 compliance software requirements sound like a single checklist until you notice that Directive (EU) 2022/2555 never once names a software company, a software vendor or a development agency as a regulated type. If a customer's procurement team has handed you a questionnaire, the honest first move is not to answer it, it is to work out which of a small number of legal positions you are actually in, because each one produces a different answer. What follows sorts that question into named outcomes, then lists what has to exist on a shelf once you know which outcome applies to you.
In short: NIS2 binds Member States, not companies directly, so your own obligation comes from a national transposing law that may go further than the directive (Article 5). The one exception is Commission Implementing Regulation (EU) 2024/2690, which applies directly and identically across the Union, but only to eleven named entity types. No Annex row names a software company. Scope has exactly two entry routes: the managed service provider definition at Article 6, point (39), and the cloud computing service definition at Article 6, point (30), which recital (33) states explicitly covers Software as a Service. A customer's own supply chain diligence duty is a third thing entirely, a contractual reach that does not put you in scope at all. Essential and important entities owe identical obligations under Articles 20, 21 and 23. What differs is supervision, fine ceilings and, for essential entities only, a management ban.
Why nobody can tell you whether you comply
Directive (EU) 2022/2555 is a directive, and every operative sentence in it takes the same form: Member States shall ensure. Article 41(1) required transposition "By 17 October 2024, Member States shall adopt and publish the measures necessary to comply with this Directive", with those measures applying from 18 October 2024. Nothing in that sentence creates a duty on your company; your duty comes from whichever national law your Member State passed, and Article 5 lets that law go further: "This Directive shall not preclude Member States from adopting or maintaining provisions ensuring a higher level of cybersecurity, provided that such provisions are consistent with Member States’ obligations laid down in Union law." That is why no article, including this one, can tell you what you must do, only what the floor is.
One exception: Commission Implementing Regulation (EU) 2024/2690 is a Regulation, applying directly and identically across the Union with no transposition step, but only to eleven named entity types. If you are not one of them, it never touches you, whatever your national transposing law says about the directive's ten Article 21 measure headings.
Does a sector-specific act take you out before you start
Before any scope test runs, check whether a more specific EU regime already covers you. Article 4(1) of the directive says: "Where sector-specific Union legal acts require essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents and where those requirements are at least equivalent in effect to the obligations laid down in this Directive, the relevant provisions of this Directive, including the provisions on supervision and enforcement laid down in Chapter VII, shall not apply to such entities." For much of our own readership, the sector-specific act that matters is DORA. A financial entity inside DORA's scope is displaced out of the equivalent NIS2 provisions entirely; that reader should read our DORA compliance software architecture coverage instead. The displacement is not total: where a sector act misses some entities in a sector, the directive keeps applying to them. If Article 4(1) does not take you out, keep going.
There is no Annex row for a software company, only two definitions that reach you
The directive's Article 2(1) sets three cumulative conditions for scope: an Annex I or Annex II type, a size at or above medium and activity in the Union. The type test comes first, and it tests what you are, not what you sell. Annex I sector 9, "ICT service management (business-to-business)", holds exactly two rows: "Managed service providers" and "Managed security service providers". Annex I sector 8 includes "Cloud computing service providers"; Annex II sector 6 includes "Providers of online marketplaces" alongside search engines and social networking platforms. An exhaustive search of both instruments for the terms software vendor, software company, software developer, software development, software house and system integrator returns zero hits in every case, and that absence is a fact about the search, not a statement that software companies fall outside NIS2, because a software company can still reach scope through a functional definition.
From here the sieve sorts a software company into one of four named verdicts, and each later section opens by stating which one it binds. Verdict 1 is in scope through the managed service provider definition, and Verdict 2 is in scope through the cloud computing service definition. A national designation moves either one into Verdict 3 regardless of size, without adding a third type test of its own. The remainder, Verdict 4, is not in scope at all, reachable only through a customer's own supply chain diligence duty.
The managed service provider definition, and what it leaves open
Article 6, point (39) of the directive, the route to Verdict 1, is the one that catches the most software companies:
"‘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, via assistance or active administration carried out either on customers’ premises or remotely;"
Four verbs, installation, management, operation and maintenance, five object classes and two delivery modes, all joined disjunctively, with no size floor, no criticality qualifier and no exclusion for one-off work written into the definition itself. It never mentions development, and no recital elaborates which delivery models it covers. Two practical cases stay genuinely open. Whether staff augmentation into a customer's own operations team counts as assistance with operating those systems, or falls outside the definition because the customer directs the work, is not settled anywhere in the directive or its recitals. Whether a fixed-scope build with no ongoing operational role counts as a managed service is the same kind of question, weaker for build-and-hand-over and stronger for build-and-run. Neither is resolved here. Until either question is settled, document which reading you are taking: staff augmentation against autonomous delivery, build-and-hand-over against build-and-run. Where the delivery model sits close to the line, plan toward the artifacts a managed service provider would need instead of assuming the narrower reading. That documentation costs little if the question resolves in your favor, and it leaves you ready if it does not.
Is a SaaS product a cloud computing service under NIS2
Verdict 2 is covered here. Article 6, point (30) defines the second functional route: "‘cloud computing service’ means a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources, including where such resources are distributed across several locations". Read alone that sounds like infrastructure, until recital (33) closes the gap most SaaS teams miss: "The service models of cloud computing include, inter alia, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Network as a Service (NaaS)." A B2B SaaS product is therefore a service model of cloud computing on the directive's own account, and a vendor satisfying Article 6, point (30) is a cloud computing service provider under Annex I sector 8, subject only to the size test next.
A recital is an interpretive aid, not an operative provision; the binding text is Article 6, point (30) itself, where the word shareable is doing real work. Where that word puts single-tenant or on-premises software is not settled here. A product giving each customer dedicated rather than shared resources has a real argument for sitting outside the definition, and this piece does not resolve that boundary. Recital (35) does resolve one adjacent case: "The term ‘data centre service’ should not apply to in-house corporate data centres owned and operated by the entity concerned, for its own purposes."
How big you have to be, and who can pull you in below that floor
The directive delegates sizing entirely to Recommendation 2003/361/EC, minus one rule. Article 2(1) of that Recommendation's Annex sets the ceilings: "The category of micro, small and medium-sized enterprises (SMEs) is made up of enterprises which employ fewer than 250 persons and which have an annual turnover not exceeding EUR 50 million, and/or an annual balance sheet total not exceeding EUR 43 million." Headcount is joined to the financial tests by "and" and is mandatory; the two financial tests are joined to each other by "and/or". There is no separate NIS2 headcount rule, only this borrowed test applied through the directive's Article 2(1), which catches you once you qualify as medium-sized or exceed the medium ceilings. That leaves the practical question of where medium begins, and the Recommendation's own Article 2(2) answers it: small ends and medium begins at roughly 50 employees or EUR 10 million, whichever a company crosses first. State this as the Recommendation's arithmetic, not as a NIS2 headline number; the directive borrows the test, it does not restate the floor.
Two features of the borrowed test rarely make a NIS2 summary. Status has hysteresis: "this will not result in the loss or acquisition of the status of medium-sized, small or microenterprise unless those ceilings are exceeded over two consecutive accounting periods". Linked enterprises also consolidate at full strength: "To the data referred to in the first and second subparagraph is added 100 % of the data of any enterprise, which is linked directly or indirectly to the enterprise in question, where the data were not already included through consolidation in the accounts." A forty-person shop majority-owned by a large group is sized as the group. The directive disapplies only the Recommendation's public-body ownership rule, nothing else.
The national-designation route, and where you land once you're in
Size is not always the gate, and this route lands you at Verdict 3, which attaches to Verdict 1 or Verdict 2 rather than adding a third type test. The directive's own Article 2(2) states: "Regardless of their size, this Directive also applies to entities of a type referred to in Annex I or II, where:", and point (b) reaches "the entity is the sole provider in a Member State of a service which is essential for the maintenance of critical societal or economic activities". Points (b) to (e) are national designations made by a competent authority, not conclusions you reach yourself.
Once you are in, the classification that follows is closed. Essential is a list of seven cases in the directive's Article 3(1); everything else in scope is important by residual definition: "entities of a type referred to in Annex I or II which do not qualify as essential entities pursuant to paragraph 1 of this Article shall be considered to be important entities." A medium-sized MSP or cloud provider is an important entity unless it exceeds the medium ceilings or is nationally designated as essential. The obligations at Articles 20, 21 and 23 are worded identically for both, a point the next section returns to.
The route where you are not in scope at all, and it still costs you the deal
Verdict 4 is covered here, and most software companies that answer this honestly land in it. Article 21(2)(d) makes supply chain security a mandatory measure heading for essential and important entities themselves: "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;" Article 21(3) then requires Member States to ensure those regulated customers, not you, weigh your security posture when choosing their measures, taking into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." Recital (85) names your category once, as an example on the customer's supplier list rather than as a regulated type: "Addressing risks stemming from an entity’s supply chain and its relationship with its suppliers, such as providers of data storage and processing services or managed security service providers and software editors, is particularly important".
What that duty does not make you
None of that makes you a regulated entity. No provision here creates an Article 23 incident report for you, no relationship with a national CSIRT and no Article 34 fine, because those attach to the essential or important entity, not to its suppliers. What you actually face is your customer's own diligence and, if you fail it, a lost deal rather than a filing. The recital's language about contracts is only hortatory, entities "should in particular be encouraged" to write cybersecurity terms into supplier contracts, so the directive mandates no specific clause. What turns this into eight concrete contract clauses is Commission Implementing Regulation (EU) 2024/2690, only where your customer is one of its eleven named types, which is where the sections below pick up.
What the implementing regulation adds, and only for eleven types
Article 1 of Commission Implementing Regulation (EU) 2024/2690 names its own closed list: "This Regulation, with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers (the relevant entities) lays down the technical and the methodological requirements of the measures referred to in Article 21(2) of Directive (EU) 2022/2555". If you land in one of those eleven categories, the directive's ten Article 21(2) measure headings stop being open-ended and become an Annex of numbered requirements, built on standards such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401, so existing certification evidence maps across without being automatic compliance. Both routes this piece has described for a software company, the managed service provider definition and the cloud computing service definition, are themselves two of those eleven categories, so a software company that reaches scope through either one is always inside the eleven and the next two sections always bind it directly. A different Annex I or II type that sits outside the eleven, healthcare or energy for instance, is a different reader's question, not this one's.
One clause in the implementing regulation is worth reading before any other, because it changes what every soft qualifier in the Annex means. The implementing regulation's own Article 2(2) requires that where a requirement is qualified by "where appropriate" or a similar phrase and the entity declines it, "the relevant entity shall in a comprehensible manner document its reasoning to that effect." Every "where appropriate" in the Annex is a documentation obligation, not an exemption.
The eight clauses your customer puts in the contract, once it is one of the eleven
This is where Verdict 4 turns into paper. Annex point 5.1.4 of the implementing regulation runs eight clauses, (a) to (h), each qualified "where appropriate through service level agreements" or "where appropriate", so your customer keeps discretion, but under the documentation rule above, declining one costs your customer a written reason. Two are worth reading verbatim. The supplier notification clause: "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;" And the audit clause: "the right to audit or right to receive audit reports;" The remaining six clauses cover cybersecurity requirements, training and certification requirements, background verification of supplier employees, vulnerability handling obligations, subcontracting requirements and termination obligations including retrieval and disposal of information. Two adjacent Annex points widen the same list rather than adding to the count of eight. Point 5.1.2(d) sets a selection criterion: "the ability of the relevant entities to diversify sources of supply and limit vendor lock-in, where applicable." And point 5.2 requires your customer to keep a registry of its direct suppliers, with a contact point and a list of the ICT products, services and processes each one provides. None of this is a duty on you. It is what your customer's own compliance obligation gives it standing to put in front of you at contract time, and it is the concrete shape of the diligence duty the earlier section named but did not itemise.
The shelf Article 21 actually asks for, from your repository
For the eleven named types, the Annex turns engineering discipline you may already practice into an evidenced requirement. Annex point 6.2.1 requires that before writing code, "the relevant entities shall lay down rules for the secure development of network and information systems and apply them when developing network and information systems in-house, or when outsourcing the development of network and information systems", covering "specification, design, development, implementation and testing". That means an analysis of security requirements "at the specification and design phases of any development or acquisition project" under point 6.2.2(a), a documented security testing policy under point 6.5.1 and patch management with an explicit escape hatch under point 6.6: "security patches are applied within a reasonable time after they become available", but "the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits", provided they "duly document and substantiate the reasons for any such decision." A patch you skipped and documented is defensible. A patch you never noticed is not, because "reasonable time" is undefined and the documented decision is the actual control.
What's missing from most teams' shelf
Two artifacts most teams do not already produce sit behind that list. The first has no NIS2 name: Annex point 6.1.2(c) requires an acquisition process to include "information describing the hardware and software components used in the ICT services or ICT products", a component inventory by function even though neither instrument uses the word SBOM. Our AI supply chain security coverage specifies that artifact in detail. The second is a written procedure for disclosing vulnerabilities "in accordance with the applicable national coordinated vulnerability disclosure policy" under point 6.10.2(e), the same procedure our CRA vulnerability handling requirements piece covers under the neighbouring regulation. Environment separation reaches further than most teams assume: point 6.8.2(h) requires production kept separate from development and testing systems, "including backups", where separation most often quietly fails. If this shelf is mostly empty, our phased application security checklist is the more useful next read.
The two clocks that make an incident reportable before you have classified it
Our CRA, NIS2 and DORA reporting overlap coverage already walks the three regimes' clocks side by side, so this section stays narrow: two facts that page does not carry, both specific to the eleven CIR types. First, Article 10(a) of the implementing regulation makes availability itself the trigger for a managed service: "a managed service or managed security service is completely unavailable for more than 30 minutes" is a significant incident by definition, inside most teams' detection latency, let alone their classification latency. Second, Article 4 of the same regulation aggregates incidents that would not individually qualify: "Incidents that individually are not considered a significant incident within the meaning of Article 3, shall be considered collectively as one significant incident where they meet all of the following criteria", one of which is that "they have occurred at least twice within 6 months". Evaluating that is a stateful query over an incident database and a shared root cause, not a per-incident judgment call.
The directive-level filing clocks, and where each one starts
Our CRA, NIS2 and DORA reporting overlap coverage already walks the full directive-level filing sequence and where each clock starts. This shelf adds only what that page does not carry for the eleven CIR types: the 30 minute managed-service unavailability trigger and the Article 4 six-month recurrence aggregation above.
What a supervisor can demand, and the one artifact that is a signature
Supervision is where essential and important entities actually diverge, not the underlying obligations. Both classes face the same evidence demand, under Article 32(2)(g) for essential entities and the identically worded Article 33(2)(f) for important ones: "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." Both also face on-site inspections and off-site supervision, but only the essential entity power includes "random checks conducted by trained professionals" (Article 32(2)(a)); the important entity equivalent is qualified "ex post" instead (Article 33(2)(a)), checks after the fact, not at random. Essential entities alone face a temporary certification suspension and a management ban, letting a supervisor "request that the relevant bodies, courts or tribunals, in accordance with national law, prohibit temporarily any natural person who is responsible for discharging managerial responsibilities at chief executive officer or legal representative level in the essential entity from exercising managerial functions in that entity." When an independent body carries out a targeted audit: "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." The entity funds its own scrutiny by default.
The management-body approval, and the training duty next to it
One artifact in this regime is not a document at all, it is a dated act by a named body. The directive's Article 20 requires that "Member States shall 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 entities of that Article", and separately "Member States shall ensure that the members of the management bodies of essential and important entities are required to follow training". Approve, not be aware of: a minute with a date on it. Training is mandatory for the management body itself while only encouraged for everyone else, the reverse of how most security awareness programmes are built.
Which country is asking, and what you build without knowing
For the digital-service categories covered here, jurisdiction is single rather than per Member State you sell into. The directive's Article 26(1)(b) puts an entity "under the jurisdiction of the Member State in which they have their main establishment in the Union", and Article 26(2) resolves what that means: "an entity as referred to in paragraph 1, point (b), shall be considered to have its main establishment in the Union in the Member State where the decisions related to the cybersecurity risk-management measures are predominantly taken." That is a question about where the person who approves the security policy sits, not where the servers run or the revenue is booked, and the natural evidence is the same approval minute from the previous section. A vendor with no EU establishment at all is not exempt: "If an entity as referred to in paragraph 1, point (b), is not established in the Union, but offers services within the Union, it shall designate a representative in the Union", and that designation is what fixes which Member State supervises it.
What to build before your national transposition law is settled
None of that changes the fact that your actual duty is national. As at 16 August 2026, the EUR-Lex collection of national transposition measures for Directive (EU) 2022/2555 lists communicated measures for 25 of the 27 Member States, with none listed for Ireland and none for Spain. That collection is a record of measures Member States have communicated to the Commission, and communicating a measure is not the same as transposing it, so treat the count as a lagging indicator rather than a verdict on any single country. A measure count is not a statement about completeness, and no measures listed is not the same as no law: it only means no measure has been notified into that collection. What you can build without waiting for a national answer is the part that does not change by country: a documented classification of which route you are on, the artifacts the earlier sections named and a dated management approval of the whole exercise. Whichever country ends up asking, that is the shelf it will ask to see.
Sources: Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 4, 5, 6, 20, 21, 23, 26, 32, 33, 34 and 41; recitals 33, 35 and 85; via EUR-Lex (CELEX 32022L2555). Commission Implementing Regulation (EU) 2024/2690, Article 1, Article 2(2), Article 3, Article 4, Article 10 and its Annex points 5.1.2(d), 5.1.4, 5.2, 6.1.2(c), 6.2.1, 6.2.2(a), 6.5.1, 6.6.1(a), 6.6.2, 6.8.2(h) and 6.10.2(e), via EUR-Lex (CELEX 32024R2690). Commission Recommendation 2003/361/EC, Annex Articles 2(1), 2(2), 4(2) and 6(2), via EUR-Lex (CELEX 32003H0361). The EUR-Lex national transposition measures collection for Directive (EU) 2022/2555, read 16 August 2026. This is engineering guidance, not legal advice, and it does not state what any single Member State's transposing law requires.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
Not by name. Neither Directive (EU) 2022/2555 nor Commission Implementing Regulation (EU) 2024/2690 lists a software company, software vendor or software developer as a regulated type.
A software company reaches scope only through a functional definition: the managed service provider definition at Article 6, point (39), or the cloud computing service definition at Article 6, point (30). Many software companies are not caught by either and instead face only their customers' supply chain diligence under Article 21(3), which does not make them a regulated entity.
-
Recital (33) of the directive states that the service models of cloud computing "include, inter alia, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Network as a Service (NaaS)". A B2B SaaS product that satisfies Article 6, point (30), on-demand administration plus broad remote access to a scalable and elastic pool of shareable computing resources, is a cloud computing service provider under Annex I sector 8, subject to the size test.
Where single-tenant or on-premises software sits relative to "shareable" is not settled by the text.
-
The obligations are identical: Articles 20, 21 and 23 apply to essential and important entities in the same words. What differs is supervision and consequence.
Essential entities face random checks and regular targeted audits (Article 32); important entities face ex post supervision only (Article 33). The fine ceilings differ too, and both are whichever-is-higher ceilings attaching only to an Article 21 or 23 infringement: EUR 10 000 000 or 2 percent of group turnover, whichever is higher, for an essential entity, against EUR 7 000 000 or 1,4 percent, whichever is higher, for an important one. And only essential entities face a temporary certification suspension and a management ban (Article 32(5)).
-
Neither instrument uses the term SBOM or "software bill of materials". But Commission Implementing Regulation (EU) 2024/2690, Annex point 6.1.2(c), requires an acquisition process to include "information describing the hardware and software components used in the ICT services or ICT products", which functions as a component inventory even without the name, and only for the eleven named entity types.
-
Legally, no NIS2 provision compels you to. Article 21(3) requires the Member State to ensure your customer, if it is an essential or important entity, takes your security practices into account when choosing its own supply chain measures.
That duty sits with your customer, not with you. Commercially, declining the questionnaire risks the deal, because your customer's own compliance and, where it is one of the eleven CIR-2024/2690 types, its own documented contract requirements depend on your answer.
-
Potentially, through the same functional definitions and only if the company offers services within the Union. Article 26(3) requires an entity with no EU establishment that offers services within the Union to designate a representative in the Union, and that designation fixes which Member State has jurisdiction.
This does not create a new category of obligation, it only answers which Member State's transposing law would apply.
-
It is a directly applicable EU Regulation that turns the directive's ten Article 21(2) measure headings into roughly 153 numbered technical requirements, our own count of the Annex's numbered points as read on 16 August 2026. It applies only to the eleven entity types named in its own Article 1: DNS service providers, TLD name registries, cloud computing service providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers.
If you are in scope of the directive but not one of these eleven, the Annex does not bind you directly.
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.
