Future To Build

Intelligence can become abundant while the ability to get anything done remains scarce.

A model can propose an experiment that no laboratory has time to run. It can write software that nobody knows how to maintain. It can explain a problem beautifully and still leave the person facing it with the same paperwork, the same waiting list, and the same lack of control.

That gap is where I would look for the next generation of important companies.

Read Conviction’s startup proposals, Y Combinator’s current Requests for Startups, and South Park Commons’ Summer 2026 questions together, and a useful pattern emerges. My reading is that the frontier is moving toward the conversion of intelligence into dependable action.

These are invitations to build, not evidence that their proposed businesses already work. They are also different kinds of documents: specific company concepts, founder requests, and open research questions. Their disagreements are as useful as their overlaps.

The essay develops ten opportunities. At the end, a full list turns all 65 current source topics into original build sketches, each with a possible customer and a test of whether the idea deserves to become a company.

Go directly to the 65 ideas.

The best AI companies will make people more capable without making them more captive.

The opportunity is in the unfinished transaction

Consider a small manufacturer receiving a customer order it cannot fulfill on time.

An assistant could summarize the problem. A useful system would establish which inventory is actually available, discover which substitutions the customer permits, calculate the new delivery date, and bring the right person a decision they can authorize.

The value is in closing the distance between understanding and resolution.

That distance contains several different problems. Some are computational. Some concern missing information. Others involve physical capacity, conflicting incentives, or the authority to act. Calling all of them an “agent problem” makes the market sound simpler than the work.

This distinction changes how I would evaluate a startup. Start with one unfinished transaction. Identify the person responsible for finishing it, the evidence they need, and the cost of getting it wrong. Then work backward to the technology.

A model is an input. A completed, acceptable outcome is a product.

1. Build the evidence business

My first bet is on products that make automated work inspectable.

Take an agent that changes a customer’s delivery commitment. The interesting record is not a transcript of everything it thought about. It is a compact account of the order, the inventory it checked, the rule it applied, the person who authorized the change, and the result recorded in the customer’s system.

An evidence business would produce that account as part of doing the work. It would also distinguish an action that was attempted from one that actually completed.

This sounds like bookkeeping until something breaks. Then it is the difference between a recoverable mistake and a week of forensic archaeology.

METR’s explanation of its own time-horizon research makes an important distinction: success on a benchmark does not establish reliable delegation in a workplace. Task context, verification, and intervention costs change the result. A capability curve cannot stand in for a customer’s acceptance test.

The initial product could serve one engineering team and one class of change. Sell a reduction in the time required to determine whether a release is acceptable. Count the defects that escape, too; a faster rubber stamp is a worse product.

This connects to Stephen Wolfram’s argument on Masters of Automation: linguistic interaction and precise computational representation have different jobs. My extension is that an agent should translate intent into something we can examine, calculate, and test.

Confidence is cheap. Evidence still requires work.

2. Give organizations a memory they can disagree with

The usual pitch for organizational memory is that a company should remember what it knows. I would add a more demanding requirement: it should remember how it might be wrong.

Suppose a supplier was rejected because its delivery performance was poor. Two years later, the supplier has changed ownership and rebuilt its operation. A system that faithfully repeats the old decision can make the company less intelligent.

Useful memory needs dates, sources, and conditions for reconsideration. It should separate an observation from an interpretation, and an active policy from an abandoned experiment.

I would start with the decisions a team repeatedly reopens: supplier selection, product exceptions, architectural tradeoffs. Show the evidence available at the time and what has changed since. The buyer is the operator who keeps paying to reconstruct the same conversation.

Baris Gultekin’s discussion of data strategy and reusable agent skills supplies the underlying connection. Capabilities become more useful when they can act on the right context. My additional claim is that context must remain contestable; otherwise, the company has automated its institutional prejudices.

The test is straightforward. Can a new employee make a better decision with the system than with search alone? Can they find the evidence that contradicts its answer?

3. Build shared authority into shared agents

YC’s current list includes collaborative agents. SPC’s earlier Summer 2025 edition also explores work shared between people and agents. The interface opportunity is real, but I think the harder product is deciding whose instruction counts.

Put sales, finance, and operations in a shared workspace. Sales wants to promise a delivery date. Finance wants a payment condition. Operations knows the goods are unavailable.

An agent that accepts the latest message as the controlling instruction has confused conversation with authority.

A compelling product would maintain a shared objective while making disagreements explicit. It would show which decisions are settled, which approvals remain open, and what changed after someone redirected the work. A handoff would transfer responsibility, not merely a chat link.

I would begin with customer implementation teams. Their work has a recognizable finish line, crosses departments, and produces expensive confusion when commitments diverge. Charge for a faster accepted handover, with fewer reopened issues.

The defensible asset would be a record of how teams resolve dependencies. More messages are not necessarily better coordination.

4. Make personal intelligence portable

The most consequential personal AI product may be the one that makes it easier to leave.

Consider the knowledge an assistant accumulates about someone: their preferences, commitments, family responsibilities, unfinished plans, and boundaries. If that knowledge works only inside one vendor’s product, switching assistants means paying a personal reconstruction cost.

I would build a user-controlled memory service with a narrow starting use case: coordinating a household’s recurring responsibilities across multiple applications.

The user should be able to inspect a remembered claim, correct it, decide which applications may use it, and remove it. A successful export should preserve useful meaning, not merely produce a large file that another system cannot interpret.

Ramesh Raskar’s Agent Zero and NANDA discussion places identity, trust, and interoperability at the foundation of a distributed agent ecosystem. That makes the question of ownership concrete. A personal agent must be able to represent a person across systems without surrendering their entire history to each one.

The commercial objection is obvious: portability can weaken retention. Good. It forces the company to earn the renewal through service rather than through the difficulty of departure.

That is a harder business to build. It is also a better definition of personal intelligence.

5. Give small software a long-term owner

YC is asking for simpler hosting for small applications. I would extend that into a broader obligation: every useful little tool needs someone, or something, responsible for its future.

A team can generate a purchasing tracker in an afternoon. Six months later, its creator has moved on, an integration has changed, and nobody knows whether the tracker is still sending information to the right place.

My proposed product is a maintenance subscription for the long tail of internal software. Each tool gets a named owner, a clear purpose, an operating budget, and a retirement date unless someone renews it.

Before expanding a tool, the system should be able to explain who depends on it. Before retiring it, the system should export its data and identify any work that would be interrupted.

The customer is the department that wants to build its own tools and the IT team that inherits the consequences. Both need a reason to say yes.

This is where “skills as the new apps” becomes an operating model. Capability can be small and modular. Responsibility cannot be optional.

6. Sell access to physical capacity

An important company can make AI more useful without looking like an AI company at all.

In its 2026 energy analysis, the IEA projects global data-centre electricity consumption rising from 485 TWh in 2025 to roughly 950 TWh in 2030. Those are forecasts for all data centres, not a measurement of AI alone.

Conviction’s linked inference proposal considers distributed gas-powered sites and workload routing. YC explores offshore compute. Both raise a question worth separating from the proposed location: what level of reliability does a particular job actually need?

A live conversation and an overnight batch of product descriptions have different tolerance for delay. An infrastructure business should make those differences usable and measurable.

I would begin with customers who can specify a deadline and accept flexibility in exchange for a lower completed-job cost. The test would include failed attempts, repeated work, and fallback capacity. A cheap hour that produces no acceptable output is not cheap compute.

Physical systems also resist elegant narratives. The IEA’s analysis finds that reliably serving critical, variable data-centre loads with onsite gas may require generation capacity 30–70% above demand. Software routing does not make equipment redundancy disappear.

The engineering opportunity is to match service promises to actual operating conditions. Geography is one variable in that calculation. It is not the business model.

7. Make experiments easier to falsify

I would be particularly interested in scientific infrastructure that makes a proposed result cheaper to challenge.

A research system could keep a live chain connecting a hypothesis to its protocol, measurements, analysis, and independent replication. A contradictory result would update that chain rather than vanish into a folder called “misc.”

This extends a question in SPC’s Winter 2025 collection about scientific communication beyond conventional papers. The company I would build around it would begin with a shared experimental workflow, not an attempt to replace the entire publishing system.

Choose one assay used by several laboratories. Agree in advance on what counts as a successful replication. Sell the reduction in uncertainty to the team deciding whether to commit more time and money.

The critical asset is the record of how results survive contact with a different operator, instrument, or sample. A large database of attractive findings without those distinctions may simply make error easier to retrieve.

This is the scientific version of the evidence business. Intelligence proposes. Reality gets a vote.

8. Build robots around recovery

A robot that performs a task in a clean demonstration has answered only part of the customer’s question.

The customer also needs to know who notices when the task fails, how quickly someone can intervene, and whether the recovery costs more than doing the work manually.

For an initial product, I would choose a repetitive task inside a controlled commercial environment and sell a service with an explicit exception budget. The machine’s appearance would follow the job.

Before expanding, I would ask the customer to introduce ordinary disruptions: a blocked path, a moved object, an unavailable destination. Measure the time to recover and the burden placed on staff.

That produces a much more useful dataset than a compilation of successful demonstrations. It also disciplines the economics. If every new location requires a permanent team of expert babysitters, the startup has scaled installations faster than capability.

The opportunity I find compelling is dependable physical service with a learning loop attached. Generality is something to earn through repeated deployment.

9. Make expertise available without hollowing out apprenticeship

Education and training should be judged by what people can do after the assistance is removed.

That principle matters for a child learning arithmetic and for a new technician learning to diagnose a machine. In both cases, an answer can arrive faster than understanding.

I would build an apprenticeship product that changes its behavior as the learner improves. Early on, it demonstrates. Then it asks the learner to predict the next step, explain the evidence, and identify the condition under which the procedure would be unsafe or inappropriate.

The assessment would be an unfamiliar task, not a replay of the lesson. A supervisor should be able to see which judgments the learner can make independently and which still require support.

SPC’s Summer 2026 education question is especially useful here because it asks whether removing difficulty can remove part of learning itself. That is a product design tension, not a reason to abandon personalization.

The buyer could be an employer with a persistent training burden. The promise would be a shorter path to demonstrated competence, with the standard of competence held constant.

The best tutor should gradually become less necessary.

10. Build the coordination layer around care

Care gives this entire discussion a more demanding test.

For a family managing an older relative’s needs, another persuasive answer may matter less than knowing whether the appointment happened, whether transport is arranged, and who will notice if nobody responds.

I would start with those coordination tasks. Give the person receiving care a clear view of what is being shared and with whom. Make responsibilities explicit. Let a family member confirm completion without turning every interaction into surveillance.

Clinical judgments and administrative assistance should remain visibly distinct. A scheduling tool does not become a medical authority because it can discuss symptoms fluently.

The first measure of value could be the time families spend chasing updates and the number of unresolved handoffs. Test whether the product reduces that burden without increasing the burden on the person receiving care.

This is a useful counterweight to the idea that every valuable AI product must maximize autonomy. Sometimes the product’s job is to help the right human show up.

The strongest objection: the platforms will absorb all of this

The skeptical case deserves more than a paragraph about “execution.”

Model providers can improve their products and bundle capabilities. Existing software companies already have customers, permissions, and a place in the budget. Hardware businesses can consume enormous capital before discovering that their service economics do not work.

Some apparent markets are temporary gaps between model releases. Some impressive prototypes are services businesses with their labor hidden. Some difficult industries are difficult because customers cannot pay enough to support a better solution.

All of that is compatible with the opportunity described here. It tells us how narrow the starting point should be.

I would ask a founder for a baseline: what does the customer do today, how long does it take, what errors occur, and who absorbs them? Then ask for a comparison that includes the entire delivery cost.

If the model became twice as capable tomorrow, would the company’s relationship with the customer become more valuable or unnecessary?

A durable business should own something that improvement makes more useful: a distribution channel, a trusted service, a physical operation, or evidence that others need. Difficulty alone is not a moat. It has to produce an advantage the customer values.

Public idea lists can also create a strange imitation game. Hundreds of founders can read the same request and conclude that it is their original insight. An investor’s interest is a useful signal. A customer’s willingness to change how they work is a different one.

Build the future people can leave, question, and improve

There are two truths to hold together.

Integrated systems can be excellent. Keeping the model, the data, and the workflow close together can make a product easier to use and operate.

The same integration can make dependence difficult to escape. A company can become more powerful by knowing more about its customer, even when the customer becomes less able to understand or challenge the system.

The resolution is a design obligation. Give people access to their evidence. Let them correct the record. Make authority revocable. Preserve a practical route to another provider.

For an employer, that means automation should leave behind a more intelligible operation. For a learner, it should produce greater independent competence. For a family, it should create more capacity to care for one another.

These are demanding requirements. They rule out some attractive shortcuts. They also give “abundant intelligence” a meaning beyond a falling price on a dashboard.

The future worth building is one in which a small business can command serious capability, a person can carry their context without surrendering it, and the systems acting on our behalf remain answerable to us.

Build the company that closes one important gap between knowing and doing. Then make sure the person on the other side has gained something they can keep.

The full list: 65 things to build

An idea becomes more interesting when you can picture its first customer. The sketches below turn the source topics into possible products, with a starting market and a condition they would have to satisfy.

These are my proposed company designs, not reproductions of the firms’ descriptions. They follow the current collections’ order; overlapping topics remain separate where they suggest different products. The companion catalogue contains the historical SPC questions and a compact cross-reference.

From Conviction’s 42 topics

The starting points come from Conviction’s collection. The product choices and commercial tests are my own.

01. The usable laboratory hour

A laboratory could buy a service that turns unused instrument time into completed experimental work. Start with one shared facility: reconcile sample readiness, technician availability, equipment setup, and the time a result is actually needed. The product should expose which missing dependency will waste tomorrow’s booking.

The first buyer is the facility manager. Charge against a measured improvement in usable capacity, with scientific quality held constant. A calendar that looks fuller while experiments fail more often has optimized the wrong thing.

02. The factory handover

Build a system that helps one production shift transfer its hard-won understanding to the next. A worker could record a defect, the conditions around it, the attempted fix, and whether it held. The next operator receives the relevant history when the same pattern appears.

Begin with a factory where product changes repeatedly disrupt quality. The operational advantage would be fewer rediscovered mistakes and faster independent troubleshooting. The evidence must survive the departure of the expert who originally supplied it; otherwise, the product is a searchable address book.

03. A passport for optical components

Create a portable record of an optical component’s test history that a manufacturer and its customer can both inspect. Connect test conditions to results, explain what changed between batches, and preserve disagreements about acceptance rather than smoothing them away.

An initial customer could be an equipment maker qualifying a new supplier. Sell reduced qualification effort. The hard part is getting both sides to trust the same record when a shipment is disputed. Useful infrastructure should remain useful precisely when commercial interests diverge.

04. The equipment confidence exchange

Build a service that makes previously owned power equipment easier to evaluate before a buyer commits. Organize inspection evidence, service history, compatibility questions, and independent assessments into a comparison a qualified engineer can review.

Start with one equipment category and a handful of repeat buyers. Earn a fee for making transactions more intelligible, without presenting incomplete records as certainty. The company becomes valuable if buyers can distinguish a sensible purchase from an expensive unknown more quickly than they can today.

05. The circuit acceptance desk

An analog design team could use an assistant that turns a customer’s performance requirements into an explicit acceptance plan. Every requirement gets a measurement method, an operating condition, and an owner who can resolve ambiguity before engineering work proceeds.

The first product would focus on one familiar circuit family. Charge for reducing late disputes and avoidable redesign. Its usefulness depends on exposing conflicting requirements early. A beautiful implementation of an incoherent specification is still a failed project.

06. The claim-status receipt

Build a tool for a small provider’s billing team that maintains a reliable record of what happened to each submitted claim. Separate preparation, submission, acknowledgment, requested corrections, and resolution. Show the human operator the underlying evidence for every status.

Begin with the recurring problem of submissions that appear complete but stall somewhere downstream. The buyer pays for less chasing and fewer missed follow-ups. The product should know when it lacks confirmation; inventing a tidy status is worse than admitting that the work remains open.

07. The prediction discrepancy notebook

Engineering teams need a disciplined way to learn from the difference between what a model predicted and what a physical test showed. Build a shared record that preserves the prediction before the experiment and links the eventual result to instrument conditions and manufacturing details.

Start with a team repeatedly redesigning one component. Sell a faster path from a surprising measurement to a better next experiment. The advantage is not a larger collection of plots. It is a defensible explanation of which assumption deserves to change.

08. A deadline market for compute

A customer submits a job with a deadline, a maximum price, and an acceptance test. A service decides when and where to run it, returning the accepted result and a clear account of any retries. The customer buys completion rather than managing the infrastructure schedule.

Start with workloads whose timing is flexible and whose output can be checked. The business works only if the full cost stays lower after fallback capacity and support. Test several simultaneous failures before treating a collection of cheap locations as dependable supply.

09. The application evidence room

Teams preparing complex applications could use a shared workspace that connects each factual assertion to supporting material and tracks unresolved questions. When a document changes, the system identifies which other statements may now need review.

The first customer is a technical project team coordinating outside specialists. Sell reduced document-reconciliation effort and clearer responsibility. Professional judgment remains visible: the product should label an interpretation as an interpretation, preserve its author, and make the underlying dated material easy to examine.

10. The change contract

Build a tool that lets a product owner and an engineering team agree on what a software change must preserve before an agent implements it. Record expected behavior, forbidden side effects, and examples of ambiguous cases. Attach the resulting evidence to the release.

Start with changes to a recurring commercial workflow, such as order amendments. The customer buys fewer disputes between “the tests passed” and “the business stopped working.” The product earns trust by finding an important misunderstanding before production, not by generating more documentation after it.

11. The robot incident rehearsal

A robotics operator could rehearse its response to a failure before putting a new machine into service. The product coordinates engineering, site staff, and support through realistic interruption scenarios, recording whether the right people recognize and resolve the problem.

Begin with one deployment environment and a limited set of ordinary disruptions. Sell a shorter path to an agreed operational readiness decision. A useful rehearsal changes staffing, design, or procedures. If it only produces a certificate, it has probably missed the valuable work.

12. The bug reproduction service

Chip teams could buy help turning an intermittent verification failure into a minimal, reproducible case. The system would preserve the original conditions, narrow the suspected cause, and produce an artifact another engineer can independently run.

Start with failures that currently consume days of back-and-forth between teams. Charge for accepted reproductions or a recurring engineering service. The decisive metric is whether the work changes a real debugging decision. A clever explanation that cannot be reproduced is another hypothesis for the backlog.

13. The exposure change journal

Build a service that tells a business and its insurance adviser when the underlying operation has materially changed. An expanded fleet, a new facility, or a changed system configuration should produce an understandable record with supporting evidence and a human review path.

The starting customer is an adviser repeatedly reconciling incomplete client updates. Sell better preparation and fewer surprises at review time. The product must distinguish a change in observed exposure from a justified change in price; those are different decisions with different requirements.

14. The decision that expired

Organizational memory should include a mechanism for retiring old conclusions. Build a tool that records why a decision was made, which assumptions supported it, and what future event should reopen it. A changed condition prompts a review rather than silently rewriting history.

Start with supplier evaluations or recurring product exceptions. The buyer is the team that repeatedly rediscovers the same argument. The test is whether people can find both the rationale and the strongest evidence against it. A company needs memory without turning yesterday’s judgment into permanent law.

15. The safe retry

Give agents tools that can explain whether an operation happened, whether it is safe to try again, and how to reverse it when reversal is possible. Begin with the unglamorous case of a connection dropping immediately after a change was submitted.

A developer integrating several external services is the first customer. Charge for supported operations and their maintenance. The technical promise is precise: uncertainty should not turn into duplicate orders, contradictory records, or accidental repeated messages. Reliability often begins with a good answer to “did that actually happen?”

16. Software with an expiration date

Build a managed home for the little tools employees create to solve local problems. Each application gets an owner, a purpose, a budget, and a date when someone must decide whether it still belongs in the company.

Sell the service to operations and IT together. The useful first demonstration is an application surviving its creator’s departure, then being retired without losing necessary records. Creating software can be delightful. Inheriting a mystery application with access to customer information is considerably less charming.

17. The unfinished-job company

Choose a narrow job that customers already pay to complete, then build a service around delivering its accepted result. One starting point could be reconciling inconsistent product information before a distributor releases a new catalogue.

The company would own the whole handoff: identify discrepancies, collect missing decisions, apply approved changes, and return a checked deliverable. Charge for the job. The test is whether each additional customer benefits from reusable operational learning, rather than requiring a new collection of heroic manual interventions.

18. The second pair of eyes

An experienced tradesperson could supervise more early-career workers if they received the right evidence at the right moment. Build a tool that helps a worker capture the job context, explain their intended next step, and ask a precise question when they reach the boundary of their competence.

Begin with an employer’s existing supervised training program. Sell less supervisor travel and better preparation for review. The system must make uncertainty easier to surface. Workers should gain judgment over time, rather than learn to obey a convincing voice.

19. The handoff wind tunnel

Build a simulated customer project in which agents and people must manage changing requirements, missing information, and conflicting commitments. The point is to discover how the team fails when everyone appears to be doing their individual job correctly.

An enterprise considering an agent deployment could pay to test its proposed workflow before using it with customers. Compare simulation findings with later pilot incidents. If the simulation cannot predict any meaningful weakness in the real operation, it is entertainment for the implementation team.

20. The business definition desk

An agent should be able to discover who can answer a semantic question it cannot safely settle. Build a service that routes disputed definitions to accountable owners: whether an order counts as delivered, which customer record controls, or what qualifies as an exception.

Start inside one cross-functional workflow. Charge for reducing the repeated reconciliation work between teams. The system’s value comes from recording explicit resolutions and their scope. A model that silently chooses between incompatible meanings can make the numbers agree while making the business less coherent.

21. The recovery operator

Build a robotics service whose specialty is the moment normal operation stops. For a defined class of machines and sites, provide the diagnosis, remote assistance, and local intervention process needed to restore useful work.

The first buyer could be an operator expanding beyond its initial location. Price around availability with carefully defined exclusions. The learning advantage would come from recurring failure patterns and faster recoveries. Expansion should reduce support cost per completed task; otherwise, the company is adding machines faster than it is learning.

22. The prospective prediction test

Create a service that helps research teams test a biological prediction before the eventual result is known. Freeze the model’s forecast, agree on the measurement, and preserve failures alongside successes. Make it difficult to select a flattering story afterward.

Start with a narrow experimental question and a customer deciding whether to fund additional research. Sell independent assessment of usefulness. The valuable record is a sequence of predictions made under uncertainty and checked honestly, not a retrospective demonstration assembled from favorable cases.

23. The internal-tool commissioning desk

Employees who know a business problem should be able to request a tool without having to design its access model. Build a guided commissioning service that translates their need into an application brief an administrator can approve and a developer or agent can implement.

The first customer is a department with a persistent backlog of small operational requests. Charge for applications that reach accepted use. The service should make ownership and permissions understandable before construction. Producing another prototype that cannot be approved does not clear the backlog.

24. The stale-record detector

Build a system that looks for disagreements between an organization’s official IT inventory and evidence of what is actually running. Each discrepancy becomes a question with an owner and a confidence level, rather than an automatic overwrite of the record.

Start with a team preparing a significant infrastructure change. The buyer pays to reduce uncertainty about dependencies. Measure whether the product discovers consequential omissions early enough to change the plan. A larger inventory is only useful if it becomes easier to trust.

25. The learning contract

A startup and its pilot customer should agree on what they are trying to learn before the first deployment. Build a product that records the baseline, expected improvement, unacceptable regressions, and the observations needed to make an expansion decision.

Sell to teams running multiple AI pilots. The service would make it harder to confuse usage with value or a convenient demonstration with representative work. Its success is a better decision, including an earlier decision to stop. A pilot that can only produce good news is a sales process wearing a lab coat.

26. The workload translator

Help a company evaluate whether its actual workload can move to a different computing system. Package representative jobs, identify dependencies, and compare accepted output, latency, engineering effort, and ongoing support under the same assumptions.

The first customer is a technical buyer investigating a second supplier. Sell the migration assessment and a maintained compatibility layer. The business depends on making alternatives usable, not on winning an isolated performance test. Switching is attractive only when the advantage survives the work required to switch.

27. Objects that obey their specification

Build a service that creates digital objects for one practical downstream use, then checks them against explicit requirements. A facilities team, for example, might need usable spatial assets for planning equipment placement rather than images that merely look convincing.

Begin with a constrained category and a known consuming application. Charge per accepted asset. The defining feature is a clear account of what was measured, assumed, or inferred. Visual plausibility should never quietly stand in for dimensional accuracy.

28. The meaning change alert

A field can keep the same name while changing what it means. Build a product that notices when the behavior surrounding a business metric changes and asks the responsible team to confirm whether its definition has changed too.

Start with a finance or operations group repeatedly reconciling reports. Sell fewer surprise disagreements at review time. The system should connect a changed definition to the reports and decisions that depend on it. Metadata earns its keep when it prevents a plausible number from becoming a misleading one.

29. The operation before the acquisition

Build a service that tests whether a proposed operational improvement works inside a business before an acquirer treats it as a reason to pay more. Start with one recurring administrative process and compare the current operation with a bounded, reversible pilot.

The customer is a buyer or owner trying to separate achievable improvement from spreadsheet optimism. Charge for the operating assessment. A credible result includes the cost of change, the staff time required, and the improvement that failed to materialize. The demonstration should survive without the person who sold it.

30. The incident hypothesis board

During an outage, a team needs to know which explanations have been checked and which remain open. Build a shared investigation board that attaches evidence to hypotheses, records contradictory observations, and prevents several responders from unknowingly repeating the same work.

Start with a service team whose incidents regularly cross organizational boundaries. Sell shorter investigation time and better handovers. The product should preserve uncertainty rather than prematurely nominate a culprit. A wrong explanation delivered confidently can cost more time than an honest list of remaining possibilities.

31. The merchant margin experiment

Give an independent merchant a disciplined way to test changes in product presentation. Track whether a proposed description, image, or offer improves the economics of completed orders, including returns and the cost of serving them.

Begin with one product category and an existing sales channel. Charge for managing experiments and recording what the merchant learns. The product should help the owner understand why a change worked. Increased attention without improved commercial results is a more elaborate way to stay busy.

32. The voice you can correct

A writing assistant should let someone inspect and edit its understanding of their communication preferences. Build a personal style record that distinguishes a stable preference from a choice made for one audience or situation.

Start with people who write frequently across different professional relationships. The subscription buys less editing without surrendering authorship. Test whether corrections carry forward appropriately and whether users can prevent a sensitive example from shaping unrelated messages. Sounding like someone should not require flattening all their relationships into one tone.

33. The event search desk

Build a video tool around a narrow operational question: what happened before a particular machine stopped, package disappeared, or workflow broke down? Let a reviewer search events while retaining access to the original footage and the uncertainty of the interpretation.

An initial customer could be a facility investigating recurring handling errors. Charge for supported sites and useful retrieval. Measure time saved on actual investigations and missed relevant events. The system must make it easy to challenge its description of what it saw.

34. The world friends keep making

Build a shared fictional world that remembers the choices a group of friends made together. Characters, places, and unfinished stories persist between sessions, but participants control the direction and can revise elements that stop being fun.

Start with small groups already organizing games or collaborative storytelling. A group subscription is a cleaner first business model than maximizing individual screen time. The test is whether people return for one another’s contributions. The best generated world gives humans more reasons to create together.

35. The reviewer’s evidence shelf

Build a workspace where a finance team can collect and inspect evidence for a defined internal control without repeatedly assembling the same materials. Keep the original record, the interpretation, and the reviewer’s decision separate.

Begin with a recurring evidence-gathering task the customer already understands. Sell lower preparation effort and fewer missing items. The product earns trust when an independent reviewer can reproduce the conclusion. Generating a polished explanation is useful only after the underlying evidence is sound.

36. The buyer’s representative

A purchasing assistant could work under a clear rule: the user pays, and the user can inspect why an option was recommended. Start with a narrow class of repeat household purchases, including the real cost of delivery, replacement, and inconvenience.

Offer a subscription or an explicitly agreed share of verified savings. The first test is whether the service saves more than it costs without creating new work. Any payment from a seller must be visible. An agent representing the buyer should make that representation economically believable.

37. The parallel-run company

Help an organization replace a legacy workflow by comparing old and new behavior before it commits. Feed both systems representative historical cases, investigate differences, and obtain explicit decisions about which behavior should be preserved or changed.

Start with one bounded workflow that can be evaluated without a full organizational cutover. Sell the migration and its ongoing verification. The scarce skill is deciding which surprising result reflects a bug and which reflects a business rule nobody documented. Faster translation alone does not settle that question.

38. The form completion companion

Build an accessible assistant that helps someone understand what information an official form requests, organize their supporting documents, and identify unanswered questions. Preserve links to the relevant official material and clearly label anything requiring clarification.

A possible first buyer is an organization that already helps people complete a particular application. Sell reduced repetitive administration while keeping assistance accountable to qualified staff. The test is more complete, understandable submissions with fewer unsupported assumptions. Ease of use should not come at the cost of accuracy.

39. The material substitution desk

An industrial buyer could use a service that evaluates candidate material substitutions against the requirements of its actual process. Record the baseline material, the proposed change, the test conditions, and the consequences the customer cares about.

Start with one component category and a repeatable evaluation method. Sell a decision-ready assessment, including reasons to reject the substitution. A promising property measured in isolation may not survive production. The company’s advantage would be learning which experiments expose that gap before the customer pays to discover it at scale.

40. Information with a freshness receipt

Build an information service that returns an observation with its source, collection time, and limits. A procurement team checking product availability, for example, needs to know whether a result is a current observation, an old listing, or an inference.

Start with one domain where stale information causes repeated expensive mistakes. Charge for dependable observations and updates. The customer should be able to set a freshness requirement and receive an explicit failure when it cannot be met. Silence about age is a poor substitute for reliability.

41. The phone call that closes

A telephone service should leave a small business with an accepted next step, not another transcript to process. Build around one type of call: collect the necessary context, establish what can be promised, and route exceptions to a responsible person.

Begin with a local service business whose staff already know the common cases. Charge for completed, accepted handoffs. Track repeat calls caused by confusion and the effort required to correct mistakes. A pleasant conversation is the beginning of the job; the caller still needs something to happen.

42. The employee change coordinator

Build a service that manages one employee change across the systems and people it affects. A transfer between teams, for example, can require decisions about access, equipment, reporting lines, and records that should no longer be shared.

The initial buyer is the operations team coordinating these handoffs manually. Charge for supported workflows and their maintenance. The product should show incomplete dependencies instead of declaring success after the first update. One correct record surrounded by five contradictory ones is not a completed transition.

From YC’s 13 Fall 2026 requests

The next group maps to YC’s current edition. These sketches emphasize a first product that can be tested before the larger ambition is taken for granted.

43. The tutor that steps back

Build a learning product that gradually reduces assistance as a child demonstrates understanding. The system should know when to give an example, when to offer a hint, and when to let the learner work through a difficulty without interruption.

Start with one foundational subject and a clearly defined age group. Parents or educators buy demonstrated progress, measured on unfamiliar tasks as well as familiar exercises. The product’s purpose is to develop the learner’s ability. A child who succeeds only while the assistant supplies the next step has not yet acquired it.

44. The component readiness record

Defense suppliers could use a shared evidence workspace for component acceptance, configuration changes, and maintenance history. Keep the product focused on documenting whether a delivered component meets the purchaser’s stated requirements and which evidence supports that conclusion.

Begin with a supplier struggling to reconcile engineering records with customer acceptance documentation. Charge for the workflow and maintained integrations. Its value would be fewer ambiguous handovers and faster access to trustworthy records. The system should preserve discrepancies for qualified review rather than automatically resolving consequential technical judgments.

45. A front door for tiny applications

Build a simple place where employees can discover, use, and take responsibility for small internal applications. A user should see what a tool does, what information it needs, who owns it, and whether it is still supported before relying on it.

Start with a department already producing its own tools. Charge for the managed environment. The first test is whether useful applications can spread without producing an equally rapid spread of unknown dependencies. Distribution should make ownership clearer as adoption grows.

46. The shared workroom

Build an agent workspace that several colleagues can enter while work is in progress. A newcomer should understand the objective, see the decisions already made, and contribute without forcing the group to reconstruct the entire conversation.

Begin with one collaborative job, such as preparing a customer implementation plan. Charge per team or active engagement. The difficult part is making interventions understandable: who changed the direction, what work became obsolete, and what still needs approval. A shared chat is useful; a shared understanding is the product.

47. The offshore operating trial

Before a company commits to a large offshore computing deployment, it needs to understand the combined operating burden. Build a service that helps an infrastructure team test remote access, maintenance procedures, connectivity, and recovery under a documented trial plan.

The first customer is an operator evaluating a site concept. Sell the pilot and its independently reviewable findings. The service has value even when the recommendation is not to proceed. A location that looks attractive on one dimension still has to function as a complete system.

48. The household loose-end service

Create a consumer assistant for recurring obligations that fall between existing apps: an unanswered repair request, a return approaching its deadline, or a reservation that still lacks confirmation. Give each item an owner and an understandable status.

Start with a small number of workflows a household can authorize explicitly. Charge a modest subscription and measure whether the service saves attention after setup and corrections are included. The path to a large consumer product begins with a small problem people are relieved to stop carrying.

49. Independence by agreement

Build a coordination product for an older adult and the people supporting them, with the older person’s preferences visible at the center. Agree on which updates should be shared, which tasks need help, and when someone should check in.

Start with appointments and transport rather than clinical decisions. A family or service provider could pay. The product should reduce chasing without making its main user feel managed from a distance. Success means more practical independence and clearer support, not a larger stream of surveillance data.

50. The mixed-work dispatcher

A site manager could use a dispatch system that treats each task as a set of requirements before assigning it to a person, a machine, or an agent. Show why the assignment is appropriate and what condition should trigger reassignment.

Begin with one facility and jobs whose completion is easy to verify. Sell lower total completion cost, including handoffs and interruptions. The system should learn from the cases that required a different kind of worker than expected. A sophisticated schedule is not useful if staff continually repair it by hand.

51. The settlement explanation layer

Build an operations tool that makes a digital-asset payment understandable to the business receiving it. Connect the incoming transfer to the expected invoice, preserve the supporting record, and surface mismatches for review.

Start with businesses already using that payment method. Charge for reconciliation and operational support rather than speculative financial exposure. Compare the complete workflow with the customer’s existing alternative. The useful promise is less uncertainty about whether an obligation was satisfied, regardless of the technology underneath the transfer.

52. The measurement that changes a decision

Build a physical sensing service around one decision the customer currently makes poorly. For a facility operator, that might be knowing which suspected equipment issue deserves an inspection before dispatching a technician.

Collect only the measurements needed to improve that decision and keep track of what the technician eventually finds. Charge for the supported operation. The test is fewer wasted interventions without more missed problems. A dense stream of measurements is an expense until someone can act on it better than before.

53. Permission behind the person

Build a service that helps an organization verify whether a request has the appropriate authority, not merely whether a familiar person appears to have sent it. Start with sensitive changes to supplier contact or payment instructions.

The product would establish a clear confirmation process, preserve its evidence, and route uncertainty to a responsible employee. Sell lower verification effort with stronger accountability. Being a real person does not automatically make a request legitimate. The decision needs to be tied to the particular action being authorized.

54. The obligation workbench

Compliance professionals could use a workspace that connects an obligation they have identified to the operating tasks, records, and reviews needed to address it. When an interpretation changes, affected work becomes visible for reassessment.

Begin with a narrow recurring process and qualified reviewers who can evaluate the output. Sell reduced reconciliation effort. The system should preserve the difference between source material, professional judgment, and completed operational work. A plausible summary is not evidence that an organization has done what was required.

55. The integration rehearsal

Build a service that tests a proposed API update against a customer’s actual usage before changing production. Identify affected workflows, prepare a migration, and show the differences in behavior on agreed test cases.

Start with one widely used integration and customers with similar patterns of use. Charge for ongoing maintenance. The useful result is an accepted change with a recovery path. If the service merely opens pull requests that engineers must investigate from scratch, it has moved the work rather than completed it.

From SPC’s 10 Summer 2026 questions

SPC’s latest collection found in this research leaves more of the answer open. Each sketch below chooses one possible experiment within the broader question.

56. The difficult-conversation practice room

Build an assistant that helps someone prepare for a conversation they still intend to have with another person. Let them rehearse a concern, recognize an assumption, and consider how their words might land without claiming to know the other person’s mind.

Start with professional coaching or manager development. A user or employer could pay for structured practice. The test is whether the user becomes better prepared for the real exchange. The product should strengthen their ability to engage with people rather than become a substitute for doing so.

57. Expertise for the overlooked customer

Create a service for customers whose problems are too small to justify the setup cost of conventional expert help. A small manufacturer preparing a first supplier questionnaire is one possible starting point: structured preparation could make a short specialist review economically practical.

The business would combine useful preliminary work with a clearly scoped professional handoff. Charge the customer for the completed service. Test whether a previously uneconomic transaction becomes worthwhile for both sides. Lower production cost creates a market only if someone values the result enough to buy it.

58. The flexible-load planner

Build a tool that helps a facility identify which energy-consuming activities can move in time without disrupting the operation. Translate production priorities into explicit scheduling boundaries and compare suggested changes with what actually happens.

Start with one site whose operations team can evaluate a limited pilot. Sell measured improvements in operating cost or reliability, including the cost of coordination. The company needs to understand the process behind the load. Moving demand is only helpful if the work it supports still gets done acceptably.

59. The understanding check

Build an assessment tool that gives a learner an unfamiliar problem and asks them to explain their reasoning, including where they are uncertain. The teacher receives evidence of misconceptions and partial understanding rather than only a score.

Begin with a subject in which educators can reliably review the assessment. Sell better information for choosing the next lesson. The system should distinguish a rehearsed explanation from transferable understanding. A polished answer can conceal confusion; the product’s job is to make that confusion useful for learning.

60. The model retirement service

An enterprise operating several specialized models needs a way to decide which ones still deserve to exist. Build a system that records each model’s purpose, dependencies, evaluation history, and operating cost, then identifies candidates for replacement or retirement.

Start with an organization already struggling to maintain several production systems. Charge for ongoing operational clarity. A useful test is retiring a model without degrading the workflow it served. The value may come from running fewer models better, rather than helping the company accumulate an impressive collection.

61. The robot-ready workplace

Build a service that helps a site identify the small environmental changes required for a machine to perform one useful job consistently. Examine the actual route or workspace, document recurring obstacles, and test the changed setup with the people who use it.

Start with a facility already considering a specific machine. Sell the assessment and implementation work. The customer should understand whether adapting the environment costs less than demanding more general capability from the robot. Sometimes the missing robotics feature is a better-organized room.

62. The personal context steward

Create a service that helps people inspect, correct, and carry the information their assistants use about them. Begin with a small set of recurring preferences and obligations, keeping an understandable history of who changed what and which applications received it.

The user pays for dependable stewardship. Test whether moving between two supported assistants preserves useful meaning and access boundaries. A data export that technically succeeds but leaves the person starting over is not portability. The product should make departure a normal operation, not a technical emergency.

63. The appointment preparation file

Build a patient-controlled tool for preparing a clear account of symptoms, prior records, questions, and personal priorities before a clinical appointment. Let the user review the account, correct it, and decide what to share with the professional they are seeing.

Start with the administrative difficulty of assembling a coherent history. The product could be paid for by users or a provider supporting appointment preparation. Test clarity and usefulness with both parties. Its purpose is a better-informed consultation, without turning an organized file into an unsupported diagnosis.

64. The device that explains itself

Build a connected-device experience in which the owner can see what the device observed, what rule it applied, and why it acted. Start with a bounded household or workplace function where an unexplained action creates frustration.

Sell the device or supporting software on the strength of dependable behavior. The user should be able to correct a preference and test the resulting change. The critical question is whether intelligence makes the object easier to live with. A device that needs continual negotiation has probably misunderstood the assignment.

65. A place to become useful

Build a community service around projects people complete together: repairing something, learning a craft, making a local resource better, or teaching a skill. Use AI for planning and coordination while leaving the achievement and relationships to the participants.

Start with an existing community that has willing members and too much organizational friction. Charge for participation or the coordination service. The test is whether people build abilities and relationships that persist outside the product. Meaning is a large claim. Helping someone become useful to another person is a concrete place to begin.

Masters of Automation keeps returning to what abundant intelligence should make possible for people. That argument continues in the newsletter, through the builders testing it in the world.

all signal, no spam.