working problem

How much of a “game-changing” AI product can a capable subscriber build for themselves?

exploringconfidence: working hypothesislast meaningful update: 2026-09-25

Every day, new apps, platforms and systems are presented on LinkedIn, Instagram, TikTok and elsewhere as game changers.

Some of them may be.

But AI has changed the economics of building software. A polished interface can now conceal a surprisingly simple combination of prompts, workflows, public data and existing models. What once required a development team, significant capital and months of work may sometimes be reproduced by one capable person with a serious AI subscription.

I want to find out how often that is true.

The experiment

We will take one publicly presented app, program or system at a time and work backwards from what it promises.

We will examine:

  • the problem it claims to solve
  • the outcome the user actually receives
  • the likely inputs, workflow and model capabilities behind it
  • how much of the core value can be recreated with widely available AI tools
  • how long a credible reconstruction takes
  • what it costs to build and operate
  • what still requires specialist technology, proprietary data, distribution, trust or human expertise
  • whether buying the original product remains better than building the capability yourself

The objective is not to copy a company’s code, branding or protected assets. We will use public information to reconstruct the underlying job and test what an ordinary, capable subscriber can accomplish independently.

Why this matters

For users, the question is practical:

Do I need another subscription, or can the AI tools I already pay for do most of this?

For founders, the question is more serious:

Am I building a durable company — or packaging a capability that my customers will soon be able to create for themselves?

That distinction matters when people consider leaving secure careers, investing savings or asking others to finance a product whose technical barriers may be falling faster than expected.

Easy development does not automatically create a bad product. Distribution, trust, workflow integration, proprietary data, speed, support, accountability and exceptional user experience can all create real value.

But the ability to build something is no longer strong evidence that a defensible business exists.

The rules

This will be a constructive examination, not a takedown.

We will:

  • analyse one product at a time
  • work only from public claims, demonstrations and lawful access
  • avoid proprietary code, private data and attempts to bypass security
  • distinguish a limited reconstruction from the complete product
  • document assumptions, gaps and failures
  • give credit where the original product solves something genuinely difficult
  • publish what users can reasonably do themselves and what still justifies buying

The result should be useful to both sides: customers should make better build-versus-buy decisions, and founders should see more clearly where genuine defensibility must come from.

What I am trying to learn

I do not expect every product to collapse into a prompt.

Some will prove much harder to reproduce than their marketing makes visible. Others may turn out to be excellent packaging of capabilities that users do not want to assemble themselves. And some may reveal that the apparent product is little more than a thin layer over tools the audience already owns.

The working question is therefore not whether we can make a rough imitation.

It is:

How much of the promised outcome can a capable user reproduce — at acceptable quality, cost and effort — using the AI access they already have?

We will begin with one product, show our work and let the evidence decide.