Most integration costs grow with every customer you add. On Strawbay, they do not. Here is why the number of systems you connect, not the number of customers you serve, is the number that actually drives cost.

When a factoring, collection or lending platform connects to a customer ERP, the hard part is the connection, not the customer. Build it once and every customer on that same system is served by the same standardized flows. The work, and the cost, lives at the level of the system, not the account.

That is why Strawbay prices on connected systems. Roughly 95% of Swedish ERPs can be onboarded, and once a system is live you can onboard as many customers on it as you like without adding operational cost. The more you scale on a connected system, the better the economics get.

It is a small reframing with a large consequence: every new customer becomes margin, not overhead.

Strawbay began with a conviction Claes Ramel kept returning to: a financial business should be able to see, monitor and change its whole ecosystem of integrations, and the data moving between its systems, from one place. That so many platforms were also rebuilding the same connections by hand was the visible symptom. We sat down with him to hear how it turned into a company.

Ask Claes Ramel where Strawbay started, and he does not begin with technology. He begins with a feeling familiar to anyone who has worked close to financial operations: that no one could really see or steer the web of connections their business depended on, and that the same hard work was being redone over and over just to keep it alive.

“What I kept missing was oversight. A finance business should be able to see its whole ecosystem of integrations, and the data moving between systems, and change it, all from one place. That is the real need. Everyone rebuilding the same connections is the symptom you notice first.”

Claes Ramel, Co-founder, Strawbay

And rebuild they did. Wherever Claes looked, smart teams were spending months wiring the same systems together, a factoring platform here, a collection platform there, each one building its own connection to Fortnox, to Visma, to the banks. He is careful not to dismiss it: that work is partly necessary, and it genuinely creates value. But it is also a temporary, slightly absurd state of affairs, the same plumbing rebuilt again and again, every version a little more fragile than the last, and almost none of it giving anyone a clear view of the whole.

“All that rebuilding is not stupid, exactly. It is partly necessary, and it does create real value today. But it is temporary. The prize is not another hand-built connection, it is making the whole web of integrations visible and yours to steer.”

Claes Ramel, Co-founder, Strawbay

The cost of all that repetition was not just engineering time. It was speed to value, and it was blindness. A new client could not get started until someone had built or maintained yet another one-off integration, and once it was live it became one more thing that could break at three in the morning, with no single place to watch it from. The work was slow to deliver, brittle to keep running, and hard to see across.

The insight that became Strawbay followed from the goal. If a business is going to see and steer its whole ecosystem, the connections cannot live buried inside each separate product. They belong one level up, built once at the level of the system itself, then reused, and watched, across every customer who needs them.

“The moment it clicked for me was realising you should connect once, at the level of the system, and reuse that everywhere. You do not write bespoke code for each customer. You build an engine, plus ready-made packages for the systems people actually use, and then onboarding becomes configuration instead of construction, and the whole estate becomes something you can actually observe.”

Claes Ramel, Co-founder, Strawbay

That shift, from one-off code to an engine with ready-made packages, is what makes the oversight possible. Instead of treating every integration as a fresh project, Strawbay treats the hard part as something you solve well once and then deliver, and monitor, many times. The number of different systems you support is what takes the work, not the number of customers you bring on board. That is what makes 1-to-n onboarding, consolidating many end customers across many systems into one master system, something a small team can do at scale, and keep an eye on.

From there, the vision widened. Finance in Europe runs on data flows that have to be stable, secure and quick to stand up, in a setting where regulation is part of daily life. Claes wanted those flows to rest on something solid, and visible, rather than on a tangle of bespoke connections that no one fully trusted or could fully see.

“What I really wanted to build was steady ground. An integration layer European finance can stand on, anchored, dependable, observable, and increasingly supported by an agent layer that helps deliver and watch over the work. Not a clever bolt-on, but the floor underneath the whole thing.”

Claes Ramel, Co-founder, Strawbay

That anchored, agent-supported integration layer is where Strawbay is heading. The engine ships complex integrations faster and holds steady as volume grows, the ready-made packages cover the systems customers actually run, and the agent layer is woven in rather than stapled on, helping the people who deliver, monitor and adjust the flows that businesses depend on.

For all the engineering underneath, Claes keeps coming back to the human goal. The point was never integration for its own sake. It was to let the teams that run European finance see their whole ecosystem, trust that the data keeps flowing, and change it when they need to.

Strawbay’s platform is built as one engine that serves every customer, with hard isolation between them, security designed in from the first line, and resilience that assumes things will go wrong. We sat down with Andy Kovalov, who leads the platform and engineering at Strawbay, to talk about the choices behind that design.

Strawbay sits in the middle of regulated financial flows, connecting client portals and core systems to the many ERP systems their customers run. That position carries a high bar: the data has to keep moving, it has to stay inside the EU, and no customer can ever reach another customer’s information. We asked Andy how the architecture is built to meet that bar.

“We deliberately built one engine rather than a separate stack per customer. One well-understood, continuously hardened platform is far safer than dozens of variations nobody can fully reason about. The strength is not that every tenant has their own copy, it is that every tenant is strictly isolated inside one system we know inside out.”

Andy Kovalov, CTO, Strawbay

That isolation is enforced at the platform level. Each customer runs in its own namespace, and knowledge, data and tooling are scoped per tenant so that a request can only ever touch the information it is entitled to. The same boundary applies to the agent layer in the console: every conversation is bound to a user and their tenant, and access is fail-closed by default.

Security is treated as a property of the design, not a layer added afterwards. Personal data and secrets are minimised and protected, the platform follows the principle of least privilege throughout, and approval keys and access tokens are rotated and validated continuously rather than left static.

“Rotation is one of our quiet strengths. Keys and approval tokens are short lived and constantly refreshed and validated, so a credential is only ever useful for a brief moment. It turns a static target into a moving one, and that removes a whole class of risk before it can ever be exercised.”

Andy Kovalov, CTO, Strawbay

Resilience is the other half of the story. The platform assumes failure and is built to recover quickly: hourly backups, a tested disaster recovery process, and source code held in escrow so customers are protected even in the unlikely event something happens to the company. The aim is simple, the financial flows a regulated business depends on keep running, and can be brought back fast if they are ever interrupted.

“Our customers run regulated businesses on top of these flows, so resilience is not optional. We back up continuously, we rehearse recovery rather than hoping it works, and the code sits in escrow. If the worst happens, the data keeps flowing and nothing of the business is trapped with us.”

Andy Kovalov, CTO, Strawbay

All of it stays in Europe. The core platform and the financial data it handles run on Google Cloud in Europe, with no replication outside the EU. Strawbay operates as a data processor with GDPR built into the design, and the controls are mapped to the standards European finance is held to: privacy by design, EU data residency, and an information security posture that is certification-ready for ISO 27001 when a customer requires it.

“We hold ourselves to the standards our customers are measured against, because the formal review always comes, and we would rather be ready for it than scramble. EU residency, GDPR by design, controls mapped and ready for certification. It means a customer’s due diligence is a confirmation, not a discovery.”

Andy Kovalov, CTO, Strawbay

The result is a platform that is fast to deliver on, because there is one engine to build on, and trustworthy to run on, because isolation, security and resilience were designed in rather than bolted on. For more on how the agent layer works within these same boundaries, see our developers section.

Strawbay’s console comes with three agents: Anna who supports, Saga who teaches, and Barry who builds. Behind their easy, helpful surface sits a deliberately narrow design: the right knowledge, a constrained set of tools, strict isolation per customer, and a human in control of anything that touches production. We sat down with Rickard Elmqvist, who works on the agents, to talk about the choices behind them.

It is tempting, when AI is everywhere, to bolt a chatbot onto a product and call it done. Strawbay went the other way. The agents are useful precisely because of what they are not allowed to do.

“We did not want AI for its own sake. We wanted useful, perfected AI that actually helps people in the console, and then we spent most of the effort making sure it stays firmly in its lane. The interesting work is not the model. It is the guardrails around it.”

Rickard Elmqvist, CEO, Strawbay

The three agents map to three jobs. Anna is support: she answers questions and helps users get things done, working from the knowledge base and from read access to what each user is already allowed to see. Saga is the tutor: she guides people through the platform and how integrations work, so teams get productive faster. Barry is the builder: he can create and change integrations, but every write runs through plan mode and explicit human approval before anything happens.

“Barry proposes a documented plan, a person reads it, and only then does it execute, step by step. The agent never reaches around the approval. That single rule is what lets us give a builder agent real capability without giving up control.”

Rickard Elmqvist, CEO, Strawbay

Underneath all three sits a governed knowledge base. The agents answer from a curated, continuously maintained store of product knowledge rather than improvising from the open internet. Just as important is what never enters that store. Knowledge is sanitised with defence in depth before anything is written, so secrets and personal data are scrubbed out. Customer data does not live in the shared store at all.

“The knowledge base is shared and sanitised, never a dumping ground for customer data. When an agent genuinely needs your live data, it reads it through scoped tools, in the moment, for that purpose. The store stays clean by design.”

Rickard Elmqvist, CEO, Strawbay

Keeping that store useful is its own discipline. Indexing services run quietly in the background so the knowledge base reflects the current state of the product, rather than drifting out of date. The aim is an agent that is helpful today and still accurate next week.

This is where retrieval matters. The agents do not lean on whatever a model happened to memorise in training. At answer time they retrieve the relevant, current passages from the governed store and reason over those, so every answer is grounded in what is actually true about the product right now. New guides, release notes and resolved questions are indexed as they appear, which means the pool the agents draw from keeps getting broader and sharper without anyone retraining a model.

“Retrieval is what keeps the agents honest. They answer from the indexed knowledge, not from a memory that froze on the day a model shipped. When the product changes, we index the change, and the next answer already reflects it.”

Rickard Elmqvist, CEO, Strawbay

That turns into a loop that compounds. Where the agents fall short, a question they answer thinly, a gap a customer runs into, that becomes the next thing we capture, sanitise and index. Each pass closes a gap and the knowledge gets a little deeper, so the agents genuinely get better and better over time, grounded in the product rather than guessing at it.

“Every gap we find is just the next thing to index. The agents improve because the knowledge behind them improves, continuously, and that is a far safer way to get better than letting a model freelance.”

Rickard Elmqvist, CEO, Strawbay

The agents reach the platform through a constrained tool layer, Strawbay’s approach to the Model Context Protocol. Rather than open-ended access, capabilities are organised into toolboxes that can be switched on or off per agent and per role. A support agent simply does not see the tools a builder uses, and the model only ever has the capabilities its role is permitted to use.

“Tool access is a dial, not a switch. We can turn toolboxes on and off per agent and per role, so each agent sees exactly the capabilities it needs and nothing more. The model cannot use a tool it was never handed.”

Rickard Elmqvist, CEO, Strawbay

The final layer is isolation. Every conversation is bound to the user and their tenant, and knowledge, data and tools are scoped per customer. One customer’s agent cannot see another customer’s world, and that boundary is built into the platform rather than left to good intentions. Inference itself runs in the EU, on the same region as the rest of the platform, so prompts and data stay on the default European path.

The throughline is consistent: useful AI that speeds people up, kept firmly in its lane, with humans in control of anything that matters. For more on the agents and the governed tool layer, see our Agents and MCP page.

Strawbay ships financial integrations fast and keeps them stable at any volume, across the systems enterprises actually run: Microsoft Dynamics 365, Fortnox, Tripletex and the rest. The reason, says engineer Sergei Kovalov, is that the engine runs every flow the same way: standardized flows assembled from reusable parts, executed in isolation per tenant, watched and retried so failures never go quiet.

Most integration teams treat each connection as its own project. Hand-coded, hand-maintained, slightly different every time. Strawbay took the opposite path. Flows are not written from scratch, they are assembled from packages and recipes, so the same logic runs identically wherever it lands.

“We do not hand-code integrations one by one. A flow is assembled from packages and recipes, the same standardized building blocks every time. That means a new customer or system is mostly a matter of choosing the right parts, not writing new ones.”

Sergei Kovalov, Lead Engineer, Strawbay

The payoff is consistency. Because a flow is defined once and reused, it behaves the same across every connected system. A fetch, a sync, a payment, the shape of the work does not drift from one ERP to the next. That predictability is what makes the platform calm to operate, even as the number of connected systems grows.

“The goal is that the same flow behaves identically everywhere it runs. If you have seen it work once, you know how it will work for the next system, and the one after that. There are no special cases hiding in the corners.”

Sergei Kovalov, Lead Engineer, Strawbay

Reliability at scale comes from how those flows execute. Each runs in its own isolated, short-lived environment, scoped to a single tenant. Work starts, does its job and ends, so one customer’s run can never quietly disturb another’s. Isolation keeps the blast radius of any single problem small, and short-lived execution keeps the system clean between runs.

“Every run is isolated and short-lived, one tenant at a time. Nothing lingers, and nothing leaks between customers. When something does go wrong, it stays contained to that single run instead of spreading.”

Sergei Kovalov, Lead Engineer, Strawbay

Failures are treated as normal, not exceptional. External systems time out, rate-limit and go down, so the engine is built to expect it. Transient failures are retried automatically, and everything is monitored so a problem is surfaced and handled rather than discovered later by a frustrated customer. The operations posture is proactive: catch it, retry it, and only raise a human when a human is genuinely needed.

“We assume things will fail, because at scale they will. Retries handle the noise, monitoring catches the rest, and we see problems before our customers do. That is what lets us run a lot of integrations without a lot of firefighting.”

Sergei Kovalov, Lead Engineer, Strawbay

Put together, the picture is simple. Assemble flows from standard parts instead of building them by hand, run them the same way everywhere, isolate each run, and let retries and monitoring absorb the inevitable failures. That is what makes delivery fast and operations calm, and it is why the same engine can carry many customers across many systems without the work multiplying.

What does it actually take to build a workplace with real substance, a place that does work of genuine height and quality? We sat down with Johanna Herrlander at Strawbay to talk about craft, care, and what it means to take pride in work that holds.

The Swedish word “verkshöjd” is hard to translate. It points to work that has real height to it, made with skill and care, the kind of thing you can stand behind. For Johanna Herrlander, that idea is less a slogan and more a daily practice, something you feel in how a team hires, how it ships, and how it treats the people doing the work.

We started with the most basic question: where does substance come from? Her answer began, unsurprisingly, with people.

“You cannot bolt quality on at the end. It starts with who you bring in. We hire for craft and for care, people who genuinely want the thing they build to be good, not just done. When someone takes that kind of pride in their work, you do not have to manage the quality into it. It is already there.”

Johanna Herrlander, Chief People & Organisation Officer, Strawbay

That care, she argues, only thrives when people are trusted to own their work. At Strawbay the teams are deliberately small, and they ship. Autonomy is real, but it comes paired with responsibility rather than instead of it.

“Autonomy without responsibility is just chaos, and responsibility without autonomy is just stress. We try to give people both at the same time. A small team that owns a problem end to end will care about it in a way no one can mandate from above. They feel it when something is not right, and they fix it because it is theirs.”

Johanna Herrlander, Chief People & Organisation Officer, Strawbay

None of that works, she is quick to add, without safety. People only do their best work when they can say “I am not sure”, ask the naive question, or admit a mistake without bracing for a reaction. For Johanna, psychological safety is not a soft extra. It is the condition that makes craft and honesty possible in the first place.

“The teams that ship the best work are the ones where it is safe to be wrong out loud. If people are afraid, they hide problems, and hidden problems are the expensive ones. When it is safe to say ‘this part worries me’, you catch things early, and you keep learning instead of defending.”

Johanna Herrlander, Chief People & Organisation Officer, Strawbay

That learning culture, she says, is what keeps substance from going stale. The point is not to know everything, but to stay curious and to get a little better with each thing you build. And it all comes back to a quiet kind of pride: building things that hold, that do not fall over the first time real volume hits them.

The reward, in the end, is something a customer can feel without ever seeing the team behind it. Integrations that stay stable, flows that keep running, onboarding that just works. Substance is not something you talk about. It is something that shows up, quietly, in work that holds.

Integrations are the kind of problem that hides in plain sight. Everyone depends on them. Almost no one wants to own them. And the moment they break, they become the only thing anyone can talk about.

We learned this the hard way. Before Strawbay, we — Jakob and Anis — spent years inside the Blingdale group, building and scaling the Quiddly platform. Across those projects and the companies around them, we tried nearly every approach to connecting financial systems that exists. We built our own. We bought from others. And no matter which path we took, we kept arriving at the same uncomfortable conclusion: the way the industry handles integrations is fundamentally broken.

This is the story of what we found and what we decided to do about it.

““We built our own. We bought from others. The conclusion was always the same: the way the industry handles integrations is fundamentally broken.”

Jakob Carlbring, Co-founder, Strawbay

When you build it yourself

Our first instinct was the engineer’s instinct: build it ourselves.

And it worked, in the way custom software always works at first. We got exactly what we wanted — connections tailored to our needs, behaving the way we expected. But custom comes with a tail, and that tail is maintenance. Every connection we built was a connection we now had to keep alive. ERP systems change. APIs deprecate. Authentication tokens expire. Edge cases surface at the worst possible moment.

Keeping those integrations healthy became a permanent job — one that sat completely outside our core business, yet was absolutely business-critical for our customers. We weren’t an integration company. We were a platform company. But we were spending real energy operating like one anyway.

“We weren’t an integration company. We were a platform company — yet we were spending real energy operating like one anyway.”

Jakob Carlbring, Co-founder, Strawbay

The deeper cost was cognitive. To maintain those connections, we had to genuinely understand systems we didn’t build and couldn’t control. We had to learn how dozens of ERP systems modeled their data, how they represented state, how their authentication flows worked, and how each of them quietly differed from the others. That’s an enormous amount of knowledge to carry in a domain that was never our focus. Every hour spent reasoning about someone else’s data model was an hour not spent on the product our customers actually hired us for.

When you buy it from someone else

So we did what most teams eventually do: we looked outward, to third-party integration providers. If this wasn’t our core competency, surely we could buy it from someone whose competency it was.

What we found was a frustrating binary.

On one end were the generic platforms. They connected to everything, in theory — but they handed us data in their shape, not ours. We didn’t just need a pipe between two systems; we needed the data to arrive structured the way our platform expected it. Generic solutions left that translation as an exercise for the reader, which meant the hard part of the problem was still ours.

On the other end were the bespoke providers. They could absolutely deliver data in exactly the shape we needed — because they built each connection by hand, for us, as a project. But that’s not a product. That’s a consulting engagement wearing a SaaS logo. It didn’t scale, it didn’t compound, and it left us dependent on someone else’s roadmap and availability for something we needed to move quickly on.

Too generic to be useful, or too bespoke to scale. Neither end of the spectrum was a real answer.”

Jakob Carlbring, Co-founder, Strawbay

The realization

Here’s the moment that changed everything for us.

We started to notice that this wasn’t just our problem. Every single customer we spoke with had the same story. Different industries, different systems, different scale — and the exact same pain. They all needed seamless connections between their own systems and the internal and external systems around them. They all considered integrations critical to their success.

And they all felt the same way we did: they didn’t want to own them.

““Different industries, different systems, different scale — and the exact same pain.”

Jakob Carlbring, Co-founder, Strawbay

When they built integrations in-house, they took on the maintenance burden and the cognitive load we knew so well. When they outsourced them, the integrations turned into a black box — something they depended on completely but couldn’t see into, couldn’t shape, and couldn’t fully trust. Critical infrastructure that was simultaneously essential and opaque.

The need was universal. The market was full of options. And yet the solution we all actually wanted simply didn’t exist.

So we decided to build it.

What we set out to build

We didn’t want to build another point in that broken spectrum. We wanted to dissolve the spectrum entirely.

We imagined an integration platform delivered as true SaaS — something you adopt, not something you commission. But unlike the generic platforms, it would give you full control to shape every data flow into exactly the format you need. And unlike the bespoke providers, it would be transparent by design: no black boxes, no hidden machinery, no waiting on someone else to tell you what your own connections are doing.

Our north star was simple. Creating a connection should feel as effortless and as trustworthy as authorizing your bank to share your data under PSD2 — a clean, consent-based handshake that just works. And once a connection exists, you should never lose sight of it. You should always have complete visibility into and control over every connection: its health, its performance, its behavior.

Transparency and control weren’t features we’d bolt on later. They were the entire point.

The foundation: a language of our own

To deliver all of that, we knew we couldn’t take a shortcut. A platform with that level of flexibility and transparency couldn’t be assembled from rigid templates and pre-baked connectors.

So we went all the way down to the foundation and built our own scripting language — purpose-built infrastructure for moving and reshaping data between systems. It’s the layer that lets anyone create data flows between any two systems with a modern integration interface, on their own terms, without inheriting the maintenance burden or the cognitive load that defeated every approach before it.

That language is what makes the rest possible. It’s what turns “integration” from a project into a product, and from a black box into something you can see, shape, and trust.

That language became Strawbay.”

Jakob Carlbring, Co-founder, Strawbay

Where we are now

Strawbay exists because the two of us refused to accept that integrations had to be a choice between owning a burden and trusting a black box. We lived inside that false choice for years. We watched every customer we met live inside it too.

We built the thing we always wished we could have bought — an integration platform that is yours to control, transparent enough to trust, and simple enough that you can finally stop thinking about integrations and get back to your actual business.

That was the problem nobody wanted to own. So we did.