Is Software Factory a new software category?

A new category is forming

A new software category is growing: software factories.

I started seeing it on my YouTube feed and on Twitter, and heard it mentioned by founders. Seems like they found a name, and it's software factory.

It includes more complex agents, harnesses and tools that help you build software in a certain templated way, so it integrates well with your codebase.

Imagine asking Claude to build a feature. It generates the code, but you still need to make sure it follows your architecture, uses the right components, passes tests and integrates with the rest of your application.

A software factory aims to automate more of that process, using a predefined system that follows your company's engineering standards.

Positioning problem: Explaining the benefits of a software factory

The tools that belong to this category face an interesting positioning challenge.

They need to convince their audience that shipping code faster isn't enough, and explain why a software factory is a better alternative to simply using Claude Code.

So far, AI coding tools have massively increased the velocity at which companies can build software. But they've also introduced a new problem: more code to review, more inconsistencies and potentially more technical debt.

Now, with software factories, it's time to fight the AI slop that process generated.

A software factory aims to give a whole organisation the same software best practices and consistency, instead of ending up with 50 skills that nobody uses and that do the same thing.

In short, the potential benefits are:

• Features fully integrated with the existing codebase, with as little adjusting as possible.
• More consistent and reliable code, instead of wacky vibe-coded software.
• Less manual review effort and fewer shitty PRs.
• The same engineering standards across the whole organisation.

For a marketer bringing this product to market, the question is: who has these problems, and who is willing to pay to solve them?

Defining the ICP: Who actually needs a software factory?

In my view, this story has two sides.

One is for technical people, like devs, CTOs and engineering leads. For them, a software factory could mean fighting the bottleneck of reviewing code and eliminating bad PRs that take more time to adjust than what they actually ship.

The other side is for non-technical people, like hands-on CEOs, marketers, product managers and designers. For them, it could mean shipping features fully integrated with the codebase and replacing wacky vibe-coded pieces of software with robust code that actually works.

But these are personas, not ICPs.

My initial hypothesis is that the strongest ICP could be B2B SaaS companies with small engineering teams, already using AI coding agents to ship production features.

These companies are likely to experience the problem sooner than others. They have small teams, limited resources and pressure to ship quickly. AI coding tools help them increase development speed, but they still need to maintain code quality and consistency.

Within these companies, CTOs and engineering leads could be the buyers, developers the main users, and non-technical builders a secondary audience.

This gives us two potential audiences, with two different problems to solve.

Two positioning hypotheses

Hypothesis A: Engineering productivity

Audience: CTOs, engineering leads and senior developers at small B2B SaaS companies.

Problem: AI generates code faster than engineering teams can review and integrate it.

Developers can now generate entire features with AI agents, but someone still needs to review the code, fix inconsistencies and make sure everything works with the existing architecture.

The bottleneck is moving from writing code to reviewing it.

For this audience, I would focus the messaging on the time wasted reviewing AI-generated code, and how software factories can help teams ship without creating even more work for developers.

Potential positioning:

Your agents write code faster than your team can review it.

In the content, I would push this narrative: explaining the problem, rubbing on pain points, and showing the logos of other companies that achieved the results they're aiming to achieve.

I would focus on:

• The time spent reviewing and fixing AI-generated PRs.
• The technical debt created by inconsistent code.
• The difficulty of maintaining engineering standards when everyone uses different agents and skills.
• How a software factory can help teams ship more without increasing the burden on developers.

The goal is to show that a software factory isn't another AI coding tool. It's a way to make AI-generated development more consistent and manageable across an organisation.

whiteboard.png

Hypothesis B: From prototype to production

Audience: Hands-on founders, product managers, marketers and designers at B2B SaaS companies.

Problem: Building prototypes with AI is easy. Turning them into production-ready features is much harder.

Marketers, product managers, designers and hands-on CEOs can now build prototypes, internal tools and even entire applications with Claude.

But there's a big difference between building something that works on your computer and shipping a feature that integrates properly with an existing product.

For this audience, I would focus on the frustration of building something with AI, getting it to work, and then realising that turning it into a real product is much harder than expected.

Potential positioning:

You built it with Claude. Now how do you ship it?

The content would show examples of things people are already building with AI, explain where they get stuck, and demonstrate how a software factory can help them go from an idea to a feature that actually works within their existing codebase.

I would focus on:

• The gap between building a prototype and shipping a real feature.
• The frustration of depending on developers to bring AI-generated projects into production.
• The difficulty of integrating AI-generated code into an existing product.
• How software factories could help non-technical people contribute to product development without creating more technical debt.

The idea isn't to sell them a more complex coding tool. It's to show them how they can take what they're already doing with AI one step further.

whiteboard.png

Testing the positioning on LinkedIn

So now we have two narratives for two different segments.

You can create LinkedIn Ads, thought leadership ads, or organic content, and get into the routine of connecting with a few people on the list every day.

With this mini content strategy, you bring your story in front of them and see if anything resonates. There are a few ways to reach them, and that really depends on your budget.

I would start by building two separate audiences on LinkedIn.

Audience A: CTOs, engineering leads and senior developers at B2B SaaS companies with small engineering teams.

Audience B: Founders, product managers and non-technical builders at similar companies.

For each audience, I would create three or four pieces of content around their specific pain points.

The founder's LinkedIn profile would be the main distribution channel. Especially in a category that people are only starting to understand, I think it's easier to educate the market through a person rather than a company page.

The goal at this stage wouldn't necessarily be to generate a massive number of leads. It would be to understand which segment feels the pain the most, which message resonates, and who is willing to take the next step.

I would look at engagement, comments, profile visits, landing page conversions and, most importantly, the conversations generated by the content.

I'd also pay attention to which audience already has a process or budget to solve the problem.

Once you start seeing a pattern, you can double down on the audience and messaging that work best.

FAQ: Positioning a software factory

What is the difference between a software factory and an AI coding agent?

AI coding agents like Claude Code help developers write code. A software factory aims to orchestrate the entire development process, from generating code to testing, reviewing and integrating it into an existing codebase.

The difference isn't necessarily how fast you generate code, but how much work is left before you can ship it.

Who is the ideal customer for a software factory?

My initial hypothesis is small B2B SaaS companies already using AI coding agents to build production features.

But that's still a hypothesis. The ideal customer is the company experiencing the problem frequently enough, and painfully enough, to invest in solving it.

That's exactly what the positioning experiments should help uncover.

Should software factories target developers or non-technical users?

Potentially both, but I wouldn't try to convince everyone with the same message.

Developers care about code quality, consistency and reducing review time. Non-technical users care about turning their ideas into real features without getting stuck in the development process.

I would test both narratives before deciding where to focus.

How would you know which positioning works best?

I wouldn't look at impressions or engagement alone.

I'd look at who starts conversations, what problems they describe, whether they're already looking for solutions, and whether they have the budget and authority to buy.

Ten conversations with the right people could tell you more than thousands of impressions.

Is LinkedIn enough to validate the positioning?

No, but I think it's a good starting point.

LinkedIn can help you put different narratives in front of specific audiences and start conversations with potential buyers.

I'd combine the results with customer interviews, product demos and feedback from early adopters. The goal isn't just to find a message people like, but to understand whether there's a real problem worth paying to solve.

What happens after finding the right positioning?

Once one audience and message consistently generate meaningful conversations, I'd start narrowing the focus.

That means building more content around the winning pain point, collecting customer proof, refining the landing page and eventually testing a more structured acquisition strategy.

The positioning will probably keep evolving as the category matures. And that's what makes working on an emerging category interesting.