We fund ourselves through customer projects. We work with two kinds of customers: those that face some sort of a challenge with a legacy system, and those that seek a competitive advantage.
On the one side of the spectrum, we work with teams having to deal with large legacy systems that are considered difficult (and often impossible) to move forward. Typical problems take the shape of either strategic assessments, or of steering agile architecture. A strategic assessment is required when the team faces a broad decision, such as migrating to a new technology, adopting a new architecture, or evaluating the path to perform a crosscutting change. The steering agile architecture scenarios relate to teams that want to internalize the ability of making informed architectural decisions and evolving the system in a piecemeal fashion. The two often co-exist: a strategic assessment is often complemented by the need of steering the technical work to reach the goal.
On the other side of the spectrum, we work with startups to help them innovate faster. We do this by materializing the domain in code that acts like executable specifications in that it is visualized in a way that non-technical people can evaluate.
While these problems are typically considered radically different, we approach them uniformly. For all these projects we use exclusively the same tools and technique we create. There are two reasons for it. First, we believe our tools and techniques provide unique abilities. Second, applying the same tools and techniques to a broad range of real-life scenarios provide empirical evidence supporting the generality of our research.