When you sit down to build a strategy execution platform, the architecture practically draws itself. Goal layer on top. Integrations below. Build a clean OKR interface, connect it to Jira and Asana and Monday, let each team's tool of choice continue doing what it does, and sync the status up to your dashboard. It's the safe bet. Every competitor in the space has made it.
We didn't. And the reason isn't aesthetic. It's that the integration approach quietly fails at exactly the moment a leadership team most needs it to work.
The integration promise — and what it actually delivers
The integration model offers a specific, attractive promise. You don't have to change how your teams work. Engineers stay in Jira. Marketing stays in Asana. Design stays in whatever it's using this month. The goal layer floats above and pulls the relevant data up — burndown charts, completion rates, status updates — into a tidy executive view.
What the integration actually delivers is a synchronised view of what got done. Not why it got done. Not whether it was the right work for the goal. Not whether the person doing it knew, at the moment of doing it, that they were supposed to be moving a strategic metric.
A Jira ticket closes. The integration fires. A KR progress bar moves a percentage point. To leadership, looking at the dashboard, this creates the appearance of traceability. The metric responded to the work. The work was linked to the goal. The system worked.
It didn't. The ticket was created independently, by an engineer doing engineering, for reasons that may or may not have anything to do with the KR it was eventually mapped to. The relationship between the ticket and the KR was decided by a human at some point in the past — in a spreadsheet, in a tool configuration, in a Slack thread that nobody can find. When the work changes, and work always changes, the mapping doesn't update with it. The traceability is approximate, maintained by human discipline, and stale within weeks.
An integration tells you what happened. It cannot tell you whether what happened was the right thing.
The specific problems integrations can't solve
There are three structural problems no integration architecture can solve, regardless of how cleverly the API is designed.
The ownership problem. When a KR is mapped to twenty tickets across three teams, who is accountable for the KR? The integration cannot answer. The integration aggregates. Aggregation is not accountability. Accountability requires a single person whose job is the outcome, and aggregating tickets across teams doesn't produce that — it dilutes it.
The creation problem. Work is created in PM tools either before the goals exist or after the goals are set without the teams that have to do the work being involved. Either way, the connection is retroactive. The work was planned in the absence of the goal context. Connecting it afterward carries strictly less information than creating it together would have. The ticket is shaped by what the engineer thought was needed in the moment, not by what the strategic outcome required. The two are often close. They are almost never the same.
The meaning problem. "40% of tickets linked to this KR are closed" is a data point. Whether closing those tickets actually moved the underlying metric — whether they were even the right tickets to be linked in the first place — is a judgement no integration can encode. The dashboard looks healthy and the goal might be drifting badly. The integration cannot tell the difference.
The argument for building native
If you want a system where every piece of strategic work knows its goal — where accountability is structural rather than maintained — you have to build the work layer. Not because PM tools are bad. They're excellent at their job. But their job is work management, not strategy execution, and they don't have a native concept of a strategic outcome. They have a native concept of a task. Those are different objects with different shapes.
When we built the Vindaris work layer, we built it from the opposite end. Every strategic work item is created in the context of a goal. The goal connection isn't metadata added later — it's the frame within which the work item exists. The owner of the item knows, at the moment of creation, what strategic outcome they're supposed to be moving. That changes the experience of doing the work. It changes the review conversation. It changes what the system can surface when something stalls — because the system knows what stalling means in terms of the goal, not just in terms of a ticket sliding right on a board.
What we gave up
The native work layer is a real trade-off, and pretending otherwise would be dishonest. We gave up the easy promise of "no change to your existing tools." An engineer who lives in Linear shouldn't have to move all of her work into Vindaris. A marketing team that runs perfectly well in Asana shouldn't have to maintain two systems for the same operational tasks.
Our answer to that constraint is that Vindaris isn't the tool where every task lives. It's the layer where strategic work lives — the initiatives, the owned outputs, the structured effort that is explicitly accountable to a goal. Operational task management continues in whichever tool the team is most productive in. The strategic work — the portion of effort that leadership needs to be able to trace to outcomes — lives in Vindaris, natively connected to the goals it's meant to move.
It's a narrower surface area than an all-in-one tool. It's also the right surface area for the problem we're solving, and we'd rather be precise than be everything.
The architectural claim
Here's the claim, stated bluntly. The only way to have a trustworthy, live, automatically-maintained connection between goals and work is to build both layers in the same system, with a shared ownership model and a shared data structure. Every other approach — integration, sync, linking, mapping — requires human maintenance to stay accurate. Human maintenance degrades under work pressure. Under work pressure is exactly when you need the traceability most.
We built the work layer because the integration approach fails at the moment it matters most. Not because we wanted more features. Because the architecture demanded it.
The Vindaris view
We are not trying to replace Jira for engineering or Asana for marketing. We are trying to be the layer where strategy and work meet, where the things that are explicitly accountable to an outcome live in a system that can surface when they're on track and when they're not, without a meeting, without a status update, without somebody's Sunday-evening reconciliation. The work layer is the product, not an addition to it. The integration model was the safe bet, and the safe bet was wrong.