Back to Dashboard

Three paths, one mission

Poysis • 4/21/2026 vision

Thanks to the session with Francess, there is no confusion as to what Poysis is building.

[!NOTE] Both Francess and Ismail are faculty members at Tangent by Greylight Capital. Their insights and critical feedback during the program have been instrumental in refining the Poysis strategy.

We are giving domain experts the tools to develop co-pilots. We plan to aggregate the logic embedded into these co-pilots into a discovery engine trained on how experts believe decisions should be made in different domains.

When I say data, I don’t mean their databases or their documents. I mean the pipelines. The tradeoffs. The decisions each co-pilot is configured to consider. That’s the layer nobody is capturing today, and it’s the layer that makes a real discovery engine possible.

The Strategy of Sequence

We could build this directly, like Turing — hire domain experts and pay them to encode their knowledge. But we don’t have the capital for that, and we don’t have the time. And even if we did, building the discovery layer directly is the wrong move right now.

The data we need hasn’t been collected anywhere yet. The experts aren’t sitting around waiting to be hired. We’d be paying to build a dataset from scratch when there’s a better way: build a tool experts want to use, and the dataset builds itself.

[!IMPORTANT] We must first be mercenary before we can be missionary.

That means hyper-focusing on Poysis, the no-code AI co-pilot builder. If we do this right, we generate revenue quickly and earn the right to the kind of funding we need to truly build the discovery engine we dream of.

Revenue isn’t the goal. Revenue is the permission slip for the work we actually care about.

Evaluating the Enterprise Path

So if the sequence is mercenary first, then missionary — how do we go about it?

Based on Ismail’s recommendation, we ought to focus on enterprise. This makes a lot of sense. Enterprises have plenty of domain experts who would like to encode their knowledge into internal co-pilots. This is a real need, and if we figure out business development, it’s a viable path to revenue.

But this path offers three options, and the choice matters more than it looks.

Option 1: Poysis Templates

We identify the most common and pressing use cases the Poysis primitives solve, and we deploy them as templates. Much like how we used the search primitive to power Product Scout.

  • The Appeal: Templates are productised, repeatable, and close to the revenue we need. Customers come in, pick the template, configure, and deploy.
  • The Trap: Over time, the templates bloat. The codebase fragments. What started as a platform becomes a portfolio of point solutions. We end up maintaining too many products, and the platform work gets starved to keep the templates alive.
  • The Mission Impact: Templates don’t generate the data we need. The expert reasoning never gets encoded because the template already made those decisions for the builder. The fuel for the discovery engine is never collected.

Option 2: Service Business

Many enterprise clients want something custom-made. We go in, build bespoke, and charge by the engagement.

  • The Reality: This is the shortest distance to revenue. I’m already doing it with the Emerson Curl Concierge. I could build ten more; the demand is real.
  • The Problem: A services business has no compounding. Every new client is a new build. Every build competes with the platform work.
  • The Character Risk: When the time comes to choose between the mission and the money, will we have the discipline to choose the mission? The “eventually” platform almost never happens. The platform becomes a side project, and the mission becomes a slide in an old pitch deck.

Option 3: Poysis as Enterprise Infrastructure (The Choice)

Launch Poysis as we originally planned, but sell it to enterprises — with white labelling, dedicated onboarding, and co-build engagements. We don’t become their contractor; we onboard them onto the platform.

[!TIP] This is my favourite option, and not by a small margin.

Focusing on enterprise here doesn’t change the product; it refines the distribution. The platform stays the product. The enterprise just becomes a better first customer than the individual domain expert ever was.

Why Option 3 Wins

Every enterprise build on Poysis generates the data we actually care about. Not their business data — the pipelines. Every co-pilot built on our platform encodes a domain expert’s reasoning in the schema we designed:

  1. Override rules
  2. Conflict resolution heuristics
  3. Dependency maps

Across twenty enterprises and fifty domain experts, this becomes something that doesn’t exist anywhere else in the world: a cross-domain record of how human expertise is actually organised.

The curl specialist and the financial advisor use the same override patterns, even though they share no vocabulary. Poysis sees both, and over time can start learning the general structure of how experts reason.

That’s the discovery engine. Not a thing we stop our business to build — a thing our business was already building while we got paid for something else.

The Path Forward

The mercenary and missionary activities are the same activity, observed at different time horizons. That’s the test every option has to pass. Only Option 3 passes it.

The roadmap is clear:

  • Sell Poysis as the infrastructure layer.
  • Help enterprises stand up their first co-pilots.
  • Let the dataset quietly compound as experts map their logic.

It won’t be effortless. Enterprise sales have longer cycles, and we must balance co-build support without backsliding into consultancy. But it is the only strategy that drives revenue while actively constructing the discovery engine.

The discovery engine is the natural consequence of Poysis operating at scale. We know what we are building, and we know exactly how to fund it.

Now, we just have to execute.