AI Act Serious Incident Reporting

Skip key takeaways

Updated August 26, 2026

• Four limbs apply, not three; any one of them is enough Article 3, point (49) covers death or serious health harm, serious and irreversible disruption of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights and serious harm to property or the environment, joined by "any of the following".
• The limb selects the clock, and the shortest applicable clock wins Fifteen days is the general ceiling, two days applies to a widespread infringement or a point (49)(b) critical-infrastructure incident, and 10 days applies where a person died. Severity does not select the deadline, classification does.
• Article 73 did not change, but the recipient of the report did Regulation (EU) 2026/1744 replaced Article 75, and new Article 75(1a) routes serious incidents to the AI Office for providers inside its competence. The financial-institution carve-out from that competence is conditional on Article 74(6), which itself only reaches systems in direct connection with the provision of financial services.
• You cannot fix the system before you tell the authority Article 73(6) forbids any investigation that alters the system in a way which may affect a later evaluation of causes before the competent authorities have been informed, so mitigation and investigation need separate paths in the architecture.
• The obligations bite on 2 December 2027, not on 2 August 2026 Regulation (EU) 2026/1744 moved standalone Annex III high-risk applicability to 2 December 2027 and the Annex I route to 2 August 2028, with Article 6(5) carved out of the deferral.
• The tier is 15 million, not 35 million, reached by cross-reference Article 73 sets no fine of its own and is never named in Article 99. The provider route runs Article 99(4)(a) to Article 16(c) to Article 17(1)(i) and lands at the 15 million tier, while the 35 million tier belongs to Article 5 prohibited practices and never reaches this duty.

Copy takeaways

A production model does something it should not have done, the alert fires and the runbook says notify the vendor. Under the AI Act that runbook is a legal instrument with a clock attached, and which clock runs depends on which limb of a single definition the event falls into. Teams that have worked through AI Act high risk classification usually treat Article 73 as a footnote to that conclusion. It is where the classification becomes an operational duty, and compressing four limbs into one deadline erases distinctions the Regulation makes on purpose. That makes it an engineering problem before it is an AI governance problem, because the classification has to happen inside the incident channel, in hours, by people who are mid-incident.

In short: the AI Act defines a serious incident in four alternative limbs, and any one of them is enough. Three deadlines attach to those limbs, 15 days as the general rule, two days for a critical-infrastructure incident or a widespread infringement, and 10 days where a person died, so the shortest applicable clock governs. Article 73 was not amended in 2026, but Regulation (EU) 2026/1744 replaced Article 75, and providers inside the AI Office's competence now report to the AI Office rather than to a national authority. The obligations themselves apply from 2 December 2027 for Annex III high-risk systems, not from 2 August 2026.

What counts as a serious incident under the AI Act

Article 73 never defines its own trigger. It borrows one, from Article 3, point (49), and that definition is easy to compress into fewer limbs than it has. Its chapeau says a serious incident means an incident or malfunctioning of an AI system that "directly or indirectly leads to any of the following", and four items follow, in Regulation (EU) 2024/1689. Two words in that phrase carry the weight. Indirectly pulls in downstream effects, so a scoring model that never touches a person can still be the cause of an incident that reaches one through a decision built on its output. Any makes the four items alternatives rather than a cumulative test.

The four are short enough to quote in full. The first is "the death of a person, or serious harm to a person’s health". Its second limb is "a serious and irreversible disruption of the management or operation of critical infrastructure". The third is "the infringement of obligations under Union law intended to protect fundamental rights". The fourth is "serious harm to property or the environment". All four, and the chapeau above them, are in Regulation (EU) 2024/1689 as published in the Official Journal, and Regulation (EU) 2026/1744 left Article 3, point (49) alone.

Why a compressed definition attaches the wrong clock

Content that summarizes point (49) as harm to health or fundamental rights has dropped two limbs, and one of them changes the deadline. The critical-infrastructure limb, point (49)(b), is the only one of the four that carries the two-day clock. A team working from a three-limb summary has no field in which to record that an incident was a point (49)(b) event, so it cannot compute the deadline it is on. That is the difference between a report filed on day two and one filed on day 15 against a duty that expired on day two.

Three reporting clocks and what starts each one

The general rule sits in Article 73(2), and it has two halves. The report is made "immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link", and in any event "not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident". Those are two different moments. Awareness starts the outer limit. The causal link, or its reasonable likelihood, starts the immediate duty. A team that only records the awareness timestamp has instrumented half of the provision. Article 73(2) adds a second subparagraph stating that the reporting period "shall take account of the severity of the serious incident", which means the 15 days is a ceiling and not an entitlement. All three passages are in Regulation (EU) 2024/1689, Article 73.

Article 73(3) cuts that down. "In the event of a widespread infringement or a serious incident as defined in Article 3, point (49)(b)", the report goes out immediately and "not later than two days after the provider or, where applicable, the deployer becomes aware of that incident". Article 73(4) sets the third clock, for the death of a person. There the report is due "immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident", and at the outside "not later than 10 days after the date on which the provider or, where applicable, the deployer becomes aware of the serious incident". Note the word "suspects". The death clock starts earlier in the epistemic sequence than the general one does. All three paragraphs are in Regulation (EU) 2024/1689, unamended.

Widespread infringement is a defined term, and its two limbs are not the same

The two-day clock is usually reported as the critical-infrastructure deadline, which is half the trigger. "Widespread infringement" is defined at Article 3, point (61), and it too has alternative limbs with different thresholds. The first limb catches an act or omission contrary to Union law protecting the interest of individuals that "has harmed or is likely to harm the collective interests of individuals residing in at least two Member States" other than the state where the act originated, where the provider is located or where the deployer is established. The second limb requires more Member States and adds a similarity test: it catches an act or omission that "has common features, including the same unlawful practice or the same interest being infringed, and is occurring concurrently, committed by the same operator, in at least three Member States". Both are in Regulation (EU) 2024/1689, Article 3.

Two Member States against three, with a common-feature test on the higher one. For a system deployed across a European footprint that is a live question on the first morning of an incident. Answer it too generously and a routine defect becomes a two-day filing. Answer it too narrowly and a genuine multi-state harm gets 15 days it was never entitled to.

The incident taxonomy an engineering team has to implement

Everything above collapses into a data model. A triage record whose only classification field is a severity level cannot produce an AI Act deadline, because the Regulation selects the deadline by limb and by circumstance rather than by severity. Four fields have to be first class in the incident record, and each has to stay editable after creation, because all four routinely change as an investigation proceeds.

Limb classification comes first, as a set rather than a single value, because one event can satisfy more than one limb. Then the awareness timestamp, recorded per legal entity, since Article 73 names the provider and, where applicable, the deployer as separate subjects of awareness. Then causal-link status, with three states rather than two, because Article 73(2) turns on an established link or the reasonable likelihood of one while Article 73(4) turns on suspicion. Last, the widespread-infringement determination with its own Member State list, because the point (61) test cannot be derived from the limb classification at all.

The deadline is computed, never entered

Given those four fields the shortest applicable clock is a pure function, and it should be implemented as one rather than asserted by a human in a text box. A record carrying limb (b) alongside limb (a) is on the two-day clock, not the 10-day one, because two is shorter. The function should recompute on every field change, since Article 73(5) contemplates a moving picture. Either the provider or deployer "may submit an initial report that is incomplete, followed by a complete report", from Regulation (EU) 2024/1689. The Regulation would rather have a thin report on time than a complete one late, and a triage system built around a single final submission fights that design. An AI governance framework that stops at policy documents will not produce any of this, because none of it is a policy question.

Who receives the report, and why that changed on 27 July 2026

Article 73(1) still says what it always said. "Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred", in Regulation (EU) 2024/1689. Read on its own that sentence is now incomplete, because a different article moved underneath it.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, replaced Article 75 rather than editing it. The old article covered mutual assistance and the monitoring of general-purpose AI systems, and its first paragraph was a two-sentence grant of monitoring powers to the AI Office. The replacement is headed "Market surveillance and control of AI systems and mutual assistance" and opens with a rule that the AI Office "shall be exclusively competent for the supervision and enforcement of the obligations under this Regulation" over two categories of system. One category is systems "based on general-purpose AI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking as that provider", subject to four carve-outs. The second is systems "integrated into a very large online platform or very large online search engine designated in accordance with Regulation (EU) 2022/2065". Quoted from Regulation (EU) 2026/1744.

The consequence for incident reporting is in a new paragraph. Article 75(1a) provides that "By way of derogation from Article 73, providers of high-risk AI systems subject to the competence of the AI Office pursuant to paragraph 1 of this Article shall report any serious incidents to the AI Office", that Article 73(2) to (9) applies mutatis mutandis, and that the AI Office then transmits the information onward to the market surveillance authority of the provider's Member State, from Regulation (EU) 2026/1744. Every deadline in this article survives that reroute unchanged. Only the addressee moves.

The financial-institution carve-out is conditional, not a blanket exclusion

One of the four carve-outs from AI Office competence covers "AI systems provided by law enforcement authorities, border management authorities and financial institutions, insofar as those AI systems fall under Article 74(6)", from Regulation (EU) 2026/1744. The last clause is doing real work. Article 74(6) makes the national financial supervisor the market surveillance authority for a regulated firm's high-risk systems, but only "in so far as the placing on the market, putting into service, or the use of the AI system is in direct connection with the provision of those financial services", from Regulation (EU) 2024/1689. A bank system that is not in direct connection with a regulated financial service does not fall under Article 74(6), so the carve-out does not reach it, and where the system otherwise sits in AI Office competence the report goes to the AI Office. A FinTech that assumes its prudential supervisor receives everything has assumed away a condition the text spells out twice.

For most readers there is a cleaner answer than arguing about the carve-out. That competence is entered only through the two categories above, and it reaches deployers narrowly, applying to them "only when they are also the provider or form part of the same undertaking as the provider", from Regulation (EU) 2026/1744. A bank that fine-tunes a third-party foundation model into a credit decisioning system is neither that model's provider nor part of the same undertaking, so the class is never entered and Article 73(1) applies on its own terms. Test entry first and the carve-out second, and most firms stop at the first step.

After the report: investigation, corrective action and the change freeze

Filing does not close the obligation. Article 73(6) requires the provider, without delay, to "perform the necessary investigations in relation to the serious incident and the AI system concerned", and adds that "This shall include a risk assessment of the incident, and corrective action." The second subparagraph is the one that changes engineering practice. The provider "shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action", from Regulation (EU) 2024/1689.

Read that against a normal incident response and the friction is obvious. The instinctive first move is to roll back the model version or retrain on corrected data, and either can affect a later evaluation of causes, so the Regulation puts a notification in front of them. That argues for keeping mitigation and investigation on separate paths, and for a design where traffic can be routed away from a model without destroying the state that produced the incident.

Two more clocks that are not the provider's

The authority has its own deadline. Article 73(8) requires the market surveillance authority to take appropriate measures under Article 19 of Regulation (EU) 2019/1020 "within seven days from the date it received the notification". A fourth clock comes from Article 79, which supplies the deployer's suspension trigger in its second paragraph. Article 79(1) does not define its risk threshold in AI Act terms at all, defining it instead by cross-reference to a product presenting a risk under Article 3, point 19 of Regulation (EU) 2019/1020, "in so far as they present risks to the health or safety, or to fundamental rights, of persons". Where the authority finds non-compliance it requires corrective action, withdrawal or recall "within the shorter of 15 working days, or as provided for in the relevant Union harmonisation legislation". Both from Regulation (EU) 2024/1689. Fifteen working days is not fifteen days, and a remediation plan built on the calendar reading is already late.

Deployers are inside the reporting chain

A firm that buys a high-risk system rather than building one is not a bystander. Article 26(5) requires that "Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use", and where use in accordance with those instructions may result in an Article 79(1) risk they must "inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system". On a serious incident the same paragraph prescribes an order rather than a set of recipients. Deployers "shall also immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities of that incident", and where the deployer cannot reach the provider, Article 73 applies mutatis mutandis. From Regulation (EU) 2024/1689.

What the financial-services deeming provision does and does not cover

Regulated firms get one concession here and it is narrower than it is usually described. For deployers that are financial institutions already subject to internal governance requirements under Union financial services law, "the monitoring obligation set out in the first subparagraph shall be deemed to be fulfilled by complying with the rules on internal governance arrangements, processes and mechanisms pursuant to the relevant financial service law". That covers monitoring. It does not cover the suspension duty, the escalation duty or the serious-incident notification, none of which are deemed fulfilled by anything. Logs work the same way. Article 26(6) requires deployers to keep automatically generated logs under their control "of at least six months", and a financial institution "shall maintain the logs as part of the documentation kept pursuant to the relevant Union financial service law". That is a filing rule, not a waiver. Both from Regulation (EU) 2024/1689.

When the duty narrows to fundamental rights alone

Article 73(9) is the most commercially significant sentence in the article for a regulated firm, and it is routinely misquoted. For Annex III high-risk systems placed on the market or put into service by providers "that are subject to Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation, the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c)", from Regulation (EU) 2024/1689. Point (49)(c) is the fundamental-rights limb, so the narrowing drops the other three limbs out of the AI Act notification for those providers and leaves one standing.

The AI Act names a category, never an instrument

Nothing in Article 73(9) identifies which Union legislative instruments qualify. It describes a class by its effect, reporting obligations equivalent to those set out in the AI Act, and stops there. Financial firms often assume their existing major incident reporting regime satisfies it. That regime exists under the Digital Operational Resilience Act, Regulation (EU) 2022/2554, and the architecture behind it is the subject of our note on DORA compliance software architecture. Whether it is equivalent for Article 73(9) purposes is a judgment the AI Act leaves open, so the safe posture is to keep the full four-limb classification in the record even where notification is narrowed. The narrowing applies to what you send, not to what you have to know, and that distinction is the design brief for compliance and regtech solutions here.

When these obligations actually bite

Material saying that high-risk obligations applied from 2 August 2026 was written before the amendment, or was not updated after it. Regulation (EU) 2026/1744 replaced point (c) of the third paragraph of Article 113, and the current text applies "Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5)" from "2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III" and from "2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I", quoted from Regulation (EU) 2026/1744. Article 73 sits in Chapter III, Section 3, so the incident duty moves with it. The EU AI Act compliance timeline covers the dates that did not move.

What the carve-out and the grandfathering rule do

Article 6(5) is expressly excluded from the deferral, keeping the Commission's classification guidelines on their original 2 February 2026 date, unamended in Regulation (EU) 2024/1689. Legacy systems moved too: Article 111(2) grandfathering now moves with the Article 113 dates above, with public authority deployments still due "by 2 August 2030", from Regulation (EU) 2026/1744. The deadline for building the pipeline is not the deadline for using it. A firm procuring a high-risk system in 2027 will be asked for its incident process during due diligence, long before December.

What non-compliance with the incident duty costs

Article 73 sets no fine of its own. The fines that reach a provider or deployer of a high-risk AI system sit in Article 99, and Article 73 is never named there. For most providers and deployers, the only route to a tier is by tracing a cross-reference chain, and the chain matters because it changes both which tier applies and what exactly is being penalised. One population reaches the same tier a different way. For systems inside the AI Office's exclusive competence under Article 75(1), Article 75c(4) attaches an Article 99(4) fine directly to "infringement of any applicable provision of this Regulation, including those not listed in Article 99(4)". Article 75(1)(a)(iii) carves financial institutions covered by Article 74(6) out of AI Office competence, so this is a separate population from the financial-services providers and deployers discussed elsewhere in this article.

The tier is 15 million, not 35 million, and it arrives by cross-reference

Prohibited practices under Article 5 carry the top tier, fines "up to EUR 35 000 000 or, if the offender is an undertaking, up to 7 % of its total worldwide annual turnover for the preceding financial year, whichever is higher" under Article 99(3). That is not the tier for a missing or late Article 73 report, and treating it as one overstates the exposure.

The relevant tier is Article 99(4), set at "up to EUR 15 000 000 or, if the offender is an undertaking, up to 3 % of its total worldwide annual turnover for the preceding financial year, whichever is higher". For a provider, Article 99(4)(a) reaches "obligations of providers pursuant to Article 16", and Article 16(c) requires the provider to "have a quality management system in place which complies with Article 17". Article 17(1)(i) puts inside that system "procedures related to the reporting of a serious incident in accordance with Article 73".

For a deployer, Article 99(4)(e) covers "obligations of deployers pursuant to Article 26". Article 26(5) puts the provider first. "Where deployers have identified a serious incident, they shall also immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities of that incident." Article 73 enters only as a fallback. "If the deployer is not able to reach the provider, Article 73 shall apply mutatis mutandis".

The chain clearly reaches a defective or absent procedure. Because Article 17(1)(i) requires that procedure to comply with Article 73, the reporting deadlines sit inside the quality management duty rather than outside it. No provision states that one missed deadline is, on its own, an Article 16 breach, and nothing in the text settles that question yet.

Self-reporting is a factor the Regulation names, not just good practice

When a competent authority sets a fine within a tier, Article 99(7) lists the factors it weighs. One of them, Article 99(7)(h), is "the manner in which the infringement became known to the national competent authorities, in particular whether, and if so to what extent, the operator notified the infringement". An operator that files the Article 73 report itself, inside the deadline that applies to its incident, is building the record this factor rewards. An operator whose incident first surfaces through a regulator's own inquiry is not.

The SME and SMC caps both reach the Article 99(4) tier this page covers

Article 99(6) caps fines for SMEs, including start-ups, at "the percentages or amount referred to in paragraphs 3, 4 and 5, whichever thereof is lower", reaching the Article 99(4) tier this section is about. Article 99(6a) gives an SMC the same relief, stating that "each fine referred to in paragraphs 4 and 5 shall be up to the percentages or amount referred therein, whichever is lower". At the Article 99(4) tier itself, an SME and an SMC get the identical lower-of relief, though the SMC list omits paragraph 3 where the SME list includes it. Article 17(2) reinforces the same size-sensitivity one level up: it requires that implementation of the quality management system's aspects be proportionate to the size of the provider's organization, and it names SMEs, start-ups and SMCs.

How Pharos Production builds AI incident reporting pipelines

We build FinTech and insurance systems where the model sits inside a regulated product, and we treat incident reporting as a data path rather than a policy. The incident record carries the four classification fields as structured data, the deadline is computed from them on every change, and the report payload is assembled from that record rather than retyped into a form.

The test we apply is a cold clock read. Take an incident from six months ago, hand it to an engineer who was not on the call and ask which limb it fell into, when awareness was established, when the causal link was, which deadline applied and whether it was met. Our AI governance team works on that record alongside the build, because retrofitting a taxonomy after the first reportable event is expensive.

Sources: Regulation (EU) 2024/1689 (AI Act), base Official Journal text, Articles 3, 26, 72, 73, 74 and 79, via Regulation (EU) 2024/1689; Regulation (EU) 2026/1744 (Digital Omnibus on AI) of 8 July 2026, in force 27 July 2026, as the amending instrument for Articles 75, 111 and 113, via Regulation (EU) 2026/1744. Read on 25 August 2026. Provisions the Digital Omnibus replaced are quoted from the amending instrument, provisions it left alone from the base text. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: August 26, 2026

Quick answers on the penalty exposure behind AI Act serious incident reporting, including which tier applies and how it is reached.

Expand all Collapse all

Search FAQs

Popular

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

Showing all 6

• ★ Featured question. What penalty tier applies if a serious incident report itself contains false information?

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

  It depends on what happens next. Once a competent authority responds to the report and issues its own request, an incorrect, incomplete or misleading answer to that request falls squarely inside Article 99(5). That provision fines such an answer at "up to EUR 7 500 000 or, if the offender is an undertaking, up to 1 % of its total worldwide annual turnover for the preceding financial year, whichever is higher". Article 99(5) reaches information supplied "to notified bodies or national competent authorities in reply to a request", so an Article 73 report filed on the provider's own initiative does not trigger that tier by itself. A systemically defective reporting procedure instead lands one tier higher, at Article 99(4).

• Where does the AI Act define which companies count as SMCs for the Article 99(6a) cap?

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

  Article 3, point (14b), inserted by Regulation (EU) 2026/1744, defines the small mid-cap enterprise category, abbreviated SMC, that Article 99(6a) caps. That definition works by reference to point (2) of the Annex to Recommendation (EU) 2025/1099, so placing a company inside or outside the SMC category means checking that Annex, not just Article 3 alone.

  SMC is a separate category from the SME and start-up category that Article 99(6) covers, and the two categories get different scope of relief, so confirming which one a company falls into is a prerequisite to knowing which paragraphs its cap reaches.

• Does Article 74(6) reduce a bank's penalty exposure for its serious incident duty?

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

  No, and the two provisions do different jobs. Article 73(9) sets the scope, triggered for "providers that are subject to Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation". For those providers, "the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c)". Article 74(6) sets only the addressee for high-risk AI systems used by regulated financial institutions. It states that "the market surveillance authority for the purposes of this Regulation shall be the relevant national authority responsible for the financial supervision of those institutions under that legislation". That designation carries no scope narrowing at all. Article 17(4) is where the real constraint sits. It lets a financial-institution provider treat its quality management obligation as satisfied by existing internal governance, but "with the exception of paragraph 1, points (g), (h) and (i) of this Article". Point (i) is the Article 73 reporting procedure, so incident reporting is the one duty a bank cannot discharge that way, and the answer stays No.

• Does the two-day critical-infrastructure deadline carry a harsher fine tier than the fifteen-day general deadline?

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

  No. The Regulation does not scale the fine tier to the deadline that was missed. Article 99(4) is blind to which clock was missed, so a two-day failure and a fifteen-day failure sit no differently in the tier structure.

  What changes with the clock is operational risk, not the statutory ceiling.

• Should a company build one incident-classification pipeline or a separate one for each regulator it reports to?

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

  One. Classify each incident once, then route the finished classification to whichever external target applies, the AI Office, a national market surveillance authority or a sectoral regulator under Article 73(9).

  Duplicating the classification layer per regulator multiplies the chance that two of them see inconsistent facts about the same event.

• Should legal sign-off happen inside the incident runbook or as a separate gate before a report goes out?

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

  Keep classification inside the runbook as structured fields, because the two-day clock in Article 73(3) leaves no time for a full external review cycle once an engineer has already flagged a point (49)(b) event. Keep a lightweight legal sign-off gate immediately before external submission, scoped to confirming the report text rather than re-running the classification from scratch.

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.