Frozen Peak Solutions

The idea

One platform for structural design

Structural design often moves between programs: a building is modelled in one, analysed in another, checked in a third and drawn again for fabrication, and each step enters the same elements once more. The Structural Suite keeps each element once, in one project model, and gives every product the same model, the same libraries and the same kind of interface for people and for programs.

Six promises

What the suite is built to do

Each promise is part of the architecture from the first line of code, so every new product fits the whole. The Today page shows what exists of each on 15 October 2026.

  • One model for every task

    Analysis, design, cross-sections, BIM modelling, bridges and infrastructure, drafting, computational design and timber-frame buildings share one project model. Each element exists once; the analysis model, drawings, schedules and IFC are derived from it, so nothing is entered twice.

  • Programs use it as people do

    Every action is an operation with a typed request. From one definition per product, the suite generates the C API, the command-line program with its server for AI agents over the Model Context Protocol, and packages for C#, Python, TypeScript, Rust and Excel VBA, so a script, a spreadsheet or another program can do whatever the desktop program does. Services add a gRPC network API.

  • Open to extension

    Parametric components, script components and plugins built with an SDK add element types, joints, checks and whole workflows without waiting for a release. A visual programming graph reaches every library and product of the suite.

  • Connected to the rest of your toolchain

    IFC 2x3, IFC 4 and IFC 4.3, STEP, DXF and DWG, the Structural Analysis Format, STL, OBJ, 3MF and XLSX. Project files are compact binary files that also save losslessly as JSON, for review and version control.

  • Results you can check

    Every design-code clause is cited in the source and the documentation, and every result is verified against hand calculations, worked examples and published benchmarks. Eurocodes with the recommended values and the Finnish national annexes, for buildings, bridges and infrastructure.

  • Fast, local and yours

    Native C++ that runs on your own machine, offline, on Windows and Linux, with performance budgets that benchmarks enforce. Open source with documented file formats, so your models stay yours.

How it fits together

Four layers, each with one job

Each layer uses only the layers below it, and the work that two products share lives in a library, so what one product gains, the others that use the same library gain too.

  1. People, scripts, programs and AI agents

    Each finds the product through the interface that suits it, and every interface reaches the same operations.

    • Desktop program
    • Command line
    • C API and language packages
    • Server for AI agents

  2. Operations

    Every action is an operation with a typed request and a typed result, described once per product. The C API, the command line, the server for AI agents and, when users need them, the packages for C#, Python, TypeScript, Rust and Excel VBA are generated from that description, so none of them can lack what another has. The desktop program calls the same operations, so undo, scripting and batches work alike for people and programs.

  3. One project model

    Each element exists once. The analysis model, the drawings, the schedules and the exchange files are derived from it, and a value that only the analysis uses is stored as an override, never as an edit of a derived view.

    • Analysis model
    • Drawings and schedules
    • IFC and other exchange files

  4. Shared libraries

    Units, geometry, finite elements, the Eurocodes, sections, materials, reports and file formats, each owned by exactly one library. A fix or a new rule in a library reaches every product that uses it. 50 libraries are built today.

How it is built

Finished parts, checked results

  • Finished before it ships

    A feature is implemented, tested and documented before it ships, with every option and case of the rule it covers. A large task is split into complete steps, never cut down.

  • Checked against references

    Each design rule cites its clause, and each result is compared with hand calculations, the standards' worked examples and published benchmarks, rebuilt from their original sources.

  • Fast by budget

    Each product states budgets for the work its users wait for, and benchmarks check them. A change that makes a measured task slower is fixed before it is merged.

  • Open source when released

    Each product is published as open source when it is released. Its third-party code is permissively licensed, apart from system libraries that are never shipped, so every licensing option stays open.

The Coming page lists every feature of the plan, release by release, and the home page lists the eleven engineering principles behind all of it.