Submit offer Pathfinder

1. GENERAL INFORMATION:

• Pathfinder (working title)
• Accelerace Management A/S
• Ole Maaløes Vej 3, 2200 København N
• CVR nr.:  32163289
• For further questions, contact info:  Mads Løntoft: mlo@accelerace.io / +45 21425125

2. PRESENTATION OF COMPANY:

Accelerace: https://accelerace.io/

3. DESCRIPTION OF THE TASK UNDER MARKET EVALUATION:

The proposed project is the design and development of an AI-driven tool with the current working title “Pathfinder”. It is an AI-powered software tool designed to assist founders and mentors in mapping out what startup-specific success and key outcomes look like within a given time frame.

From the identified high-level goals, Pathfinder helps founders progressively reverse-engineer these into the preconditions that must be true, testable hypotheses, concrete outcomes, and actionable tasks - through a structured, multi-step dialogue with an AI thought partner. The tool is designed to challenge and validate the founder’s thinking at every stage, ensuring that plans are rigorous, assumption-aware, and grounded in evidence where possible.

At its core, Pathfinder would serve three functions:

• Outcome mapping and progressive decomposition. Starting from the founder’s high-level target(s) (e.g., close a funding round or achieve specific growth milestones as two basic examples), the tool guides a multi-step decomposition through dialogue. In the first step, the goal is established and its underlying rationale examined. In subsequent steps, the tool helps identify what must be true for the goal to be achievable, then decomposes each precondition into testable hypotheses, measurable outcomes (both binary and progressive), and concrete tasks. At each step, the AI actively challenges assumptions, pushes for specificity, surfaces gaps in the plan, and references relevant benchmarks or data points where available. The process is hypothesis-driven: each element in the map should represent a specific, testable claim about what the startup needs to achieve, not a generic category.
  
  
• Progress tracking and visibility. Throughout the program, both founders and mentors can track progress against the mapped outcomes. This creates a shared, living view of where the startup stands and allows needed adjustments to be made in due time. A central aim is to make mentor sessions more focused and program check-ins more substantive. The map should support versioning, so that when the plan changes - as it inevitably will - previous versions are preserved. This creates a learning record of how the startup’s understanding and strategy evolved over time, which is valuable both for the founder and for the program’s institutional knowledge.
  
  
• Resource matching. By understanding where a startup is in its journey and what outcomes it is currently working toward, the platform can surface relevant resources from within the Beyond Beta ecosystem. This could be specific mentors, courses, workshops, partners, voucher opportunities, etc., when they are most useful. (May be out of scope for first version).

How It Would Work
A startup entering a Beyond Beta cohort would (either alone or in collaboration with a mentor) begin by defining their target outcomes for a specific period of time, e.g. the program duration, end of runway, or another relevant time horizon. Depending on the type of startup (organic growth / venture potential), Pathfinder guides them through a structured, multi-step process.

The process works through progressive layers of decomposition, where each step goes deeper:

• Main Goal / Thesis: The top-level entity. Represents the startup’s overarching target for the set time period. For venture-track startups, this is typically a funding milestone. For organic-growth startups, it could be a set of growth and profitability targets. The AI does not simply accept the stated goal - it examines the rationale: Why this target? What assumptions underpin it? What does achieving it unlock? This ensures the foundation is solid before building on it.
  
  
• Preconditions (what must be true): The next step identifies the key preconditions that must hold for the goal to be achievable. These are the critical pillars of the plan. The AI helps ensure these are collectively exhaustive and that no critical dimension is overlooked. Preconditions are framed as statements of what must be true, not as activities.
  
  
• Outcomes: Under each precondition, the model maps specific outcomes that demonstrate whether the precondition is being met. Outcomes can be either binary (a hypothesis to validate or invalidate, such as “our target customer will pay for this product at our target price point”) or progressive (a metric moving toward a quantitative target, such as “reach €20K MRR”). The system must support both types natively, with appropriate tracking mechanics for each. Outcomes typically fall within dimensions such as market, product, team, and financials, but the system should support additional or alternative dimensions as the startup’s context requires.
  
  
• Hypotheses: The assumptions that underpin each outcome. These represent what must be true for the outcome to be achievable. Hypotheses are testable and have a validation status (not started, testing, validated, invalidated). Each hypothesis should be linked to evidence that supports its current status. The framing should be specific and falsifiable - not “customers want this” but “clinic owners with budgets over €50K/year will pay €500/month because the cost of the status quo exceeds that amount.”
  
  
• Tasks: Concrete work items that test hypotheses or advance outcomes. Tasks have a status (planned, active, complete) and can have due dates. Tasks are the most granular level of the outcome map.
  
  
• Dependencies: Outcomes can have explicit dependencies on other outcomes. The system models these as directional relationships (Outcome A must be resolved before Outcome B can meaningfully be pursued). Dependencies can cross dimensions - for example, a product outcome may depend on a market validation outcome. The AI should proactively surface these dependencies and help identify sequencing issues and flawed logic.
  
  
• Sector and stage adaptability: Pathfinder must adapt to different types of startups and sectors. An AI-first startup’s path to Series A has different decomposition patterns, risks, and benchmarks than a biotech or SaaS company. The tool should be capable of bringing domain-relevant knowledge into the dialogue - initially through the human mentor’s input, and over time through accumulated institutional knowledge and research capabilities. The dimensions, preconditions, and typical risk patterns should reflect the startup’s specific context, not follow a generic template.
  
  
• The AI as rigorous thought partner: A critical design requirement is that the AI does not simply accept and structure what the founder says. It must act as a rigorous thought partner that challenges weak reasoning, pushes for evidence behind claims, surfaces blind spots, and ensures that the decomposition is logically sound. The AI should behave more like a senior strategic advisor than a note-taking assistant. Over time, the system should be capable of incorporating multiple advisory perspectives - technical, commercial, financial, investor - into its challenge of the founder’s thinking. Provided sufficient context, the Pathfinder should help founders think through their plans more rigorously, while keeping the human (founder and mentor) in control of the decisions of what to ultimately prioritize.

Note that these are initial considerations for what the tool could look like. Part of the delivery is to conceptualize this further with a strong foundation in what is needed for a valuable solution.

A Collaborative Workspace Model
The workspace should support interaction patterns that allow the user to see the full picture at a high level and then drill into any specific area for detail. The specific visual representation - whether a tree structure, concentric layers radiating from the central goal, a spatial canvas, or other approaches - is to be explored and determined during the discovery and UX design phase. The key requirement is that the visualization clearly communicates the logical structure of the decomposition, the relationships between elements, and where gaps or underdeveloped areas exist.

The workspace should feel like a co-creation tool that actually invites for collaboration and iteration, not a simple static dashboard. Founders and mentors should be able to add, edit, rearrange, and remove elements interactively, in a manner similar to working on a shared whiteboard or visual canvas. The AI assistant is available at every level, offering context-specific insights, gap analysis, and suggestions.

The initial setup process is designed as a collaborative dialogue rather than a form. The founder begins by working with the AI to build the first version of the outcome map through a progressive, step-by-step conversation. Rather than the AI proposing a complete decomposition for the founder to review, it builds the map incrementally - establishing the goal first, then working through each subsequent layer of depth together, ensuring shared understanding at each step. The mentor is invited (either in parallel or after founder’s first iteration) to the workspace, reviews the map, adds their perspective, and co-edits. This initial co-creation phase is critical to building shared understanding and ownership of the plan.

A core design principle is that periodic check-ins must provide enough value to the founder that engagement is self-motivated. The check-in should feel like a useful reflection exercise, not an administrative burden. The AI facilitates this by asking targeted questions based on the current outcome map. The AI should ideally be able to infer status updates from the conversational response to update the map, minimizing the founder’s manual data-entry effort.

The exact cadence and format (purely conversational, structured form, or a hybrid) is to be determined during discovery. However, the design principle is non-negotiable: if founders perceive check-ins as overhead, the system fails. The AI must do the heavy lifting to keep the map current and relevant.

Value Proposition

For Startups
A clear, structured foundation for what to work on to achieve meaningful goals. Rather than navigating with vague goals, founders get a concrete, hypothesis-driven roadmap that adapts as they learn. The AI-assisted approach surfaces blind spots and ensures that critical assumptions are being tested rather than taken for granted. The progressive decomposition process itself is valuable - it forces founders to think more rigorously about their plans than they otherwise would.

For Mentors
A shared reference point for the overall acceleration program and for every session. Instead of a vague sense of what should happen over the course of the acceleration program and spending a lot of time getting up to speed on what’s happened since last time, mentors can see progress at a glance and focus their guidance on the areas where the startup most needs support.

For the Program
Better oversight, more targeted interventions, and a data-driven sense of cohort progress. Over time, the Pathfinder could potentially generate insights about which types of support are most effective at different stages, helping Beyond Beta refine its program design and offering. The versioned maps across cohorts create institutional knowledge about startup development patterns. This is to be explored much further before implementation.

4. TASK OBJECTIVES AND SUCCESS CRITERIA:

The project consists of the following deliverables:

Phase 1:

Discovery and detailed requirements definition, full concept development for phase 2. This must be agreed before proceeding with full implementation of phase 2.

Phase 2:

Development of core functionality: goal decomposition dialogue, outcome mapping, hypothesis tracking, and basic progress visibility for founders and mentors. Must include Sector and stage-specific adaptability (domain-tailored decomposition patterns, benchmarks, and risk profiles)

• Technical architecture and API integration design (see below)*
• UX/UI design for the core workspace
• Pilot deployment with one Beyond Beta cohort

* Technical architecture. The solution must expose a well-documented API that enables integration with our existing platform (Laravel/PHP). Beyond this integration requirement, the supplier is free to propose the internal technology stack they consider most suitable for an AI-native application. We prioritize a modern, maintainable codebase with thorough documentation and knowledge transfer over alignment with a specific language or framework. The supplier should justify their technology choices in the proposal.

Requirements for the solution:

The supplier's proposal should address the following requirements:

Data security and privacy. Startups using Pathfinder will enter sensitive business data including financial information, competitive positioning, IP-related hypotheses, and team assessments. The solution must ensure strict data isolation between startups, so that no startup's data is visible to or accessible by another. The supplier must address encryption (at rest and in transit), access controls, GDPR compliance, and how data is handled in relation to any third-party AI model providers.

Data input and context acquisition. The tool's ability to provide meaningful guidance depends on the quality and breadth of context it can work with. The supplier should propose how the tool acquires the information it needs, including conversational input from the founder (the primary channel), the ability to incorporate uploaded documents (e.g. pitch decks, financial models, market research), and the potential for integration with external data sources for benchmarking and validation. The architecture should be designed to accommodate multiple input channels over time.

Structured data collection for learning. The design must ensure that data generated through Pathfinder sessions is captured and structured in a way that enables learning and analysis over time. As the system accumulates data from multiple startups and cohorts, it should become progressively better at identifying patterns, surfacing relevant benchmarks, providing sector-specific guidance, and identifying common risks and success factors. This requires that the data architecture is designed for this purpose from the outset, not retrofitted.

Data architecture. Outcome maps, hypotheses, validation statuses, evidence, and session histories must be stored in a structured, queryable format, not locked inside unstructured chat transcripts. The data architecture must be designed from the outset to support future cross-cohort analysis, pattern recognition, and program-level reporting.  The supplier must demonstrate that individual startup data can be queried and exported in structured form and lay the foundation for full cross-cohort analysis capabilities.

Model selection and cost management. The supplier should address which foundation models the solution will be built on and how operational costs will be managed at scale. This includes strategies for efficient token usage (e.g. context management, caching, routing between models of different capability and cost), and a cost projection for running sessions at scale (e.g. 50 startups conducting regular sessions over a program cycle). The cost per session must remain sustainable as usage grows.

Working model and collaboration. We expect a close, iterative collaboration with the supplier throughout the project. This is not a traditional handoff engagement where requirements are delivered and the supplier works independently until completion. We expect regular alignment sessions, joint discovery workshops, and the ability to adjust direction based on learnings from own and user testing and pilot feedback. The supplier should describe their proposed working model and how they ensure continuous alignment with our team. We have development resources that will be deployed in the project as well and it is important to ensure we work in tandem, so that we can take over this project once the delivery is complete for further development and maintenance.

Specific supplier requirements:

• Demonstrated experience building AI-native applications (not just adding AI features to existing products). Preference for specific examples of AI-driven user experiences, not just chatbot wrappers.
• Deep experience with LLM integration patterns: prompt engineering, context management, structured output generation, and retrieval-augmented generation (RAG), eval structures etc. that we can learn from and implement.

A working MVP covering Phase 2 scope must be ready for pilot deployment with a Beyond Beta cohort starting in early October 2026. The supplier should include a delivery timeline in their proposal that accounts for discovery, development, and a testing period before pilot launch.

5. BUDGET OG SPECIFICATION OF AN OFFER

Phases 1 and 2 – scope and budget framework

Phases 1 and 2 are to be considered as one consolidated assignment. Consequently, an offer must include a proposal for the delivery of both Phase 1 and Phase 2.

The total maximum budget for the assignment (Phases 1 and 2 combined) is DKK 800,000 excl. VAT. The bidder must describe how the overall assignment is proposed to be delivered and how the total budget is intended to be allocated between Phase 1 and Phase 2.

The contracting authority reserves the right, following completion of Phase 1, not to proceed with the development of Phase 2 if the outcome of Phase 1 is assessed as unsatisfactory. In such case, Phase 2 will be cancelled and the corresponding part of the assignment and budget will lapse.

We expect a written offer to include at least:

• Date of submission of the offer. It is important that the offer is clearly dated.
• A brief presentation of the bidder, stating the CVR number and contact details. Where relevant, including references and company history.
• The bidder’s proposal for solving the task.
• A specification of the price for solving the task, including how the budget is proposed to be allocated between Phase 1 and Phase 2, as well as an overview of the estimated time allocation for the development of Phase 1 and Phase 2.
• Hourly rate applicable in the event of purchase of additional hours.
• Discount, if relevant.
• Timeframe and expected end date.
• Conditions for the offer, if any

6. BACKGROUND FOR THE TENDER:

Beyond Beta is subject to a number of requirements for good, healthy financial management, including documentation that the agreed price for external purchases is an expression of the market price. This tender is part of these requirements. We emphasize that the bidder must only make an offer on the requested task. Services of executing or implementing nature cannot be approved. The winning bid is chosen based on an assessment of the best correlation between price and quality.