This paper explores how changing software economics affect customer value, internal work and competitive advantage. It connects published research with our BLOCK-iQ development experience, including the architecture, testing and operating work around the code. Those perspectives inform the choices to build, buy, partner or stop.
Just because you can, does not mean you should.
Our experience developing BLOCK-iQ, including work with Solid, points to two opportunities and a defensive question. Each belongs in strategy, alongside evidence from customers and practical experiments.
Executive choice | What to reconsider | Evidence to seek |
|---|---|---|
Create new revenue | Turn expertise or a repeatable service into a product that was previously uneconomic. | A customer problem, a route to market and willingness to pay. |
Improve internal work | Connect existing systems and complete work left between email, spreadsheets and software. | Better outcomes, actual adoption and full operating cost. |
Protect existing value | Reassess what customers would still buy if core features became easier to reproduce. | Reasons to stay, distinctive value and viable pricing. |
For software and productised services, review what customers pay for beyond features: trusted expertise, data rights, embedded integrations and dependable service. Test whether pricing still fits the value delivered as delivery effort changes.
What the evidence supports
Bain describes building an outside-in prototype during acquisition due diligence that raised concerns about a target’s defensibility. In another case, embedded workflows, data and customer loyalty supported a more positive view. Reproducible functionality and a replaceable business are different propositions. [1]
The 2026 MirrorCode preprint tested AI agents recreating 25 programs without source access. The strongest model scored 56% across the benchmark. This demonstrates substantial capability and remaining limits; it does not establish that a complete enterprise service can be copied reliably. [2]
[1] Bain and Company • New Diligence Challenge Uncovering AI Risks and Opportunities • 27 October 2025.
[2] Adamczewski and colleagues • MirrorCode • preprint revised 17 July 2026.
Start with demand and prove adoption
Cheaper development can make previously unattractive opportunities worth testing. It changes the viability calculation; it does not prove viability. The obligation to validate customer desirability endures, while expectations and alternatives can change. Understanding demand, earning adoption and covering the full cost to serve remain essential.
Find the problem in the customer’s work
Look for a recurring task with a real consequence: a decision delayed, a handover lost or information repeatedly rekeyed. Ask people to walk through the last time it happened. Understand their workaround, incentives and buying process before presenting a solution. Internal colleagues are customers too; a sponsor’s enthusiasm does not establish that they will change how they work.
Matt Lerner’s work on language–market fit is useful here. It asks teams to express value in the words customers use for their goals and struggles, then test whether that language is understood and resonates. His Growth Levers toolkit provides practical support for interviews, growth models and experiments. [3, 4]
Test the route to value alongside the product
Test | For an external product | For an internal tool |
|---|---|---|
Demand | Will a defined buyer commit time, data or payment to a trial? | Will colleagues try it on real work and return to it? |
Effectiveness | Does it deliver the outcome customers value enough to retain? | Does it improve decision quality, service or first time resolution? |
Economics | Can revenue cover acquisition, delivery, assurance and support? | Does the benefit exceed integration, change and ongoing run costs? |
For example, a customer onboarding task may cross sales, operations and finance. An AI-enabled service could collect missing information, prepare records and flag exceptions. That is a testable concept, not a promised result. Compare it with simplifying the process or using an existing product. Measure correct completion and customer effort as well as time saved; assign ownership when information is wrong or incomplete.
Make trust part of the proposition
Our hypothesis is that easier generation of convincing software and content increases the value of verifiable competence and dependable relationships. Test what customers actually trust: explainable recommendations, known people, reliable records, service recovery or clear accountability. A familiar brand and an impressive demonstration cannot substitute for performance.
The product includes onboarding, support and what happens when it fails. Lower coding cost alone does not settle pricing, customer acquisition or the cost of keeping a promise.
[3] Matt Lerner • Finding Language Market Fit • First Round Review, 2021.
[4] Matt Lerner • Growth Levers Toolkit • companion resources for Growth Levers and How to Find Them.
The work around the code
Developing BLOCK-iQ has required us to make customer intent, architecture and evidence explicit. An eight-layer view developed during that work helps reveal whether the pieces join up. It is an organising view, not a claim that every layer is complete or every journey proven. [5]
Layer | Question it makes us answer |
|---|---|
Surface | How does this particular user interact with the product? |
Journey | What is the customer trying to achieve from start to finish? |
Workflow | Which steps, people and exceptions move the work forward? |
Decision engine | Which question is answered, using which facts and rules? |
Policy and configuration | Which rules vary, and who can authorise a change? |
Shared services | What records and services must multiple journeys rely on? |
Knowledge graph | What do the relationships between entities mean? |
Data schema | How is information stored consistently and retrieved? |
Tracing a whole journey exposed gaps that a screen or a component test could miss. We therefore distinguish built, meaning code exists; live, meaning a screen or route calls it; and proven, meaning it passes a meaningful evaluation that a broken implementation would fail. These are separate engineering states, and none alone proves customer value. [5]
A harness makes the method repeatable
The documented build harness coordinates work, records decisions and evidence, and separates building from validation. Its gates check that relevant tests actually ran and treat missing evidence as unknown. This supports disciplined delivery; it does not remove the need for human judgement, security assessment or testing the complete customer journey. [5]
Bring the business and IT together
We have used Solid in the BLOCK-iQ work, including prototyping. Solid describes agents that can operate across approved systems, use or build integrations and work within access, budget and approval controls. These are vendor-described capabilities to validate for each deployment. [6]
Domain experts can take a larger role in shaping and testing products. IT remains a partner in architecture, data access, security, release and operation. Agree who accepts the outcome, who checks it, who approves deployment and who owns monitoring, incidents and rollback. Keep controls proportionate to the consequences of failure.
[5] BLOCK-iQ engineering records • Stack View, 6 August 2026; Build Board and build harness documentation, September 2026. Author’s project experience; these records are not an independent product assurance assessment.
[6] Solid • Product and enterprise capabilities • accessed 10 October 2026.
Use new evidence to change strategy
Strategy needs a current view of what customers could receive, what delivery could cost and what the organisation can execute. Assumptions about required team size, time to market or integration difficulty should be tested again. Equally, a feasible build may be a poor use of capital or leadership attention.
Decide whether the opportunity deserves investment
Decision lens | What leadership needs to establish |
|---|---|
Customer impact | Whose problem matters, and what would improve enough to change behaviour? |
Economics | Does the full cost make sense, including acquisition or adoption, integration, assurance and run? |
Execution | Can we access the data, change the work and operate reliably with named owners? |
Strategic fit | Does this strengthen a chosen advantage or distract from something more valuable? |
Choice and evidence | Should we build, buy, partner, simplify or stop? What evidence would change that choice? |
Connect practical fluency to strategic judgement
Practical AI fluency helps leaders distinguish a plausible demonstration from a dependable service. Customer discovery, assumption testing and verification develop alongside the tools. The methodology companion explains how TIP combines these disciplines across the sessions.
FUNCTION brings that learning into a future vision, customer needs, roles and a roadmap. STRATEGIC and ENTERPRISE connect it to markets, priorities and shared operating choices. Evidence can inform those decisions as it emerges.
Our application of Mindset + Method = Money & Momentum is to develop capability through the work, while checking customer value and full economics. The build is one source of learning; adoption and operation provide others.
Start with one consequential assumption
Choose a customer problem previously dismissed as too costly or difficult. Pair a business owner with IT; agree a budget, review date and stop criteria. Test a small service with real users. Measure effectiveness, net capacity, adoption, full cost and failures.
Take the evidence and trade-offs into STRATEGIC. Leadership owns the investment decision, including when to stop. Practical AI fluency should improve that judgement.
Explore the approach: Customer to code · Otto example · STRATEGIC
Go deeper: Method and references · Read and listen