---
title: "The problem is solved. Why isn't it a product?"
description: "I built, with coding agents, what an observability SaaS used to do for us. Collecting logs, analysing them, and improving the code from them all worked through AI, and I got exactly the interface I wanted. It still was not a product. Put the minimum conditions for solving a problem and for being a product side by side on the four-layer stack, and they part ways at the point where the person who uses a tool, the person who runs it, and the person accountable for it stop being the same person. Whether to build or buy then stops being a question of replacement and becomes a choice, stage by stage, of how much you are willing to be accountable for."
canonical: "https://architecture.reopt.ai/articles/problem-solved-not-a-product"
language: "en"
last-updated: "2026-10-22"
alternate-markdown: "https://architecture.reopt.ai/ko/articles/problem-solved-not-a-product.md"
site-index: "https://architecture.reopt.ai/llms.txt"
source: "reopt architecture"
---

# The problem is solved. Why isn't it a product?

> I built, with coding agents, what an observability SaaS used to do for us. Collecting logs, analysing them, and improving the code from them all worked through AI, and I got exactly the interface I wanted. It still was not a product. Put the minimum conditions for solving a problem and for being a product side by side on the four-layer stack, and they part ways at the point where the person who uses a tool, the person who runs it, and the person accountable for it stop being the same person. Whether to build or buy then stops being a question of replacement and becomes a choice, stage by stage, of how much you are willing to be accountable for.

- **Author:** Eric Han
- **Date:** 2026-10-22
- **Category:** analysis
- **Tags:** saas, product, ownership, observability, OCLS

## I built my own log monitoring

At my previous company we ran an observability SaaS on an enterprise plan. This year I rebuilt what that tool did for us, working with coding agents.

The structure is simple. It collects the service's logs and exposes them over MCP. The AI then reads the logs itself. It works out why an error happened and fixes the code based on that analysis. There is no hunting through dashboards for the right graph. I ask the AI what I want to know.

What I needed was a minimal endpoint for analysing logs, and I shaped the interface the way I wanted it. The problem was solved. But ask whether I could sell it and the answer comes immediately. I could not.

How do the minimum conditions for solving a problem differ from the minimum conditions for a product? That one question is what this article is about.

## Solving the problem ends at the bottom two layers

Seen through the [four-layer model](/architecture) of reopt architecture, the tool fills the bottom two layers. The Module layer holds an endpoint that collects logs and hands them out; the Agent layer holds an AI that reads them, judges, and fixes. That was everything solving the problem required, and AI has driven down the cost of building those two layers dramatically. The claim that you can replace a SaaS by building it yourself holds this far.

## A product starts only once the top two layers are filled

| | Minimum to solve the problem (The log tool I built) | Minimum to be a product (When user, operator, and owner are different people) |
|---|---|---|
| L4 Governance | _Empty_ | Availability guarantees, retention policy · Access control and audit, cost control |
| L3 Collaboration | _Empty_ | Several teams and roles read the same logs · A path from alert to response |
| ↑ Where it becomes a product / ↓ Where AI replaces it | | |
| L2 Agent | AI reads logs over MCP and fixes code · The owner is me | Every outcome has a named owner · Who answers when the AI analysis is wrong? |
| L1 Module | An endpoint that collects and serves logs · The interface I want | A contract with users you have never met · Refusal conditions, versions, compatibility |

_Solving the problem ends at the bottom two layers; a product starts only once the top two are filled_

My tool has nothing in the top two cells on the right. Start with the Collaboration layer. Log monitoring used as a product is read by several teams and several roles. When an alert fires it is handed to whoever responds, and the response leaves a record. My tool lacks this layer, and not out of laziness. There is only one user, so there is no one to hand anything to.

The Governance layer raises more questions. A monitoring tool has to stay up even when the service it watches goes down, so who guarantees that availability? How long are logs kept, and when are they deleted? Who can see which logs, and is that access recorded? When ingestion grows tenfold, who controls the cost?

The bottom two layers change character too once they become a product. A module's contract has to hold for users you have never met, so it must say what it refuses and what breaks when a version changes. At the Agent layer, someone has to be named as the one who answers when the AI gets an analysis wrong.

What goes into the top two layers is not functionality. It has nothing to do with analysing logs better. It is the set of conditions that let someone else trust the tool enough to rely on it.

## It becomes a product when the three roles split

In "the interface I want", the word that matters is "I". With my tool, the person who uses it, the person who runs it, and the person accountable for it are all me. When those three are one person there is no need to write a contract down; what I want is the contract. With no one to hand off to, there is no need for a collaboration structure, and when something breaks I fix it myself, so there is no one to promise availability to.

Hold both against the four OCLS questions and the difference sharpens.

| | Solving the problem | Being a product |
|---|---|---|
| **OWN** | User, operator, and owner are one person | Responsibility holds even when the three are different people |
| **CONTRACT** | The endpoint I want. It need not be written down | A written contract that holds for users you have never met |
| **LAYER** | Module and Agent, two layers | All four layers |
| **SHARPEN** | I fix it when it bothers me | Regular correction from many users' operating signals |

A product has to keep working when those three are different people. Customers use it, an operations team runs it, a company is accountable for it. The top two layers are the machinery that closes the gaps that open the moment the three roles split. That is why they are unnecessary before the roles split, and why nothing holds without them afterwards.

Others have reached the same conclusion by a different road. Satya Nadella suggested on the BG2 podcast in December 2024 that [the very notion of business applications could collapse in the agent era](https://cloudwars.com/ai/apps-apocalypse-bill-mcdermott-joins-satya-nadella-in-saying-ai-agents-will-crush-applications/). Dave Vellante and George Gilbert at SiliconANGLE argued that the prediction holds only for single-user apps like Office. In software many people share, [the logic tier does not go away; it changes shape](https://siliconangle.com/2026/02/28/satyas-sacrifice-agents-threaten-office-microsoft-responds/), because work that spans several systems needs consistency and governance.

## The limit of replacing SaaS

So the question of whether you can replace a SaaS by building it yourself can only be half answered. Functionality gets replaced. What does not get replaced is the structure that lets others trust it and rely on it.

A piece from the venture firm Forgepoint puts it more bluntly. When a vendor fails, there is an outside party to hold accountable; when a tool you built fails, the blame stays with your own team. They call [the ability to shift blame](https://forgepointcap.com/perspectives/margin-of-safety-43-saaspocalypse-vibe-coding-and-the-new-scarcity/) a feature no AI agent can provide. In their words, vibe coding reduces the cost of creation, but it does not change the cost of being wrong.

When looking at a tool you built yourself, ask this.

> Does this tool keep working when the person who uses it, the person who runs it, and the person accountable for it become different people?

If the answer is no, what you have is a solved problem. That is not a bad thing. For a tool only you use, the bottom two layers are enough, and thanks to AI those two layers are cheaper than ever. But to call it a product, the top two layers have to be filled.

And the top two layers are not filled in one go. Yevgeniy Brikman wrote that [you cannot shortcut the process of maturity](https://www.ybrikman.com/blog/2026/08/01/what-you-cant-vibe-code/). Most of what software costs comes after it is built, in maintenance, and what accumulates from living through outages and security issues one by one cannot be caught up with by writing code faster. The figure above is a snapshot; the top two cells on the right are filled by time.

From the side of those building SaaS, the same question points the other way. Customers can now build the bottom two layers themselves. What they cannot build themselves is the top two, and that is where a product has room to stand.

## Designing the scope of responsibility

Come back to the side of solving the problem. How complete does a tool you built for yourself need to be? The measure is not a feature list. It is who pays when the tool stops working. If I pay and I can absorb it, the completeness of the bottom two layers is enough. The moment someone else pays, the completeness required climbs a layer at a time.

Look past "the problem is solved" to the scope of operation, and building versus buying stops being a question of replacement. It becomes a choice you make at each stage.

| Stage | The three roles | Layers needed | What to choose |
|---|---|---|---|
| Only I use it | All three are me | Module, Agent | Usually build. Thanks to AI, this is where it ends cheapest |
| My team uses it | Users multiply | Add Collaboration | Fill in sharing and alert handoff yourself, or use a SaaS |
| Others rely on it | Operation and accountability split too | Add Governance | Carry availability, retention, and access yourself, or hand them off |

My log tool is at the first stage today. If my service goes down and the log tool goes down with it, I work blind for a while, but that cost is mine to pay and I can absorb it. Once the team starts reading the same logs it moves to the second stage, and the moment incident response depends on it, it reaches the third. At that point I have to choose again whether to fill the top two layers myself.

The choice can be made layer by layer as well. Hand the collection and retention of the Module layer and the availability and access control of the Governance layer to a SaaS, and build the analysis and improvement loop of the Agent layer on top, shaped the way I want. Not replacement, but a division of responsibility.

So the question changes. Not whether you can replace a SaaS, but how many layers you will be accountable for at the stage you are in. Choose the answer again each time the roles split.

As AI starts making the top two layers cheaper too, this boundary will move with it. How far it moves is a question I have not yet answered.

## Related patterns

- [Responsibility Partitioning](https://architecture.reopt.ai/patterns/responsibility-partitioning.md)
- [Module Contract](https://architecture.reopt.ai/patterns/module-contract.md)

---

_Markdown representation of https://architecture.reopt.ai/articles/problem-solved-not-a-product. Full index: https://architecture.reopt.ai/llms.txt HTML original: https://architecture.reopt.ai/articles/problem-solved-not-a-product · 한국어: https://architecture.reopt.ai/ko/articles/problem-solved-not-a-product.md_