About

Deep Domain Problems: Beyond Surface-Level Solutions

I'm Rajiv, co-founder of Betalectic. Ten years ago, I started with a simple thought: "If I don't have any ideas, let's help others make their ideas happen."

As my team worked on problems across different industries, we needed to group them. I got some ideas from domain-driven design (DDD) and started calling these "Deep Domain Problems" (DDP).

The question that got me thinking about this was: "What problems should we work on next?"

In the last 15 years, I've seen how dealing with businesses has changed. Now, there's an app for pretty much everything, which makes me proud as an Indian to be part of this wave of problem-solving. With our vast population, India has been in a special spot during these changes. I think of these as consumer experience problems (B2C), and we've solved tons of them. For business owners, we've seen big improvements in business software, with new solutions every day.

When you look closely at these solutions, you often see they're just new layers built on top of old systems—which isn't necessarily bad. Building something on top is more straightforward than understanding all the complex stuff underneath.

There are a few ways to tackle the deep - more profound problems:

  1. Discard existing processes and start fresh—typically impractical
  2. Invest time in understanding how systems work and their interdependencies—these complex systems power our financial infrastructure, supply chains, and industries, requiring decades to comprehend fully
  3. Collaborate extensively with domain experts—this is what I think works best.

Solving Deep Domain Problems doesn't involve tearing everything down. Instead, it consists in improving things step by step. This approach works best when industry veterans collaborate with tech people who want to build lasting products.

Here's what I want to do with deepdomainproblems.com:

  1. Support for Deep Domain Problem Solvers: These experts have invested decades in understanding industry intricacies, regulations, and practical operations. They need architects and domain modelers beyond typical app developers. Just as domain expertise develops over time, so does programming wisdom.

  2. Connection to Deep-Problem Programmers: First-world countries have staff engineers who continue coding after 25+ years rather than moving into management because they love solving complex problems. Connecting them with DDPs could significantly improve solutions at India's scale. This requires a commitment to domains rather than changing fields frequently for salary increases.

  3. Funding for Deep Work: Daily demands may limit flexibility to commit to a single domain. Solving DDPs resembles R&D—it needs funding for experimentation, scaling, and influence, plus sufficient incentives to encourage participation.

  4. Documentation of Methodologies: We must interview successful problem-solvers and document approaches for tackling DDPs, recognizing that solutions aren't one-size-fits-all.

I want "DDP" to become something everyone knows, like how people know what "SaaS" is. Then, when we see a problem, we can say, "Look, that's a Deep Domain Problem," and know how to tackle it properly.