Specialized work needs specialized tools. An editor that understands your domain — completing what can be written here, rejecting what cannot, and phrasing its errors in your vocabulary — is what turns a custom language from a specification into something people reach for every day.
A language is a promise about what can be said. The editor is how that promise is kept, keystroke by keystroke.Completion narrows what could come next down to what makes sense here. Validation rejects the rest before it ever runs, in words taken from your domain rather than from a stack trace. Without that, a domain-specific language is just a file format your experts have to memorise.
An editor for a custom language is not a text box with colors. It holds the same model of your domain that the language does, and it uses that model on every keystroke — which is what makes the difference between a tool people tolerate and a tool people ask for.
The editor proposes only what the language allows at this point in the document, using the terms your domain already uses. Nothing to memorise, no reference manual open beside the screen.
Rules are checked as the text is typed. The mistake is caught by the person who made it, seconds after making it, instead of surfacing in a batch that failed overnight.
A message names which rule was broken and where, in the language of the business. No parser jargon, no stack trace, nothing that needs a developer to interpret it before anyone can act.
Jump to where a concept is defined, list everywhere it is used, rename it everywhere at once. Because the editor works on the parsed model, these operations are exact rather than a hopeful text search.
We offer comprehensive solutions tailored to diverse domains. Which of these is right depends on who writes, what they write, and what has to be true about it afterwards.
Enhanced with syntax highlighting, autocomplete, refactoring tools and error detection: ideal for software development, scripting, configuration management and document editing. The text stays diffable and reviewable, so everything your team already does with source control keeps working.
Combining textual and graphical representations for maximum flexibility and precision, perfectly suited for domains requiring intricate interactions between visual and textual data, such as modeling languages, domain-specific languages and advanced engineering tasks.
Visually intuitive interfaces that simplify complex configurations, workflows and data visualizations, beneficial for business process modeling, system architecture design, graphical data management and workflow automation.
Most of what an editor knows — the grammar, the scope rules, the checks, the messages — does not depend on where it is displayed. Implemented behind the Language Server Protocol, that knowledge is written once and reused: the same language support can serve an IDE your developers already have and a browser editor for the people who will never install one. Choosing where your users work stops being a rewrite and becomes a decision about them.
The people who own the rules rarely own an IDE. If the editor cannot meet them where they already work, the language will be used by proxy — and a language used by proxy is a ticket queue with extra steps.
The same language, with and without a real editor around it.
An illustration of the pattern we keep meeting, not an account of one client’s project.
They open the file in a general-purpose text editor. Nothing highlights, nothing completes, nothing says a keyword is misspelled until something downstream fails. So they copy an existing rule and change the numbers, because copying is the only move that feels safe — and anything the copied rule does not already do stays permanently out of reach.
Every question about what the language allows comes back to them. The reference document goes out of date the week after it is written. The errors that reach production are, almost without exception, the ones a grammar would have caught in a millisecond.
Completion lists what is valid at the cursor, named the way they name it. A rule that breaks a constraint is underlined as they type, with a sentence saying which constraint and why. They start writing rules they have never written before, because the editor shows them what is possible instead of leaving them to guess.
The language definition is the documentation, because completion, validation and messages are all derived from it. The team spends its time extending the language rather than answering questions about it.
coverage "Home — Basic"
applies to buildings built after 1990
excess 250 EUR
limit 150 EUR
↳ limit must be greater than the excess (250 EUR)We put the editor where the work already happens: a desktop IDE, a web application of your own, or a panel inside a tool your users keep open all day. We use ANTLR, Langium and JetBrains MPS, together with our own open-source foundations — Starlasu and LionWeb, both Apache-2.0 — choosing per project rather than per habit.
What does your team actually do, and in what words?
We work closely with your team to understand your domain’s processes, terminology, rules and constraints, examining existing workflows and systems to find the pain points, the usability problems and the openings for improvement.
Which features earn their place in the interface?
We design the editor around usability, clarity and effectiveness, with iterative prototyping, user testing and refinement, so that every feature serves a clear purpose and the integrations fit the workflows you already have.
Does it still fit once real work runs through it?
We present prototypes and incremental updates throughout development to gather real user insight, so the editor stays attuned to your operational reality and adapts as your requirements evolve.
These are the decisions that fix what the editor can be, and they are much cheaper to make now than after the first prototype. We would rather ask them in the first meeting.
What we will not do is build an editor for a language that has not been designed yet. Completion has to have something to complete against; without a grammar there is a text box with syntax highlighting, which is not what any of this is for. If the language does not exist yet, designing it is the first piece of work and we will say so.
An editor is one half of the work. The other half is the language it is built for: see domain-specific languages, or the whole practice on languages, editors & business rules.
Bring the language you already have — or the spreadsheet standing in for one. We will tell you what an editor for it would have to do, where it would have to live, and whether the language has to be designed first.
