DEV Community: Darun Karas Abir

The Model Is Becoming a Commodity. The Workflow Is Becoming the Product.

Darun Karas Abir — Tue, 18 Aug 2026 10:24:43 +0000

A year ago, building an AI product often started with a simple question:

Which model should I use?

GPT or Claude?
OpenAI or Anthropic?
A local model or an API?

Today, that question is becoming less interesting.

New models are appearing constantly. Open-weight models are becoming more capable. Inference is getting cheaper. Developers can access models from companies like Qwen, DeepSeek, Meta, NVIDIA, and others without necessarily building everything from scratch.

So a more important question is emerging:

If the model becomes easier to access, where does the real value move?

I think the answer is:

The workflow.

The AI Stack Is Changing

The old mental model was simple:

User
 ↓
AI Model
 ↓
Answer

Then applications started adding RAG, tools, memory, and APIs:

User
 ↓
Model
 ↓
RAG + Tools
 ↓
Answer

Now we're moving toward something more like:

User Goal
    ↓
Agent / Orchestrator
    ↓
Model Selection
    ↓
Tools + APIs + Data
    ↓
Multiple Agents
    ↓
Verification
    ↓
Workflow
    ↓
Real Result

The model is still important.

But it is no longer necessarily the whole product.

What Happens When Models Become Interchangeable?

Imagine that tomorrow a new open model becomes significantly better at coding.

And two weeks later, another model becomes better at reasoning.

Then another becomes much better at image generation.

Would you rebuild your entire application every time?

Probably not.

A good AI application should be able to change the model without changing the entire product.

That means the architecture starts looking like this:

                 AI WORKFLOW
                      ↓
                Model Router
               ↙     ↓     ↘
          Model A  Model B  Model C
             ↓       ↓        ↓
               Tools / APIs
                    ↓
                  Result

The application doesn't need to be married to one model.

It needs to know which model is useful for which job.

This is already becoming a real infrastructure problem. NVIDIA's NeMo Switchyard, for example, is designed to route AI workloads across different models based on factors such as capability, cost, and latency.

But Aren't Open Models Free?

This is where things get interesting.

When people hear:

“This model is open.”

they sometimes interpret it as:

“AI is now free.”

That's not really how the economics work.

The model weights may be available.

But running the model still requires:

GPUs
electricity
memory
networking
storage
inference infrastructure
monitoring
scaling
engineering
reliability

So there are several ways an open-model company can build a business.

1. Cloud

Give developers access to the model without requiring them to buy GPUs.

Open Model
    ↓
Cloud Infrastructure
    ↓
Developer
    ↓
Usage
    ↓
Revenue

2. API

The developer doesn't want to manage infrastructure.

So they pay for inference.

Your Application
      ↓
     API
      ↓
    Model

The model may be open, but convenient access isn't necessarily free.

3. Enterprise

Large companies often need more than a model.

They need:

private deployment
security
compliance
monitoring
support
customisation
predictable performance

That's another layer where companies can charge money.

4. Infrastructure

Sometimes the biggest opportunity isn't the model itself.

It is everything required to run thousands or millions of model requests reliably.

Free Access Can Also Be a Business Strategy

There's another interesting idea here.

Suppose a company gives developers free access to a model or a limited amount of compute.

Why?

Because the goal may not be to make money from the first request.

The goal can be:

Free access
     ↓
Developer tries it
     ↓
Developer builds something
     ↓
Users arrive
     ↓
Usage grows
     ↓
Developer needs more compute
     ↓
Paid infrastructure / API / enterprise

So:

Free can be customer acquisition.

The company gets developers into its ecosystem first.

Developers build products on top of the technology.

When those products grow, their requirements grow too.

More inference.

More GPUs.

More storage.

More reliability.

More enterprise features.

That's where monetization can begin.

But Here's the Bigger Opportunity

If models are becoming easier to access, developers don't necessarily need another application that says:

“Here is our AI model.”

They need applications that say:

“Tell me what you want done.”

That's a very different product.

Consider two systems.

System A — Chatbot

You:

“Write a marketing campaign.”

AI:

“Sure. Here's a marketing campaign.”

Useful.

But you're still doing most of the work.

System B — Agent Workflow

You:

“Launch a marketing campaign for my new SaaS.”

The system could potentially:

Understand the product
        ↓
Research the audience
        ↓
Create campaign strategy
        ↓
Generate copy
        ↓
Create visual assets
        ↓
Review the content
        ↓
Prepare channel-specific posts
        ↓
Schedule them
        ↓
Track results

Now the AI isn't just generating text.

It's participating in a workflow.

That's the important shift.

One Model Doesn't Need to Do Everything

This is where multi-model systems become interesting.

Imagine a workflow with five steps:

Research
   ↓
Reasoning
   ↓
Coding
   ↓
Image Generation
   ↓
Review

Why force one model to handle all five?

Maybe:

Model A is excellent at research.
Model B is better at reasoning.
Model C is better at coding.
Model D is better at images.
Model E is cheap and fast enough for verification.

So the workflow can become:

                  USER
                   ↓
              ORCHESTRATOR
                   ↓
       ┌───────────┼───────────┐
       ↓           ↓           ↓
   Research     Reasoning    Coding
    Model A      Model B     Model C
       ↓           ↓           ↓
       └───────────┼───────────┘
                   ↓
             Image Model D
                   ↓
              Review Model E
                   ↓
                RESULT

The user doesn't need to know all of that.

They simply need the result.

This Changes the Developer's Job

A few years ago, developers spent a lot of time asking:

Which framework should I use?

Then:

Which database?

Then:

Which model?

Now we're increasingly asking:

How should these models, tools and agents work together?

That's a much more interesting engineering problem.

You need to think about:

Routing

Which model should handle this task?

Context

What information should the model receive?

Tools

What can the agent actually do?

Memory

What does it need to remember?

Reliability

What happens when a model fails?

Verification

How do we know the result is correct?

Cost

Why use an expensive model when a cheaper one is sufficient?

Execution

Can the system actually complete the task instead of just explaining how to do it?

These problems don't disappear when models become better.

In some ways, they become more important.

The Real Product May Be Above the Model

This is the part I find most interesting.

Imagine two companies.

Company A

“We have the smartest model.”

Company B

“Give us the goal. We'll figure out which models, agents and tools are needed to accomplish it.”

If models continue improving and becoming more interchangeable, Company B has an interesting advantage.

Because its product isn't dependent on one particular model.

It owns the workflow.

Model = Engine

Agent = Worker

Tools = Capabilities

Workflow = Process

Product = Outcome

The engine can change.

The workers can change.

The tools can change.

But the workflow can remain.

This Is Where Multi-Agent Systems Become Useful

A multi-agent system doesn't necessarily mean:

“Let's add 20 AI agents because agents are cool.”

That's not useful.

The better question is:

What different responsibilities exist inside this task?

For example:

Planner
   ↓
Researcher
   ↓
Builder
   ↓
Reviewer
   ↓
Executor

Each agent has a job.

And each job can potentially use the model that makes the most sense for it.

That's much closer to how software systems have always been designed.

We don't use one database for every possible problem.

We don't use one programming language for every task.

Why should we assume one AI model will always be optimal for everything?

What We're Exploring With Xenition

While working on this problem ourselves, we started asking a different question:

What if the user never had to care which model was being used at all?

That's one of the ideas behind what we're building with Xenition.

Xenition is an all-in-one AI workspace where multiple agents, models, tools, and workflows can work together.

Instead of asking users to manually decide:

“Which model should I use for this step?”

the goal is to let the workflow handle more of that complexity.

For example, one part of a workflow might need strong reasoning.

Another might need code generation.

Another might need image generation.

Another might simply need a fast, inexpensive model for a small task.

The interesting part isn't simply that Xenition uses multiple models.

The interesting part is hiding that complexity from the user.

The user shouldn't have to think:

Should I use Qwen, Claude, GPT, DeepSeek, or another model for this step?

They should be able to say:

“Here's what I want to accomplish.”

And the system should handle the rest.

The Biggest Opportunity for Developers

This doesn't mean developers should stop building models.

Models will remain extremely important.

But there is a huge opportunity in building the layers around them.

Things like:

agent orchestration
model routing
memory
tool calling
workflow engines
evaluation
verification
observability
permissions
data integration
automation
human approval
execution

These are the things that turn:

“AI generated something.”

into:

“The work actually got done.”

And that's a much more valuable outcome.

So What Should Developers Build?

I don't think the answer is:

“Build another chatbot.”

And I don't think it's always:

“Train another bigger model.”

A more interesting question is:

What job can AI actually complete from beginning to end?

Don't start with:

“Which model should I use?”

Start with:

“What outcome should the user get?”

Then work backwards.

Desired Outcome
      ↓
Required Workflow
      ↓
Required Tools
      ↓
Required Agents
      ↓
Best Model for Each Task
      ↓
Verification
      ↓
Execution

That changes how we build AI products.

The Model May Not Be the Moat

This is probably the biggest lesson.

If your entire product depends on:

“We use Model X.”

then what happens when Model Y becomes better?

Your advantage can disappear overnight.

But if your product has:

excellent workflows
useful integrations
proprietary context
strong execution
reliable automation
great user experience
accumulated workflow knowledge

then changing the underlying model doesn't destroy the entire product.

It can actually make your product better.

The Future May Not Be Model vs. Model

It may be:

Workflow vs. Workflow.

The model is becoming easier to access.

Agents are becoming more capable.

Tools are becoming easier to connect.

Open models are expanding the number of choices developers have.

And model-routing infrastructure is making it increasingly practical to use different models for different jobs.

So perhaps the most important question for the next generation of AI applications isn't:

“Who has the best model?”

It's:

“Who can turn all these models into the best experience for getting real work done?”

The model is the engine.

The agent is the worker.

The workflow is the product.

And ultimately:

Don't build around a model. Build around a job.

How to Promote a SaaS Product: A Practical Step-by-Step Playbook

Darun Karas Abir — Mon, 17 Aug 2026 09:57:34 +0000

Building a SaaS product is easier than it used to be.

You can validate an idea quickly, build an MVP with a small team, use AI to speed up development, and launch within weeks.

But then comes the harder question:

How do you get people to actually discover your product?

A great product with no distribution can easily become a product nobody knows exists.

This guide walks through a practical SaaS promotion system you can start using today.

1. Don't Start With "How Do I Get More Users?"

Start with:

Who has the problem my product solves?

Before posting anything, define three things.

Your target customer

For example:

Startup founders
Freelancers
Marketing teams
Developers
Small businesses
Agencies

Their problem

Don't describe your product yet.

Describe the problem.

Instead of:

"We built an AI project management platform."

Try:

"Small teams spend hours every week turning scattered messages and tasks into organized project updates."

The second statement gives you a promotion angle.

Your outcome

What changes after someone uses your product?

For example:

Before:
5 hours of repetitive work every week.

After:
30 minutes of automated work.

That transformation should appear repeatedly in your marketing.

2. Create a Simple Promotion Foundation

Before trying to get attention, make sure someone who discovers you can understand your product in seconds.

Your landing page should answer:

What is this?
Who is it for?
What problem does it solve?
What makes it different?
What should I do next?

A useful formula is:

Problem → Solution → Proof → Action

For example:

Managing social content manually takes hours every week.
Our platform automates the repetitive parts.
Teams are already using it to manage their campaigns.
Start your first campaign today.

Don't make visitors work to understand what you're selling.

3. Promotion Method #1: Do It Yourself

You don't need a huge audience to start.

You need a repeatable system.

Start with 3–4 channels where your potential customers already spend time.

For a developer-focused SaaS, that might be:

X
Reddit
LinkedIn
Dev.to
Product Hunt
Relevant communities

Don't copy-paste the same advertisement everywhere.

Instead, turn one product insight into multiple pieces of content.

Example

Suppose your SaaS helps automate reporting.

One product insight can become:

X:
"Most reporting workflows aren't difficult. They're repetitive."

Dev.to:
"How I Automated a Weekly Reporting Workflow"

Reddit:
"I spent a month eliminating repetitive reporting tasks. Here's what worked."

LinkedIn:
"5 reporting tasks your team probably shouldn't be doing manually."

One idea becomes four pieces of content.

4. Use the 80/20 Content Rule

A common SaaS marketing mistake is making every post an advertisement.

Instead, try:

80% useful content
20% product-related content

Teach people something they can use even if they never become your customer.

For example, if you built an analytics SaaS, don't only post:

"Try our analytics platform!"

Also publish:

How to choose SaaS metrics
How to reduce dashboard noise
How to calculate retention
Common analytics mistakes
How to structure product experiments

Useful content creates trust.

Trust makes the eventual product promotion much easier.

5. Promotion Method #2: Work With Creators

You don't necessarily need celebrities.

For SaaS, smaller creators can sometimes be more useful because their audience is highly focused.

Look for creators who already talk about your customer's problem.

For example:

Developer SaaS → developer creators

Design SaaS → design creators

Marketing SaaS → marketing creators

Finance SaaS → finance/business creators

The important part is audience relevance, not follower count alone.

How to Find the Right Creators

Create a spreadsheet with:

Creator	Platform	Audience	Followers	Engagement	Contacted	Result
Creator A	YouTube	Developers	25K	High	Yes	Waiting
Creator B	X	Founders	12K	High	Yes	Interested
Creator C	TikTok	Marketing	80K	Medium	No	—

Then prioritize creators based on:

Audience relevance + engagement + content quality

rather than simply choosing the biggest account.

6. Give Creators Something Worth Showing

Don't send a creator a generic message:

"Hey, check out our SaaS."

Give them a story.

For example:

"Can you show your audience how you automated your weekly reporting workflow?"

Now the creator has content.

The product becomes part of the story instead of being the entire story.

That's a much stronger promotion strategy.

7. Build a Creator Promotion Loop

Once you find creators who perform well, don't treat each collaboration as a one-time event.

Create a loop:

Find → Contact → Collaborate → Publish → Measure → Repeat

Track:

Views
Clicks
Signups
Activation
Paid conversions
Cost per acquisition

After several collaborations, you'll start seeing which creators actually drive customers rather than just views.

8. Promotion Method #3: Use AI to Scale the Work

AI can be useful for promotion, but there's an important distinction:

AI shouldn't replace your product knowledge. It should use your product knowledge.

Give your marketing system useful context:

Product description
Target audience
Features
Use cases
Customer problems
Pricing
Brand voice
Existing content
Competitors
Testimonials
Website information

Then AI can help turn that context into promotional work.

For example:

Product context →

"Our SaaS helps small agencies automatically generate weekly client reports."

AI can help produce:

X post ideas
LinkedIn posts
Blog topics
Video scripts
Creator briefs
Reddit discussion angles
Email campaigns
Content calendars

The important part is that the AI is working from your actual product context, rather than generating generic marketing text.

9. Turn One Feature Into an Entire Campaign

Let's say your product has one major feature:

Automatically generates client reports.

Don't create one post and move on.

Build a campaign around it.

Content 1 — Problem

"Why are agencies still manually building weekly client reports?"

Content 2 — Educational

"How to build an automated reporting workflow."

Content 3 — Demonstration

"Watch a client report go from raw data to finished report."

Content 4 — Founder story

"Why we stopped manually preparing reports."

Content 5 — Creator content

"Creator demonstrates the workflow."

Content 6 — Comparison

"Manual reporting vs automated reporting."

Content 7 — Product CTA

"Try the workflow yourself."

One feature can produce an entire week's worth of content.

10. Don't Chase Views — Track the Funnel

A post receiving 100,000 views isn't automatically successful.

Imagine two posts:

Post A

100,000 views
500 clicks
10 signups
0 customers

Post B

10,000 views
700 clicks
150 signups
20 customers

Post B is probably far more valuable.

Track your funnel:

Impressions → Clicks → Signups → Activation → Paid Customers

This tells you where the actual problem is.

11. Find Your Best Distribution Channel

After publishing consistently for a few weeks, look at the numbers.

You might discover:

Channel	Views	Signups	Customers
X	50K	80	5
Reddit	15K	120	12
LinkedIn	30K	40	3
Creators	100K	300	28

The answer isn't:

"Creators got the most views."

The better question is:

Which channel produced the best customers?

Double down on that channel.

12. Build a Weekly Promotion System

You don't need to reinvent your marketing strategy every Monday.

Create a repeatable schedule.

Monday

Research customer problems.

Tuesday

Create educational content.

Wednesday

Publish a product demonstration.

Thursday

Work with creators or community members.

Friday

Analyze performance.

Weekend

Repurpose the best-performing content.

This turns promotion from a random activity into an operating system.

13. The Promotion Flywheel

A strong SaaS promotion system eventually looks like this:

Build product

↓

Understand customer problem

↓

Create useful content

↓

Distribute content

↓

Creators amplify it

↓

AI helps scale repetitive promotion work

↓

Measure results

↓

Learn what works

↓

Create better content

↓

Repeat

The goal isn't to "go viral."

The goal is to build a repeatable distribution engine.

14. A Simple 30-Day SaaS Promotion Plan

If you're launching a SaaS right now, here's a practical starting point.

Week 1 — Foundation

Define your ideal customer
Write your core problem statement
Improve your landing page
Create 5 customer-focused content ideas
Set up analytics

Week 2 — Content

Publish 3–5 educational posts
Publish 1 product demonstration
Write one detailed tutorial
Participate in relevant communities

Week 3 — Distribution

Contact 20 relevant creators
Repurpose your best content
Test different hooks
Experiment with two new channels

Week 4 — Optimization

Identify your best-performing content
Identify your best acquisition channel
Calculate conversion rates
Double down on what worked
Stop spending time on channels producing nothing

Final Thought

Building a SaaS is no longer the only difficult part of starting a software business.

Distribution is becoming the competitive advantage.

The companies that win won't necessarily be the ones that build the most features.

They'll be the ones that can repeatedly:

Build → Explain → Distribute → Measure → Improve

So don't wait until your product is "perfect" before thinking about promotion.

Start building your distribution system while you're building the product.

Because shipping the product is only the beginning.

Getting the right people to notice it is the real game.