Vertical SaaS Is Winning in 2026: Should Engineers Learn Domain Expertise or Double Down on Tech?

General
1

I’ve been thinking a lot about where we’re headed in 2026, especially after last week’s board meeting where our investors asked pointed questions about our competitive moat. The answer kept coming back to one thing: domain expertise.

The Vertical SaaS Wave Is Real

The data is undeniable. Industry-specific SaaS tools are growing 2-3x faster than horizontal productivity platforms. In fintech alone (my world), vertical solutions raised more capital in 2025 than the previous three years combined.

But here’s what’s keeping me up at night: What does this mean for engineering careers?

The Dilemma We’re All Facing

At our company, we build payment orchestration tools for enterprise merchants. When I hire engineers, I’m increasingly looking for people who understand payment processing, not just people who can write great code.

Here’s a real example: Last quarter, a senior engineer proposed an elegant caching solution for transaction data. Technically brilliant. But it would have violated PCI-DSS compliance requirements in subtle ways that would have killed us during our next audit. Our payments specialist caught it immediately. The generalist engineer? Talented, but didn’t even know what PCI-DSS stood for.

The Technical Depth vs Domain Knowledge Question

Option 1: Double down on pure technical skills

  • Become exceptional at distributed systems, algorithms, performance optimization
  • Stay flexible across industries
  • Classic “software engineer” career path

Option 2: Layer on domain expertise

  • Learn payment networks, banking regulations, fraud patterns
  • Become indispensable in one vertical
  • Risk being pigeonholed if the industry shifts

What I’m Seeing in Practice

Our highest-performing engineers have both. They understand asynchronous message processing AND they understand why a payment authorization must complete within 3 seconds to avoid cart abandonment. They know Kubernetes AND they know merchant discount rates.

But building both takes time. And the market is moving fast.

From a product strategy lens, here’s what I know:

  • Vertical SaaS wins by owning outcomes, not features
  • Domain-aware AI delivers measurable ROI (we’ve seen this firsthand with fraud detection)
  • Customers pay premium for “they get my business” vs “they have good tech”

The Question for All of Us

If you’re an engineer in 2026, what’s the right career bet?

  • Stay technical-depth focused and remain adaptable?
  • Pick a vertical and go deep on domain expertise?
  • Try to do both (the “T-shaped” approach) and risk being mediocre at everything?

I’m especially curious about engineers who’ve made this choice already. What did you pick? What would you do differently?

For context, I came from product roles at Google and Airbnb (horizontal platforms), and now I’m at a vertical fintech startup. The difference in how engineering value is measured is stark. At Google, technical excellence was the currency. Here, technical excellence plus understanding merchant services is table stakes.

The real question: Is this just a fintech thing, or is this the new normal across all verticals in 2026?

Sources for the curious:

2

David, this hits close to home. In financial services, domain expertise isn’t just a “nice-to-have” – it’s the table stakes that determines whether your code ships or dies in compliance review.

The Financial Services Reality

I lead a team of 40+ engineers building banking infrastructure. Here’s what I’ve learned: The engineers who understand both the technology AND the regulatory landscape move 2x faster than pure generalists.

Your PCI-DSS example is spot-on. But it goes deeper. Last year, we built a new real-time payment processing system. The engineers who understood the Federal Reserve’s FedNow requirements, the difference between ACH and wire transfers, and the reconciliation patterns that banks expect? They designed the right abstractions from day one.

The engineers who came in with pure distributed systems knowledge? Brilliant people. But they kept building solutions that looked great on paper but couldn’t pass SOC 2 audits or violated banking regulations we didn’t even know to tell them about.

But Here’s My Counter-Argument

You cannot build domain expertise on top of weak technical fundamentals. I’ve seen that fail too.

We hired a payments domain expert who came from the business side and did a coding bootcamp. They understood merchant acquiring better than anyone on the team. But when it came to debugging race conditions in our transaction processing pipeline or optimizing database queries for regulatory reporting, they were lost.

The T-Shaped Model Is Real

I’m a big believer in the T-shaped engineer:

  • Horizontal bar: Solid technical foundation (distributed systems, databases, security, testing)
  • Vertical bar: Deep domain expertise in one area (for us, financial services compliance and payment networks)

The best engineers I’ve hired spent 3-5 years building strong technical skills across different domains, THEN specialized. They have the engineering fundamentals to evaluate trade-offs and the domain knowledge to know which trade-offs matter.

The Career Path I Recommend

For engineers early in their career: Build technical breadth first. You need to understand data structures, system design, debugging, testing, and security fundamentals before you can effectively apply them to a domain.

For mid-career engineers: Pick a vertical that aligns with your interests and has strong market growth. In 2026, regulated industries (fintech, healthcare, legal tech) have the strongest moats and the highest demand for domain expertise.

For senior engineers: Your domain expertise becomes increasingly valuable. The engineer who can architect a compliant payment processing system while navigating PCI-DSS, SOC 2, and state money transmitter regulations? That person is worth their weight in gold.

To Answer Your Question

This isn’t just a fintech thing. I see it everywhere:

  • Healthcare: HIPAA compliance + technical skills
  • Legal tech: Understanding legal workflows + engineering
  • PropTech: Real estate regulations + software development

The new normal is: technical excellence plus domain fluency. The question isn’t whether to specialize, but when and how deeply.

What I tell the engineers I mentor: Don’t specialize too early. But don’t wait too long either. The sweet spot is 3-5 years of broad technical experience, then pick a vertical you’re genuinely curious about.

3

Oh wow, this conversation is giving me flashbacks to my startup days – and not the good kind :sweat_smile:

My Expensive Domain Expertise Lesson

So, storytime. Back in 2022, I co-founded a healthcare scheduling SaaS for specialty clinics. Our team? Two amazing engineers (me included from the design side), one growth marketer, and a ton of ambition.

We built beautiful, elegant software. Our React component library was chef’s kiss. The UX was intuitive. We shipped fast.

We failed spectacularly.

Not because the tech was bad. We failed because none of us understood healthcare workflows deeply enough. We didn’t know that:

  • Different specialties have wildly different scheduling patterns
  • Insurance pre-authorization workflows dictate scheduling windows
  • HIPAA isn’t just “encrypt the data” – it’s embedded in every patient communication touchpoint
  • Medical assistants (our primary users) needed phone-first workflows, not web-first

We kept building features based on what we thought made sense. Our customers kept saying “this doesn’t work how we work.” By the time we finally hired a domain expert (former practice manager), we’d built the wrong product.

Domain Expertise Reveals What to Build

Luis is absolutely right about technical fundamentals. But here’s what I learned: domain expertise tells you what to build. Technical skills tell you how to build it.

We had the “how” down cold. We had no idea about the “what.”

If even one person on our founding team had worked in a medical office, we would have:

  • Built phone integrations first, not web dashboards
  • Understood insurance workflow complexity from day one
  • Designed for HIPAA compliance patterns, not bolted them on later
  • Actually talked to medical assistants instead of assuming we knew their needs

The T-Shaped Approach Makes Sense… But How Do You Get There?

I love the T-shaped model Luis described. But here’s my question: How do you develop domain expertise without going all-in on a vertical?

Some ideas I’m exploring now:

  • Side projects in target verticals – I’m building an accessibility audit tool for healthcare (learning domain while building)
  • Customer embedding – Spending time in-person with users in their environment
  • Domain-adjacent communities – Joining healthcare design communities, reading industry publications
  • Micro-consulting – Small domain-specific projects before committing

My Current Take

After the healthcare startup shutdown, I’m now leading design systems work (horizontal role) while building vertical expertise in accessibility + healthcare through side projects.

It’s slower than going full-time into a vertical. But it lets me:

  • Keep earning while I learn the domain
  • Test if I’m actually passionate about healthcare (vs just thinking it’s a good market)
  • Build network and credibility before job-searching in the vertical

The real risk isn’t picking a vertical too late. It’s picking the wrong vertical too early and having to start over.

To David’s original question: This is absolutely not just a fintech thing. Every vertical I look at (healthcare, legal, construction, education) rewards domain expertise + technical skills.

The question that keeps me up: How do you know which vertical to bet on?

Market growth? Personal passion? Existing network? All of the above?

4

Maya, your healthcare story is a perfect example of why timing matters so much in this decision. And David, your question gets at something I’ve been thinking about a lot as we scale our EdTech engineering team.

The EdTech Parallel

In education technology, I see the exact same pattern. Engineers who understand pedagogy, classroom dynamics, and student data privacy requirements ship better products than pure generalists.

Real example from last month: We were building a new assessment feature. An engineer who came to us from a teaching background caught a UX issue that our QA team missed entirely. The flow we designed would have required students to navigate away from their work to submit – something that seems minor until you understand that middle schoolers will just… close the browser and assume it’s saved.

A teacher-turned-engineer knows that. A pure software engineer might not think about it.

But Here’s the Reality Check

Domain expertise commands a significant salary premium. And Maya’s question about “which vertical” is critical because the financial stakes are real:

  • AI/ML specialists: $170K-$250K for senior roles
  • Cybersecurity engineers: $135K-$150K+
  • General full-stack engineers: $70K-$94K (up to $117K for top performers)

That’s not a 20% difference. That’s 2x or more.

So when you’re choosing a vertical, you’re making a major financial bet. Pick the wrong one? You might need to start over, and those years of domain expertise don’t necessarily transfer.

The Path I Recommend

Don’t specialize before 2-3 years of solid engineering experience.

You need fundamentals first:

  • Data structures and algorithms
  • System design and architecture
  • Debugging and troubleshooting
  • Testing and code quality
  • Basic security principles

I’ve seen engineers go straight into healthcare tech or fintech without these foundations. When complex technical problems arise (distributed systems bugs, performance issues, security vulnerabilities), they struggle. Domain knowledge can’t compensate for weak technical fundamentals.

But Also Don’t Wait Too Long

By year 4-5, you should be developing a vertical focus. Why?

  1. Career acceleration: Domain experts get promoted faster in vertical SaaS companies
  2. Network effects: Your domain expertise compounds – you build relationships, reputation, and insights over time
  3. Market dynamics: In 2026, vertical SaaS companies are where the growth and funding is

How to Choose Your Vertical

Maya asked the right question. Here’s my framework:

Green flags:

  • Regulated industry (healthcare, finance, legal) = high barriers to entry
  • You have genuine curiosity or personal connection to the problem space
  • Strong market growth and venture funding
  • Complex workflows that resist commoditization

Red flags:

  • Choosing purely based on salary (you’ll burn out)
  • Industries in decline or heavy disruption
  • Verticals where low-code tools can replace specialists
  • Markets you can’t get access to (no network, no way to learn)

For Different Career Stages

Junior engineers (0-3 years): Build technical breadth. Work at a company with diverse technical challenges. Learn fundamentals deeply.

Mid-level engineers (3-7 years): This is your window. Pick a vertical that aligns with your interests and has strong market dynamics. Start building domain expertise intentionally.

Senior+ engineers (7+ years): Your domain expertise is now a major career asset. You can speak the customer’s language, design domain-appropriate architectures, and move faster than generalists.

To Answer David’s Original Question

Yes, this is the new normal in 2026. Vertical SaaS is winning because domain expertise is the moat that AI and low-code tools can’t easily cross.

The career bet: T-shaped is the answer. Solid technical foundation (3-5 years building) + deep domain expertise in a growing vertical.

Just don’t pick your vertical at random. And definitely don’t specialize before you have the technical fundamentals to make good engineering decisions.

5

This discussion is hitting on something I’ve been thinking about at the executive level: how vertical SaaS is fundamentally changing what we value in engineering talent.

The Market Signal Is Loud

Let me share what I’m seeing from the CTO seat. When we posted a senior engineering role last month for our compliance automation platform, we got 200+ applications. The candidates fell into clear buckets:

Bucket 1: Strong general engineering background, no domain knowledge

  • Impressive resumes (FAANG experience, strong technical skills)
  • Could probably learn our domain
  • Would take 6-12 months to become productive

Bucket 2: Domain expertise, weak engineering fundamentals

  • Understood compliance workflows deeply
  • Struggled with system design questions
  • Would hit ceiling quickly on technical complexity

Bucket 3: T-shaped engineers (technical fundamentals + domain knowledge)

  • Smaller pool (maybe 15 candidates)
  • Could contribute immediately AND grow technically
  • These are who we hired. And we paid premium.

The Financial Reality

Keisha mentioned salary differences. Let me add the employer perspective: Companies are willing to pay 30-50% more for engineers with relevant domain expertise.

Why? Time to value.

A generalist engineer might take a year to understand our compliance domain well enough to make good architectural decisions. A domain expert who also has solid technical skills? Productive in weeks, not months.

When you’re a vertical SaaS company competing on domain expertise, that time difference is existential.

But Here’s My Advice: Choose Wisely

Maya asked how to pick a vertical. As someone who’s been in tech for 25 years, here’s what I’ve learned:

Pick a domain you’re genuinely curious about, not just one that pays well.

I’ve seen too many engineers chase high-paying verticals (crypto in 2021, AI/ML in 2024, fintech in 2026) without genuine interest. They burn out or become mediocre domain experts because they’re not naturally curious.

The engineers who thrive in vertical SaaS are the ones who enjoy learning about payment processing nuances or healthcare workflows or legal documentation patterns. Not because they have to, but because they find it genuinely interesting.

The Long-Term Compounding Effect

Here’s what people underestimate: domain expertise compounds over decades.

A fintech engineer who deeply understands payment networks in 2026 will:

  • Build a professional network in that vertical
  • Develop pattern recognition for domain-specific problems
  • Gain reputation and credibility
  • Have insight into where the industry is heading

By 2036, that person could be the CTO of a fintech company, or a founder who understands both the technical and business sides deeply.

Compare that to a pure generalist who changes domains every 3-4 years. They might have broader experience, but they lack the deep network and compound insights that come from long-term focus.

Market Dynamics Favor Verticals

David’s original question was whether this is the new normal. From my vantage point: Yes, absolutely.

The data I’m seeing:

  • Vertical SaaS startups raised more VC funding than horizontal platforms in 2025
  • Our industry-specific solutions have 3x higher retention than our general tools did
  • Customer acquisition cost is lower when you speak their language (domain expertise)
  • AI is making horizontal tools more commoditized, but domain-specific AI still requires domain expertise to build

For Engineering Careers

My framework for engineers at different stages:

Years 0-3: Build technical fundamentals. You need this foundation. Don’t specialize yet.

Years 3-5: Start exploring verticals. Do side projects, take contract work, talk to people in different industries. Find what genuinely interests you.

Years 5-10: Commit to a vertical. Build deep expertise. This is your career bet.

Years 10+: You’re now a domain expert with technical credibility. This opens paths to senior engineering leadership, founding startups in your vertical, or consulting.

The Ultimate Question

To David’s point about whether T-shaped engineers risk being “mediocre at everything” – I don’t think so.

The key is sequence:

  1. Build strong technical fundamentals FIRST (3-5 years)
  2. THEN layer on domain expertise (next 5-10 years)
  3. The combination makes you exceptional, not mediocre

What makes engineers mediocre is trying to specialize before they have fundamentals, or having great fundamentals but refusing to learn any domain deeply.

In 2026, the winning bet is clear: technical excellence + domain expertise. Not either/or.

The engineers I’m hiring, the ones getting promoted to Staff+ levels, the ones starting successful vertical SaaS companies – they all have both.

Pick a domain you care about. Learn it deeply. The market will reward you.