We build domain-specific languages, editors, parsers, validators and rule engines so specialists can express knowledge precisely—and systems can execute it consistently, without a developer translating every change.
We have created languages and rule-based tools for medical, tax, financial and engineering domains. The foundations are open source: Starlasu and LionWeb, Apache-2.0 and public, so nothing here holds your work hostage.
A language, an editor and a validator put those rules back in the hands of the people who own them—and let a machine check them.
Four parts of the same machine. Most projects need two or three of them; which ones depends on where your domain knowledge is stuck today, not on a technology preference of ours.
A domain-specific language covers what actually varies in your domain and nothing else. The rules stop being buried in an implementation and become something you can read, review, diff and version—in the vocabulary your experts already use.
A language is only as useful as the place you write it. We build the editor around it: syntax support, validation as you type, autocompletion in domain terms, and errors phrased the way a specialist would phrase them. As a web tool, a desktop application or a plugin for the IDE your team already uses.
Rate tables, eligibility criteria, pricing logic, compliance checks: written once, in a form the business owns and the system runs. There is no second copy inside the application to drift out of step with the first.
Behind a language sits a model of your domain. From that model we generate code, configuration, documentation and tests deterministically—so the artefacts stay consistent with each other, and with the rules, by construction.
The language and the tool it is written in are designed together, but they are different pieces of work. Start with whichever is closer to your problem.
By creating languages tailored to your needs we bridge the gap between domain experts and developers: less complexity, fewer rounds of translation, faster time to market. We design the language around what actually varies, then build the validator and the generators that turn it into running code.
Specialized tasks need specialized tools. We craft editors that fit into the workflow instead of interrupting it, so a team can write, check and refine what it produces without leaving the context—with context-aware support for the domain, not generic text editing.
We have created languages and rule-based tools for medical, tax, financial and engineering domains. What they have in common is not an industry. It is that the rules are numerous, they keep changing, the people who own them are not developers—and almost right is worth nothing.
rule "Reduced VAT on medical devices"
when
invoice.line.category is medical-device
and buyer.country in EU
and buyer has valid exemption-certificate
then
apply vat-rate 4%
require attachment "exemption certificate"Protocols, dosages and eligibility criteria that must be exactly right.
A notation clinicians can read, and a validator that refuses what the protocol does not allow.
Rates, thresholds and exemptions that change by jurisdiction and by year.
Rules versioned the way the law is, executed the way software is, and testable against last year’s cases.
Pricing, limits and compliance logic spread across systems and spreadsheets.
One place where the logic is written, and generators that keep every system in step with it.
Configurations and constraints that only a handful of specialists fully understand.
The constraints written down as a model, so an invalid configuration cannot be expressed in the first place.
A custom language is a long-term commitment, so the machinery underneath it should not be something only we can maintain. Ours is open source and public: Starlasu, our libraries for parsers, syntax trees and transpilers, and LionWeb, the open initiative for making language tools interoperable, which we help develop.
That means no proprietary intermediate representation, no format only our tooling can read, and no reason you could not take the work to another supplier—or bring it in-house. It is also why we can start from something battle-tested instead of from scratch.
Parsers, transpilers and language engines have been our own product line since 2015, across 70+ clients in 20+ countries — not a side effect of consulting. The part of this work that decides whether a language lasts is keeping it narrow: the value of a DSL comes from what it refuses to express, and a domain grows faster than a language should. That is the discipline these three pages are about.
LLMs have changed what a language like this is worth: a small, checkable notation turns out to be a far better target for a model than a general-purpose language, and the validator that comes with it can reject what the model gets wrong. We set out that argument in full on the domain-specific languages page.
You can also read what our clients say in the case studies and the testimonials.
Tell us about the domain you are trying to tame—the rules, the specialists, the change that keeps queueing behind a sprint. We will tell you honestly whether a language, an editor, or neither is the right answer for it.
