Skip to content

Resources

HÄLYTIN: the weekend build of an app the state scheduled for 2027

The weekend did not compress the code. It compressed the drafting upstream of it: the specification, threat model, DPIA structure, and audit trail. That half of a public schedule no longer costs years. Procurement and accreditation still do.

In late March 2026, Yle reported that a national drone alert would reach Finnish phones in 2027. The project behind it, the Ministry of the Interior's SIREN, had been set up that same month, on a schedule running to December 2027: nearly two years from announcement to delivery. In April, over one weekend, Taiga's AI software factory produced HÄLYTIN, a reference implementation package for the same app. We offered it to the state pro bono and said so in an April 15 press release. Maaseudun Tulevaisuus picked the story up, and the framing wrote itself: nearly two years planned for the state, one weekend for a startup. The contrast is real. It is also the least interesting part of the story.

What we built, and what we did not

HÄLYTIN is a reference implementation package. It is not a deployed national system. It holds no citizen data, connects to no authority systems, and carries no claim that the state's project can skip the work still ahead of it.

What it does carry is what a public buyer needs to evaluate it: the specification, the threat model, a pre-filled DPIA structure for the controller to complete, the architecture with its recorded decisions, the test evidence, and the audit trail that ties every decision and approval to the code it produced. Every factory run delivers the same standard set: nine artifacts from specification through DPIA, measured against our published 22-check bar. HÄLYTIN got no special treatment. It got the standard treatment.

We offered it pro bono, as a reference point: this is what one weekend now produces when the whole delivery is governed. The state is free to use it, audit it, or discard it.

The time was never in the code

In April 2026, a16z's Kimberly Tan argued that code is upstream of every other application, because code is the building block of all software. Half right. In a ministry, or in any regulated buyer, code is not the upstream layer. Upstream of code sit the specification, the security review, the privacy assessment, the architecture decisions, the documentation, and the procurement that ties them together. That is where public schedules live. Nobody plans two years of typing.

Fast code generation on its own does not touch that layer. It does not even produce code you can trust unattended. In DryRun Security's March 2026 study, 26 of 30 AI-agent pull requests (87%) introduced at least one vulnerability. Veracode's 2025 testing found AI-generated code introduced a security flaw in 45% of tasks. Compress only the build and you get a clever weekend. Compress what sits upstream of the build and the same weekend produces something a regulator could question, line by line, with the paperwork to question it against.

Most of HÄLYTIN's weekend went into the artifacts around the code.

Slow by design, fast by comparison

The factory that built HÄLYTIN is deliberately slow. A run takes hours, sometimes days, because the factory does not start with code. It starts with questions. You do not prompt the factory. The factory prompts you: what data the app touches, what happens when the network fails, who is accountable for a false alarm. A public buyer has to answer those questions sooner or later. The factory asks them first, records the answers, and builds against them.

So the weekend cuts both ways. It is slow for a demo, since anyone can generate an app that looks like HÄLYTIN in an afternoon. It is fast for a delivery that arrives with a threat model and a DPIA structure attached. How the factory works covers the mechanics in detail.

What compressed, and what did not

Honesty about the weekend requires a boundary. What compressed was the drafting: the specification, the threat model, the DPIA structure, the architecture decisions, the tests. What did not compress is everything that turns a package into a national system: procurement, security accreditation, the controller's own privacy assessment, integration with the existing emergency infrastructure, and accountability for a false alarm at national scale. None of that fits in a weekend, and HÄLYTIN claims none of it. The claim is narrower: the drafting half of a public schedule no longer costs what it used to.

What this means for public timelines

The December 2027 date was not set by careless people. It was sized under an assumption that held for decades: specifying, governing, documenting, and building a public system takes years, in sequence, each step waiting on the last. The building half of that assumption broke first, and everyone noticed. The upstream half is breaking now, and fewer have noticed, because it breaks quietly, in paperwork.

Estimates should match the current cost of the work. When a reference implementation arrives over a weekend with its governance drafts attached, the question is not whether the state should have hurried. The question is what the remaining year and a half is for.

Which line on your 2027 roadmap still assumes the upstream half takes a year?

Sources

Frequently asked questions

What is HÄLYTIN?+

HÄLYTIN is a reference implementation package for Finland's planned national drone-alert app, produced by Taiga's AI software factory over one weekend in April 2026 and offered to the Finnish state pro bono. It includes working code together with the specification, threat model, DPIA structure, architecture record, and audit trail.

Did the Finnish government use Taiga's drone-alert app?+

No. HÄLYTIN was offered as a pro bono reference implementation. It is not a deployed national system, and the Ministry of the Interior's SIREN project continues on its own schedule toward December 2027.

How was HÄLYTIN built in one weekend?+

By compressing the work upstream of code. The factory produced the specification, threat model, DPIA structure, architecture decisions, and audit trail in the same governed run that produced the code. The documentation, more than the code, is what makes the package something a public buyer can evaluate.

Why does government software take years to deliver?+

Most of the calendar sits upstream of the build. Specification, procurement, security and privacy review, and documentation run in sequence, each step waiting on the last. In our experience the build is the shorter half, and the upstream half is only now becoming compressible.

Is AI-generated code safe enough for government systems?+

Raw output is not. Veracode's 2025 testing found AI-generated code introduced a security flaw in 45% of tasks, and in DryRun Security's March 2026 study 26 of 30 AI-agent pull requests introduced at least one vulnerability. It becomes usable when generation is one step inside a gated process with a published readiness bar, human review, and a full audit trail.

The 22 checks are published. The self-test runs against them in your browser.

Bring the project this article made you think about.