Answering this question requires a bit more discussions and work than I can write on this page. One of the first steps of any project is to investigate exactly this question. But here are some considerations that we will would explore together if you are interested. I detail them below.
The most important consideration is this: you should only develop custom tools and languages for that part of your software that is unique to your business, that drives your unique position in the market. It is crucial that your tools are as effective as they can be for this part of your software. Everything else should be treated as commodities, and you should rely on off-the-shelf tools and frameworks. To make this concrete: unless you are Amazon or Netflix, then computing infrastructure, deployment tools and databases are not something you want to develop specifically for company. However, if your USP is algorithms for digital therapeutics, then a domain specific language that helps you express this algorithms as effectively as possible is a great investment (see chapter 6 in this paper).
A Suitable Domain
Richness and VarietyIs the domain suitably deep, does it have enough intricacies and variety? Is it timeless to some degree? Are there people who are experts in the domain, who have spent half a life understanding it? Is there a rich vocabulary and specific notations? Would non-trivial analyses be helpful to users?
Boilerplate and FanoutSome software platforms require a lot of boilerplate code to use them correctly. In other cases, lots of derived artifacts — such as documentation, design diagrams or coverage reports — are necessary to comply with a particular process. Both cases are excellent opportunities to describe things once, at a suitable level of abstraction, and then automatically generate code and documents.
Platform IndependenceAnother driver for DSLs (and code generation) is the need to run the same domain logic on different platforms. Either in parallel (e.g., server and phone) or over time (e.g., your systems' functionalities lives longer than the technology of the day), and you don't want to reverse-engineer things over and over again.
A Suitable Business Model
A Medium-term OutlookA DSL is not rocket science, but it is an asset that will pay itself back over time. How long the amortization takes depends primarily on the increase in efficiency you gain from using the DSL vs. the investment for its development. But if your business focuses only on the current quarter then it's hard to make it work.
Benefit from EffectivityIf you are a solution provider and sell time, people or effort, then an increased effectiveness of your development effort might not be terribly useful. If you sell products and want to release on a shorter cycle, or if you develop systems internally and want to accelerate your business agility, a DSL might be a great investment.
A Degree of SamenessLike a framework or a library, a DSL embodies a set of abstractions that you use all the time in your work: if each of your products or projects is in a different domain, it is harder to justify the development of a language for that domain — and you might also not have the deep experience. In contrast, if you develop digital therapeutics apps, satellites or payroll software all the time, then investing into making this more efficient is great!
A Suitable Organization
Technical MaturityDeveloping a DSL (and using it at the same time) requires a certain maturity in your internal development process: you'll have to manage the requirements for the language, develop it incrementally, ensure quality and regularly release it to your users. If you and your teams struggle with build automation or unit testing, developing a DSL might be a jump too far. On the other hand, if you have done plaform- or framework-based development in the past, a DSL is a logical next step.
Willingness and Ability to ChangeA DSL moves the "threshold of formlization" earlier in the development process. This is likely a significant change in the process. It requires people to change, to learn new skills and to go through some temporary period of reduced productivity as they learn the new approach. The technical developers have to learn how to develop languages and gnerators, both skills that are not too widespread. Everybody needs to be on board to harvest the benefits of the approach.
... or continue Reading:
How to adopt a DSL?