The questions an engineer asks
before signing anything.

The tool produces the analysis model, the EN 1993 verification, the calculation report and the drawings. Your own licensed engineers review that package and sign it.

What DTJ is responsible for is the software doing its automation job correctly. That is tested, the testing is documented, and DTJ gives you the documentation on request.

You keep the responsibility you already have and you lose the manual weeks.

The software was built and used on live projects with real delivery dates. Every number quoted on this site comes from that work, not from an estimate.

Client names stay unpublished because that work is confidential, and your work gets the same treatment. What DTJ can show you instead is the real output, on a structure like the ones your office builds.

Every run hands over the complete chain: analysis model, EN 1993 verification, full calculation report, AutoCAD drawings, plus a full set of supporting documents and checks.

Nothing is hidden behind a result. Your engineers can open the model and the supporting documents, follow any load, any combination and any check, and see exactly what a person would have written by hand.

The variation is real, but it usually sits in the details, not in the way the structure is put together. Finding that pattern is the work DTJ does before any software gets written.

That is why the software is built around the parameters that drive a whole class of structure instead of around one finished design, and why the software is set up to your standards and your details. What comes out is your structure the way your office builds it. The structures in the Structures section are examples of what the software covers today, not a boundary.

Actions come from EN 1991, combinations from EN 1990 and the steel verification from EN 1993, each to the national annex of the country you build in. That is what the software has run in production, on real structures.

AISC, IS and AS are roadmap and are not built yet. A new code gets written into a contract when a customer needs one, and adding a code extends the software instead of rebuilding it.

The automation is not tied to any one package. Any solver or CAD program with a programmable interface can be driven the same way, and adding one means writing a single new driver, not a new product.

Today the automation runs analysis in SAP2000 through the OAPI, and drawings come out of AutoCAD as native files your team opens and edits.

Your SAP2000 and AutoCAD licences stay yours and your software stays where it is. Your engineers work in the DTJ interface, and a small DTJ agent on the same machine drives SAP2000 and AutoCAD inside the licences you already pay for. Tell DTJ what your office uses and you get a straight answer on what adding that package takes.

A general tool like SAP2000 still needs an engineer to build the model, apply the loads, run the checks, read the results and draw the outcome. DTJ automates that whole loop for the structures your office builds by hand again and again.

What you buy is the automation, and the engineering judgement built into it.

Speed, because the loop closes in hours instead of weeks. Consistency, because the same input gives the same output every time, and the check that gets rushed at the end of a long week does not get rushed. Capacity, because the same engineers cover more projects without a single new hire.

Tell DTJ which structures your office repeats most and what those structures cost you in hours today. You get an honest answer on whether automation is worth it at all, including when the answer is no.

If it is worth it, the next step is a study of how your office builds those structures. Your engineers and DTJ work through them together: what repeats, what changes every time, what your standards demand, and what the output has to look like to be useful on your desk. Your engineers know the work and DTJ knows what can be automated, and the answer only exists where the two meet.

At the end of the study you know what the automation would cover, what it would do for your office and what building it costs. The build is agreed from there, before any work starts, and once the software is running, annual maintenance keeps it updated.

Everything the software produces for your projects is yours: the models, the reports and the drawings. You keep them and issue them like any other work your office produces.

What stays with DTJ is the software itself and DTJ's own methods inside it. Your standards and your details stay confidential and are never built into anyone else's software.

Parameters go up. Instructions for building the model come back down, your own software builds the model on your own machine, the results go back up, and the finished documents come down. After delivery nothing is left on DTJ servers.

Your analysis model stays on your machine. Your CAD files and your project folders are never read and never uploaded.

DTJ servers are in the EU, encrypted in transit and at rest. What stays afterwards is the metadata: the date, your project reference and the number of runs. Never the engineering itself. Your work is never used to train anything and is never shown to anyone.

Your engineers use the software themselves and set every input and parameter a project needs. What they do not change is the software itself.

Updating the software is DTJ's job, and your annual maintenance covers those updates. When a national annex changes, when SAP2000 or AutoCAD releases a new version, when something needs correcting, DTJ updates the software and your engineers keep working.

DTJ prices one thing separately: new engineering. A structure type your DTJ licence does not cover yet, or a country and national annex outside your DTJ licence, is new work and gets its own quotation. Everything else is covered by the annual maintenance.