PortalJS: state of the nation and next 6 months — conversion report

What the file claims

124 propositions, 124 roles, 68 relationships, 9 assumptions, 0 assessments.

goal 13 · conflict 5 · current_reality 73 · future_reality 11 · prerequisite 11 · transition 11

Revision 2 (2026-09-28). The SCQ is now frozen; this LTP is the working form. Adds reviewer comment 1 and Anuar's PostHog funnel analysis as sources:

• Goal: adds the stated near-term goal, the team using Arc/Studio to build many portals fast and demo them as outreach (g-e-team-builds-demos), with the framework mattering only as it supports Arc. The rev 1 funnel goal stays as a second, longer-term candidate. The reviewer flags the near-term goal as small next to the self-serve ambition (g-e-goal-small).
• Current reality: adds the PortalJS goal is undefined as a root cause, listing four candidate goals, with no owner named for any of them. Adds 11 funnel findings as evidence and effects.
• Removed: r-e-no-funnel-analysis and f-e-funnel-analysis, because the analysis now exists.

Revision 3 (2026-09-28) adds reviewer comment 2. It narrows the focus to government data portals and says self-serve sign-up is the wrong path for them:

• Goal: adds a third goal, win government data portal customers (g-e-win-gov-portals). Its conditions are a demo video plus book-a-call offer, and measuring calls booked. This partly answers r-e-goal-undefined; see call 9.
• Current reality: Cloud sign-ups were never serious and none converted. Buyers are governments, and they want to talk, so self-serve sign-up fails for them. Calls booked aren't tracked. Three possible markets are named. Datopian's PortalJS business is confined to government, outside enterprise.
• Conflict (drafted by Claude, parked by the reviewer): a government focus vs a self-serve publishing experience for data engineers as the route back into enterprise. The reviewer said the tension distracts energy, and asked to record it and leave it for now.
• Future reality: a government landing page with demo video and book-a-call; tracking calls booked; removing self-serve sign-up from the government path; and, if any self-serve remains, routing it through Arc and measuring portals deployed.
• Weakened: the Cloud sign-up collapse (r-e-cloud-signups-collapsed) now matters less, because those sign-ups weren't serious. Call 8 is largely moot.

Revision 4 (2026-09-28) adds reviewer comment 3, which settles the goal structure and asks for the next step:

• One goal for the next 6 months: win government data portal customers. "Team builds demos fast with Arc" is now a critical success factor under it. "Framework supports Arc" is a necessary condition under that. The rev 1 funnel goal and its two CSFs are re-roled to observation, and their two necessary_for links are removed. They stay in the file as a record, not as goals.
• Markets: "junior data engineers" and "the old DataHub market" are the same market: quick self-serve publication of one dataset or a catalog. r-e-three-markets and r-e-publication-market are reworded to match. There are still three markets: government portals, enterprise, and self-serve publication.
• Prerequisite and transition trees for the demo-and-call path, drafted by Claude. See Drafted plan (rev 4). Obstacles come from the sources where they can; objectives and actions are Claude's proposals, awaiting the reviewer's check. No conflict, prerequisite or transition view. See Not in this file.

Revision 5 (2026-09-28) adds reviewer comment 4. Outreach is the critical success factor; the site is minor:

• Goal tree under "win government data portal customers":
  • cold outreach carrying a prototype of the prospect's own portal (new CSF)
    • team builds demos fast with Arc (moved here from a direct CSF: prototypes exist for outreach)
      • framework supports Arc
  • known before RFP: be in the buyer's mind before their contract goes to RFP (new CSF)
  • RFP capability: most government contracts go via RFP, so we must respond well even when already in the door (new CSF)
  • demo video + book-a-call (kept)
  • calls booked measured (kept)
• Current reality: buyers don't arrive at the site on their own; most contracts go via RFP; a contact may be 12 months from renewal; a simple prototype of their site impresses buyers; power users building their own portals are a potential route to open-source users, awareness and an alternative marketplace (background; parked with the self-serve conflict, tracked as bead da-47g).
• Plan: the reviewer generally agrees with the drafted demo-and-call plan, and notes most of it applies whatever the channel. Action 7 now reads: link the landing page, and the prospect's own prototype where one exists, from every cold outreach email.
• Link to the e2e project: cold outreach and RFPs are the same biz dev engine as projects/e2e-operators (bead da-3y4: weekly biz dev day, prospecting tool, Daniela as champion). This file doesn't duplicate that plan. The overlap is natural and intentional (reviewer, comment 5).

Revision 5b (2026-09-28), reviewer comment 5: r-e-buyers-dont-arrive softened to most buyers, since some find the site or have used PortalJS first (as CDT did). The plan's actions are now beads under epic da-55j (the separate actions.md was later removed; beads are the only action list).

Revision 6 (2026-09-28): the current reality tree is rebuilt against the government goal. In rev 5 it was a list: 56 items, 31 unlinked, no core problem, and effects framed for the old self-serve goal. Claude proposed "effort drifted to self-serve" as the root cause. The reviewer rejected that (comment 6 P7: "I don't think it's that we drift into self-serve SaaS. That hasn't happened.") and named the causes below. The RFP win/loss analysis supplies the evidence.

                         FEW GOVERNMENT RFP WINS (3 of 30, to Jun 2026)
                         ▲ evidence: all 3 wins invited/relationship-led; 0 cold wins
      ┌──────────────────┼───────────────────────┬──────────────────────────┐
   causes             causes              contributes_to             contributes_to
      │                  │                       │                          │
 No prior contact:   Weak RFP responses:    Lost to OpenDataSoft ◀─causes─┘ (weak responses)
 we bid cold         don't show, criterion      ▲ contributes_to: quality not made visible
      ▲ causes       by criterion, that we      ▲ contributes_to: open source seen as cheap
      │              meet each requirement      ▲ evidence: Toulouse 41 vs 85
 LITTLE COMPELLING       ▲ evidence: Toulouse gaps;
 OUTBOUND / VISIBILITY     generic, non-compliant                   FEW PARTNERS in the
   (root)                  proposals                                jurisdictions we bid
   ▲ evidence: ~700                                                   (root) ─contributes_to─▶ few wins
     real visitors/mo    QUALITY NOT MADE VISIBLE (root)              ▲ partner often needed
                                                                      ✗ challenged: partner-led
                                                                        sub-bids have won nothing

Roots: little outbound/visibility, quality not made visible (few partners was dropped as speculative in comment 7), plus upkeep time unprotected (still linked to "upkeep dies"; call 12). The two the reviewer calls key are outbound and RFP response.

• Re-roled to observation (off the core tree, kept as record): the self-serve branch (r-e-little-self-serve, arc-cloud-compete, arc-earns-nothing, arc-free, arc-cloud-both-host, site-sends-nowhere, ctas-to-arc, cloud-signups-collapsed, freemail-blocked, cloud-low-activation, gov-want-to-talk, self-serve-fails-gov); r-e-goal-undefined (now resolved); r-e-stuck-in-gov (parked conflict); r-e-no-socrata-play. r-e-low-traffic becomes evidence of low visibility.
• Future reality: adds feature evidence per RFP criterion, partners in bid jurisdictions, and a refreshed RFP analysis.
• New bead da-4pl: refresh the RFP win/loss analysis (it's a June snapshot with 12 of 30 outcomes open).

Revision 7 (2026-09-28), comments 7–8. Closing state of this analysis.

• Root under outbound: "no dedicated, systematic biz dev time" is added as the root cause of little outbound (call 12, confirmed). Little outbound becomes an intermediate cause.
• Goal: adds "PortalJS stays visibly active" (changelog, community) as a condition of the government goal.
• The main engine (comment 8 P1): systematically build PoCs and email people, from the contact database already in Twenty (to be enriched). Added as a future-reality change, enabled by dedicated biz dev time.
• Owner: Daniela, proposed, because the path overlaps her biz dev role. To confirm (da-55j.1).
• Self-serve "someday": bead da-47g is deferred. It's not in the 6-month focus.
• New beads: 55j.9 systematic PoC + email outreach (P1, Daniela); 55j.10 OpenDataSoft feature comparison; 55j.11 RFP evidence pack; 55j.12 keep PortalJS visibly active.

Items

| g-e-win-gov-portals | goal | goal | comment 2 P7 | medium | "if we're focusing the goal right now, it's… government open data customers or data portal customers" | rev 3; call 9 | | g-e-demo-and-call | goal | critical_success_factor | comment 2 P7 | high | "a video demo or whatever and 'book a call' is what should be offered" | | | g-e-calls-measured | goal | critical_success_factor | comment 2 P7 | high | "That's what we should be measuring: how many calls got booked" | | | c-e-grow-portaljs | conflict | cloud_objective | comment 2 P5 | low | — | drafted: the reviewer names the contention but not the shared objective | | c-e-win-gov | conflict | cloud_requirement | comment 2 P3 | medium | "Our customers, like buying customers, are governments" | drafted | | c-e-energy-on-gov | conflict | cloud_prerequisite | comment 2 P7 | medium | "if we're on the focal audience for government data portals" | drafted | | c-e-reach-enterprise | conflict | cloud_requirement | comment 2 P4 | high | "we want to get back into enterprise, not to be stuck in this ghetto of government stuff" | | | c-e-energy-on-self-serve | conflict | cloud_prerequisite | comment 2 P4 | medium | "expand PortalJS… into what was the old data hub publication market" | | | r-e-signups-not-serious | current_reality | observation | comment 2 P1 | medium | "There was just spam or something like that… we didn't have a lot of serious signups" | | | r-e-no-signup-converted | current_reality | evidence | comment 2 P1 | high | "even in April, not one of those converted to a customer" | | | r-e-buyers-are-gov | current_reality | observation | comment 2 P3 | high | "Our customers, like buying customers, are governments" | | | r-e-gov-want-to-talk | current_reality | root_cause | comment 2 P3 | high | "they don't really need this [self-serve] experience… they just want to speak" | "learned with Joao"; "task experience" read as a transcription of "self-serve experience" | | r-e-self-serve-fails-gov | current_reality | intermediate_cause | comment 2 P7 | high | "This isn't a classic SaaS model… It's not going to work that way" | | | r-e-calls-not-tracked | current_reality | undesirable_effect | comment 2 P7 | high | "how many calls got booked, and that's not in Posthog" | | | r-e-stuck-in-gov | current_reality | undesirable_effect | comment 2 P4 | medium | "not to be stuck in this ghetto of government stuff" | | | r-e-three-markets | current_reality | observation | comment 2 P6 | medium | "Those are three different markets." | the three are read from a run-on sentence; call 10 | | r-e-publication-market | current_reality | observation | comment 2 P4 | medium | "there are a lot of people out there… data engineers" | Evidence.dev named as a comparable; left out of the statement | | r-e-self-serve-gateway | current_reality | observation | comment 2 P5 | medium | "they're also a gateway into more enterprise customers, potentially" | hedge kept as "potential" | | f-e-gov-landing | future_reality | injection | comment 2 P8 | high | "a dedicated landing page… is a video and a sign-up for a call" | | | f-e-track-calls | future_reality | injection | comment 2 P7 | high | "That's what we should be measuring" | | | f-e-drop-gov-signup | future_reality | injection | comment 2 P7 | high | "that's just a complete waste of time and should go away" | | | f-e-arc-deploys-metric | future_reality | injection | comment 2 P8 | medium | "if we want self-service signups, it would be people who are using Arc and deploying" | conditional in the source |

Confidence: high — one sentence states it. medium — hedged, assembled, or the view was a call. low — read from a question.

Relationships asserted

| g-rel-offer-for-gov | necessary_for | g-e-demo-and-call → g-e-win-gov-portals | comment 2 P7 | "for government, they really want at most a demo video and 'book a demo' or 'book a call'. That's what we should be offering" | | g-rel-measure-for-gov | necessary_for | g-e-calls-measured → g-e-win-gov-portals | comment 2 P7 | "that's what we really want to measure" — weak as necessity | | c-rel-gov-for-growth, c-rel-enterprise-for-growth, c-rel-energy-gov-for-gov, c-rel-self-serve-for-enterprise | necessary_for | the cloud's four arms | comment 2 P4–P7 | drafted structure; only the arms' contents come from the source | | c-rel-gov-vs-self-serve | conflicts_with | c-e-energy-on-gov → c-e-energy-on-self-serve | comment 2 P5 | "maybe we need to think about if that's a contention, because it does distract our energy" (assumption c-a-energy-limited) | | r-rel-talk-causes-self-serve-fails | causes | r-e-gov-want-to-talk → r-e-self-serve-fails-gov | comment 2 P7 | "It's just that people want a demo. It's not going to work that way" | | r-rel-no-conversion-supports-fails | supports | r-e-no-signup-converted → r-e-self-serve-fails-gov | comment 2 P1 | evidence offered for the same point; no single sentence | | r-rel-gateway-supports-publication | supports | r-e-self-serve-gateway → r-e-publication-market | comment 2 P5 | "they're also a gateway into more enterprise customers" — offered as why that market matters | | g-rel-demos-for-gov | necessary_for | g-e-team-builds-demos → g-e-win-gov-portals | comment 3 P1 | "yes prioritise gov data portal customers", accepting call 9's proposed structure | | p-rel-* (12) | overcomes / necessary_for | each intermediate objective → its obstacle and → p-e-path-live | drafted plan | drafted; plus the landing page as a condition of the CTA switch and the outbound links | | t-rel-* (10) | precedes / produces | the action sequence below | drafted plan | drafted | | g-rel-outreach-for-gov, g-rel-known-for-gov, g-rel-rfp-for-gov | necessary_for | each new CSF → g-e-win-gov-portals | comment 4 P1–P3 | "the critical success factor is outreach"; "We want them to be thinking about us before they come to RFP"; "we also have to do RFP as well" | | g-rel-demos-for-outreach | necessary_for | g-e-team-builds-demos → g-e-cold-outreach | comment 4 P1 | "That's why we want to build prototype demo portals: when we're sending an email to someone" (assumption g-a-prototype-impresses) | | r-rel-no-arrival-supports-low-traffic | supports | r-e-buyers-dont-arrive → r-e-little-self-serve | comment 4 P1 | "People are not going to just show up on our site." | | r-rel-outbound-causes-no-contact | causes | r-e-little-outbound → r-e-no-prior-contact | comment 6 P3 | "We haven't done outbound, so we don't generate inbound interest." | | r-rel-no-contact-causes-few-wins | causes | r-e-no-prior-contact → r-e-few-gov-wins | comment 6 P3 | "If we bid cold on RFPs, that's very weak." (assumption r-a-cold-bids-weak) | | r-rel-weak-responses-causes-few-wins | causes | r-e-weak-rfp-responses → r-e-few-gov-wins | comment 6 P1 | "we don't win RFPs effectively" | | r-rel-weak-responses-causes-ods | causes | r-e-weak-rfp-responses → r-e-lost-to-ods | comment 6 P6 | "I think that goes to poor RFP response" | | r-rel-invisible-contributes-ods | contributes_to | r-e-quality-invisible → r-e-lost-to-ods | comment 6 P6 | "less about product quality per se and more about making product quality visible" | | r-rel-perception-contributes-ods | contributes_to | r-e-oss-perception → r-e-lost-to-ods | comment 6 P5 | "People think open source is kind of cheap or poor quality" | | r-rel-ods-contributes-few-wins | contributes_to | r-e-lost-to-ods → r-e-few-gov-wins | Claude | drafted: ODS losses are part of the losses | | r-rel-partners-contributes-few-wins | contributes_to | r-e-few-partners → r-e-few-gov-wins | comment 6 P4 | "often you need a partner in a given country or jurisdiction to win" | | r-rel-*-supports (7), r-rel-partner-bids-challenges | supports / challenges | evidence → claim | RFP analysis, comment 6 P8 | evidence offered for the claim; partner-bid record counts against "partners win" | | r-rel-no-time-causes-little-outbound | causes | r-e-no-bizdev-time → r-e-little-outbound | comment 8 P3 | "yes lack of dedicated systematic bizdev time is an issue", answering call 12 | | g-rel-active-for-gov | necessary_for | g-e-product-active → g-e-win-gov-portals | comment 8 P3 | "we also want to keep the product active" — weak as necessity | | f-rel-time-enables-outreach | enables | f-e-dedicated-bizdev-time → f-e-systematic-poc-outreach | Claude | drafted |

Deliberately omitted

Judgment calls for the reviewer

1. The goal is read off the SCQ's question. The SCQ has no stated goal; L37 offers a "candidate framing". Its three parts became a goal and two CSFs, all low confidence. Confirm or rewrite before building on the goal tree. Is migration capture really necessary for a working funnel, or a separate goal?

2. Lost deals to OpenDataSoft are not linked to the missing feature comparison. The source puts them side by side but doesn't say one causes the other. If you believe it contributes, say so and it becomes contributes_to.

3. No link from the complications to r-e-little-self-serve. The SCQ implies Arc/Cloud confusion, Arc being free, hidden enterprise option, dying upkeep and marketing weakness all lead to little self-serve business, but never says so. These are the links most worth adding if you assert them.

4. Arc vs Studio naming kept out of propositions; still undecided.

5. Arc vs Cloud overlap not framed as a conflict. Could become a cloud (e.g. "keep Arc free to drive adoption" vs "charge for Arc so it earns"), but the source doesn't pose it.

6. Two goals, unlinked (rev 2). The near-term goal (team builds and demos fast) and the rev 1 funnel goal sit side by side. The format has no "higher-level objective", so they can't be nested. The reviewer's point is that the near-term goal is too small to be the whole answer. Deciding what PortalJS is for over 6 months is the main open question. It could become a conflict cloud: "use PortalJS as our internal outreach tool" vs "grow PortalJS as a self-serve product".

7. r-e-goal-undefined as root cause. It plausibly sits under several effects: the Arc/Cloud overlap, the CTA switch that emptied Cloud, Arc being free with no price. The source doesn't say so. If you assert any of those links, this becomes the critical root cause candidate.

8. The Cloud collapse has two candidate causes. The CTA switch (asserted, L180) and the paid search cut (correlation, L122). Only the first is linked. Rev 3: largely moot, since those sign-ups weren't serious (comment 2 P1).

9. Three goals now. Rev 1's self-serve funnel goal is contradicted for the government audience ("a complete waste of time"). Rev 3's win-government goal and rev 2's build-and-demo goal fit together: Arc builds demos, and demos plus calls win governments. I kept all three and linked none, because the format can't nest goals. Suggest: make g-e-win-gov-portals the goal for the next 6 months, g-e-team-builds-demos a condition under it, and retire g-e-working-funnel or move it to the parked conflict's self-serve side. I haven't done this without your say-so.

10. Three markets, read from a run-on sentence. I read them as government data portals, enterprise, and junior data engineers who might grow into enterprise work. The third may really be the same group as the "old DataHub publication market". Confirm. Rev 4: call 9 is resolved as proposed; call 10 is resolved (same market).

11. (Resolved rev 7: r-e-no-bizdev-time causes r-e-little-outbound.) Upkeep unprotected → little outbound? Rev 1's "upkeep isn't protected, so it dies" plausibly causes little outbound, and the e2e project says biz dev doesn't run constantly because delivery fills the week. Not linked: no source says so for PortalJS. It's the likely deeper root under "little outbound".

12. Visibility vs real gaps. The reviewer puts the ODS problem on visibility, not quality. But Toulouse named specific missing items (MFA, DR detail, data.gouv.fr harvesting, visualization types). Some may be real feature gaps. The ODS feature comparison would settle which.

13. Partners: helpful, but partner bids haven't won. The reviewer says a local partner is sometimes necessary and often helpful, not always required (comment 7); the RFP record shows 0 wins from sub bids through partners (Toulouse included). Both can hold: partners may help without being sufficient, or the partner model (Datopian as subcontractor, not controlling the narrative) is the problem. Recorded as challenges.

14. The parked conflict is mostly drafted. The contention and both arms are yours; the shared objective and the tree structure are mine. No injection yet: you parked it.

Drafted plan (rev 4)

Drafted by Claude at the reviewer's request. Nothing here is ratified. Obstacles cite a source where one exists. Objectives, actions and assumptions are proposals.

Implementation objective (p-e-path-live): government data portal buyers reach a demo video and book a call, and every call booked is counted.

Sequence (transition):

1 name owner + protect half-day
├─► 2 add call-booked tracking ──► 3 baseline: calls booked, last 90 days ─────┐
└─► 4 record demo video ──► 5 publish gov landing page ─┬─► 6 switch gov CTAs, ├─► 8 monthly review
                                                        │    drop self-serve   │    vs baseline
                                                        └─► 7 link from all ───┘
                                                             outbound

Expected effect: Datopian knows how many government calls PortalJS books each month and whether that number is rising.

Assumptions: a short video of a working portal is enough to move a government buyer to book a call; calls will be few enough that one person can take them.

Status (rev 5): generally agreed by the reviewer (comment 4 P5). Treat as the working plan; the open points below remain.

Open for the reviewer:

1. Owner. Who owns the path? Daniela already builds Arc demos and does partner outreach (see the e2e project), so she is a natural candidate.
2. Target. What number of calls a month counts as success by March 2027? The baseline from step 3 should set it.
3. Video. One generic video, or one per segment (city, state, national statistics office)?
4. Socrata. Governments leaving Socrata are government portal buyers, so a Socrata-migration variant of the landing page could fold in here. g-e-capture-migration is parked as an observation for now; should it become a CSF under the government goal?
5. OpenDataSoft comparison. Lost deals are to a government-portal competitor, so the comparison probably belongs on the landing page too. It has no plan yet.

Validator output

bun run check:import not run (no Reason Commons checkout; reviewer said the validator isn't needed). Local Python check passed: unique ids across entities, designations and relationships; every designation names an existing entity and parent; every relationship has one from and all ends in the same view; every entity designated. Rev 7: 124 entities (goal 13, conflict 5, current_reality 73, future_reality 11, prerequisite 11, transition 11), 68 relationships, 9 assumptions; every assumption names an existing relationship.

Not in this file

• A plan for anything but the government path. The parked self-serve conflict, the Socrata play and the OpenDataSoft comparison have no prerequisite or transition trees yet.
• OpenDataSoft feature comparison — to be created; likely its own doc under projects/portaljs-sep-2026/.
• July 2026 commercial brief (ref/2026-07-22-portaljs-queryless-arc-commercial-path.md) — context only, not extracted; parts (Queryless, Arc as Cloudflare frontend tier) are superseded.

Reviewer comment 1 2026-09-28

Paragraphs as numbered for locators.

P1. One of the issues is that our goal with PortalJS is not clear. Is it an open-source tool that is a lead generator for our Cloud or even our more detailed professional services work, as happened with the California Department of Technology, where they came because they tried out PortalJS? Is it a self-serve SaaS option? Is the Studio a self-serve SaaS option?

P2. PortalJS could even become the replacement for DataHub for self-serve: publishing datasets and data portals quickly, now that DataHub is becoming a data marketplace we curate quite heavily. The goal for PortalJS is a bit undefined. It's okay to have two goals, owned by different people or by us, but it's not clear what exactly we're doing there.

P3. The current goal: PortalJS is a tool for ourselves, so we can build many portals very quickly and do outreach. PortalJS, particularly Arc, is what we need. We don't need Cloud, and the framework only matters if it supports Arc. The goal is for us to use it as a team to build portals very quickly and demo them to clients.

P4. Still flag the point, even if that potentially resolves it. There are open questions, and that seems quite a small near-term goal, to be frank. It should do that, but what else could we be doing with this tool? The dream of self-serve is a big one, but we'll see.

P5. From here we drop the SCQ (keep it, don't update it) and work in the LTP trees.

Reviewer comment 2 2026-09-28

Paragraphs as numbered for locators. Lightly tidied from a transcribed conversation.

P1. On the funnel facts: there were 21 Cloud sign-ups in April, but some were just spam, and even in April not one converted to a customer. Generally we didn't have many serious sign-ups, not just in April.

P2. Did people ever schedule calls? A video plus scheduling a call is more realistic than sign-ups. Scheduling a call is really valuable nowadays: I once got on a call with a vendor within a day, didn't buy then, and bought from them a year later. Only a student won't book a call. Someone has to be available, but we won't get many calls.

P3. What we learned with Joao is that we are in a niche. Our buying customers are governments, and they don't really need the self-serve experience. They just want to speak to someone.

P4. We could expand PortalJS into what was the old DataHub publication market. There are a lot of people there, many working as data engineers. If the experience is competitive with Evidence.dev and similar tools, it's a way to get back into enterprise and not be stuck in the ghetto of government work.

P5. If there's a more self-serve experience, we need to think about whether that's a contention, because it distracts our energy. If we want to get back into enterprise, there is an opportunity there; it's a different audience. The much bigger self-serve audience is also a potential gateway into enterprise customers. Record it and think about it, but it's a completely different pathway; leave it for now.

P6. If we focus the goal now, it's on government open data or data portal customers. Are we after enterprise, more junior data engineers who might grow into other work, or government data portals? Those are three different markets.

P7. For government data portals, a video demo and "book a call" is what should be offered, and calls booked is what we should measure, not sign-ups. That's not in PostHog. This isn't a classic SaaS model: people want a demo. Self-serve sign-up won't work that way, so for this audience it's a complete waste of time and should go away.

P8. If we do want self-serve sign-ups, they should be Arc users deploying a portal; that's a measure of success, because they get something useful quickly. Cloud doesn't need self-serve sign-up at all. For the government audience, a dedicated landing page with a video and a sign-up for a call.

Reviewer comment 3 2026-09-28

P1. Junior data engineers and the old DataHub market are indeed the same: quick, self-serve publication of one dataset or a catalog. Agree on the goal structure: yes, prioritise government data portal customers. Agree on the next step (plan the demo-and-call path).

Reviewer comment 4 2026-09-28

Paragraphs as numbered for locators. Lightly tidied from a transcribed conversation.

P1. There are many more conditions. We have to do outreach: people are not going to just show up on our site, which is really minor in our view. We have to go out and do cold outreach. That's why we build prototype demo portals: when we email someone, it comes with a screenshot or even a video and a site they can check out. It might not be perfect, but showing we built a simple prototype of their existing site impresses people. The critical success factor is outreach.

P2. This may pay off in the medium to long term. We might get something in front of someone whose contract is only up for renewal in 12 months, but we're in their mind now. We don't want to just be coming to an RFP call; we want them thinking about us before they come to RFP.

P3. We also have to do RFPs, because most government contracts go via RFP, so even if we're in the door we need to do that.

P4. As background notes and beads: explore other simple uses of PortalJS, like empowering power users to build their own portals. That's the real way into more open-source users, more awareness, more free marketing, and possibly an alternative marketplace.

P5. Generally agree on the plan for the demo-and-call path. Much of it is relevant whatever we do: in cold outreach we'll send a PoC (if built) plus probably a link to a landing page.

Reviewer comment 5 2026-09-28

P1. On current reality: most buyers don't come on their own. Some may, or at least have used PortalJS first. Minor. The overlap with e2e is natural and intentional. Next: create the actions.

Reviewer comment 6 2026-09-28

Paragraphs as numbered for locators. Lightly tidied from a transcribed conversation. Responds to Claude's proposal that "PortalJS effort drifted to self-serve" was the root cause.

P1. I don't think the root cause is that. We don't do a lot of outbound marketing in a compelling way, and we don't win RFPs effectively. Those are the two key things.

P2. We've lost a lot of RFPs. There's a separate analysis about this. We might be getting better.

P3. We haven't done outbound, so we don't generate inbound interest. If we bid cold on RFPs, that's very weak.

P4. We also sometimes lack partnerships. Often you need a partner in a given country or jurisdiction to win: bidding on a French portal, you need a French partner.

P5. Against OpenDataSoft, we may not be showing what we can do strongly enough. People think open source is cheap, poor quality, or missing features. We scored poorly on the evaluation in the Toulouse data portal bid against OpenDataSoft. Genuine or biased, we should have been able to tick the boxes: we can do this, here's a demo, here's the feature.

P6. That goes to poor RFP response, but it might also be related to product quality. It's less about product quality per se and more about making product quality visible.

P7. I don't think we drifted into self-serve SaaS; that hasn't happened. We haven't done outbound as needed, or got visibility in other ways, and we haven't been strong on RFPs to follow up when we have had openings.

P8. What we do see is that inbound interest is powerful. When someone has seen something, we contact them, and they're in touch before an RFP, we are often more likely to win.

P9. The RFP data is in a separate project; I don't know how up to date it is. If it isn't, refreshing it is a task: analyse what's been going on.

Reviewer comment 7 2026-09-28

P1. We don't absolutely need a partner in every jurisdiction where we bid. A partner is sometimes necessary and often helpful.

Applied: r-e-local-partner-needed, r-e-few-partners and f-e-more-partners reworded to match.

P2. Agreed with call 14 that partners as a cause is very speculative: it's not clear partners are an issue.

Applied: partners removed from the causal tree. r-e-few-partners re-roled root_cause → observation; f-e-more-partners re-roled injection → observation; r-rel-partners-contributes-few-wins deleted. The evidence (r-e-local-partner-needed, r-e-partner-bids-lost and the challenges link between them) stays as an open hypothesis. The refreshed RFP analysis (da-4pl) could test it: do bids with a local partner win more often than those without?

Reviewer comment 8 2026-09-28

P1. Agreed on the gap: add the RFP-response actions.

P2. The main thing is systematically building PoCs and emailing people. We already have a database of potential contacts in Twenty, though it could be enriched.

P3. On call 12: yes, the lack of dedicated, systematic biz dev time is an issue. We also want to keep the product active.

P4. Daniela as owner, as it overlaps with her biz dev responsibility.

P5. Note the work on a self-serve option as "someday". Then close this out with beads for the immediate next steps.