Thursday, November 12, 2026
Home Blog

From Corporate Innovation to an Independent Startup: A Bold Move into LegalTech

0
Moonlit: Data Layer and Commentaries for Legal AI Roderick Lucas

I am Roderick Lucas, founder and CEO of Moonlit. Before Moonlit I spent close to a decade at Deloitte, where I became Artificial Intelligence Lead, and I taught technology courses at Vrije Universiteit Amsterdam and Tilburg University. Moonlit is a legal publisher built for humans and AI. Legal professionals use our platform to research the law, read commentary and monitor changes. Underneath sits our Data Layer: legislation and case law from dozens of jurisdictions, connected by hundreds of millions of references, updated daily and verifiable down to the official source. The same layer reaches AI assistants such as Copilot, ChatGPT and Claude through our MCP connector, and other legal AI products through our API.

The inspiration was a mismatch I saw every day. The law is public. You pay for it with your taxes, and the courts publish their rulings for everyone. Yet working with it was expensive and slow. Every serious question crosses a border at some point, the sources sit on dozens of national portals in different formats and languages, and the knowledge that explains them sits behind publisher paywalls. Specialists spent most of their time collecting and checking rather than thinking.

Then language models arrived, and they could reason about legal text far better than anyone expected. What they lacked was something reliable to reason over. That gap was the company: build the layer underneath to provide access to the knowledge on top of it.

Moonlit originally started as an internal project at Deloitte. What led to its development, and when did you realise it had the potential to become an independent business?

Deloitte advises clients across many countries, and a tax or legal question rarely stays inside one jurisdiction. Our specialists were doing cross-border research by hand: open each national portal, search it in its own language, copy the sources into a memo. We built a tool to take that collecting work off their plates, with every source linked back to the official publication so the specialist could check it in one click.

Once legislation and case law from several countries sat in one structure, and the citations between them were resolved into links, the tool stopped being a faster search box and became a map of the law.

A data layer like this gets more valuable with every person and every system that reads from it, and inside one firm it could only ever serve one firm’s specialists. Together with Deloitte we decided spinning it out was the best path forward. We’re in good contact and Deloitte is still an investor in Moonlit.

Taking Moonlit independent in 2024 was a major step. What gave you the confidence to make that decision, and what were the biggest challenges along the way?

The confidence came from the users, not from a plan. When people change how they work without being told to, you have something. Add to that the timing: language models were about to make verified legal data far more valuable, and we already had the building stones for layer those models needed.

The first challenge was leaving a large organisation with a small team and a large ambition. Inside Deloitte you have brand, clients and infrastructure on day one. Outside you have to earn each of them again, and the legal market is careful about who it trusts. We answered that with proof rather than promises: ISO 27001 certification, EU and US hosting, and a product where every claim links to its source.

We started as a research platform, became a data company when legal tech vendors began building on our API and MCP connector, and are now also a publisher with Commentaries. Each step was the right one, and each took some convincing, inside the company as much as outside it.

The problems Moonlit solves fall into three different silos:

Collection: The sources for a cross-border question are spread over dozens of national portals, each with its own format, language and way of citing. Moonlit connects to the official portals, takes in new publications every day and puts everything in one structure that is updated daily, down to the individual article.

Connection: Legal texts cite each other constantly, and the meaning of a ruling depends on what it applies and what later rulings did to it. Our knowledge graph resolves those citations into links in both directions, so for any document you see what it cites and what cites it.

Trust: Every document keeps its link to the official publication, and every answer our tools give can be checked in one click. A citation either points to a document we hold or it does not appear.

Law firms, Big Four advisories and public institutions use the platform for cross-border research. Legal tech vendors build on our API and MCP connector instead of running a scraping operation per country. With Commentaries, anyone with a free account can read expert-reviewed commentary on the law.

Against the traditional platforms, the difference is where we start. They were built per country and sold per seat, with the content licensed and locked. We start from the official sources of many jurisdictions, structured the same way and linked to each other, and we keep that layer open: through our platform for people, and through our API and MCP connector for machines. A legal tech company can build on it. A lawyer can connect it to the AI assistant they already use.

Against other AI legal tools, we are not really a competitor. We are what many of them run on. Building and maintaining a complete layer per country is a scraping operation that never ends, and it is not what a legal AI company wants to spend its engineers on. So they take ours. Through the API and the MCP connector, any product or assistant can search our Data Layer. Our own assistant Luna runs on the same connector, so it gets no better data than theirs.

And against everyone, the difference is Commentaries. We are the only one that we know of that publishes the interpretation of the law, reviewed by named experts, with every source one click away, free to read.

Reliability starts at the source and never leaves it. We take the law from the official publishers only: the legislative gazettes, the court databases, the regulators and, for EU law, EUR-Lex. Every document keeps its attribution and a link back to the official publication, and that link is the basis for everything built on top.

The concern is justified. Damien Charlotin’s tracker of court decisions involving AI hallucinations stood at well over two thousand when we launched Commentaries, hundreds of them tied to practising lawyers. A model has seen a case number mentioned far more often than it has seen the ruling itself, so it produces a reference that looks right. And its knowledge stops at its training date, while the law does not.

Our answer is to change the job the model does. With our tools it retrieves the law instead of recalling it. Every result carries its citation and official link, and a citation that does not resolve to a document we hold does not appear. That removes the fabricated case. It does not remove misreading, which is why Commentaries puts a named legal expert between the AI draft and the reader. If you cannot click through to the ruling a conclusion rests on, you are being asked to take it on faith. We built Moonlit so nobody has to.

Moonlit is already being used by professionals at organisations such as Deloitte, KPMG, and De Nederlandsche Bank. How did you convince established institutions to adopt your technology, and what have you learned from working with them?

We did not convince them with a pitch. We let their specialists try it on a real question and check the answer against the sources. In an institution like that, the person who decides is rarely the person who does the research, so the product has to win the researcher first. Once a specialist has run a cross-border question in an afternoon that used to take a week, and clicked through to every source, the conversation with procurement becomes a formality.

The formality still has to be done properly. These organisations ask the right hard questions: where is the data hosted, who has access, what happens to our queries, is every source attributable. Moonlit is ISO 27001 certified and GDPR compliant, offers both EU and US hosting and we do not store queries. For a central bank or a Big Four firm, that last point matters as much as the first three.

What we learned is that the established players are not conservative about technology. They are conservative about risk, which is a different thing.

You secured investment from Curiosity VC to support Moonlit’s growth. How did this partnership come about, and what role has external funding played in developing your business?

We were building the data. For a fund that invests in AI infrastructure rather than AI wrappers, that was the conversation they wanted to have.

The funding pays for engineering, because connecting dozens of official portals and keeping them current every day is a team’s full-time work, not a project. It pays for Commentaries, which needs paid expert editors before a single page is read. It also lets us build the business in the right order: the data layer first, the products on top of it second, and the market reach third. Without outside money we would have had to sell harder earlier and build less.

In the Netherlands about 40 cents of every euro you earn goes to the state, and part of that funds the legal system. Much of the commentary that explains the law is written by academics at publicly funded universities. The large publishers sell that commentary back to the universities, the courts, the ministries and the firms that need it, at hundreds of euros per user per month. Everyone who has to comply with the law pays twice. A fair legal system should not cost more per month than your Netflix subscription.

Commentaries is our answer. Each commentary is drafted from the primary sources in our Data Layer by our own engine.

The business works because the commentary is not the core product. The Data Layer is. Commentaries is included in the Platform subscription for professionals who research daily, and it reaches AI assistants through the MCP connector and other legal AI products through the API. Every reader who comes for a free commentary sees what sits underneath it, and the ones who need the full platform, or the data behind it, pay for that. The open commentary also gets better with use: readers correct it, editors revise it, and the Data Layer flags every new ruling. A closed commentary cannot do that. So the thing we give away is also the thing that makes the paid product stronger.

Building a technology company in a traditionally conservative industry comes with unique challenges. What has been your biggest obstacle as a founder, and how have you overcome it?

The biggest obstacle was not the industry. It was the publishers’ head start. For decades the knowledge that explains the law has belonged to two or three companies, and the whole market is shaped around that: the subscriptions, the citation habits. When you tell a lawyer the interpretation of the law can be open, free and checked at the source, the first reaction is not disagreement. It is disbelief that it can be done at the quality they are used to.

You cannot win that debate in a meeting, so we built the proof instead. First the Data Layer, with every document linked to its official source, so nobody has to take our word for the law. Then Commentaries, with named editors from universities, courts, government and law firms.

Looking ahead, what are your ambitions for Moonlit over the next few years, and which markets, technologies, or opportunities are particularly exciting for you?

The ambition is to be the legal data infrastructure and publisher built for humans and AI. Publisher in the full sense: we collect the law from the official sources, structure and connect it, and now publish the knowledge on top of it.

The models will keep getting better and the difference will come from what they are allowed to read and the proprietary data you build on top of them. Our own assistant runs on the same MCP connector that outside agents use, and customers already run their own agents on it. As more of the work shifts to reading, the value of a verified layer underneath goes up.

The second is law firms building in-house. Most of our API customers today are legal tech vendors. The next wave is firms and legal departments that build their own tools on the same data, and the MCP connector lowers the bar to a few clicks.

The third is geography. The problem we solve is cross-border by definition, so the market is wherever the law is published and people have to comply with it. We host in the EU and the US, and the Data Layer grows one official portal at a time.

Finally, what three pieces of advice would you give to aspiring founders who want to turn an innovative idea into a successful startup?

First, build the foundation before the feature. Everyone could see the chat interface coming. Few wanted to spend years connecting official portals and resolving citations, because that work is invisible. It is also what cannot be copied in a quarter. Pick the hard, unglamorous layer in your market and own it. The products on top come easier than you think.

Second, let the users decide before you do. Moonlit became a company because specialists kept using the internal tool without being told to and kept asking for more. When people change how they work for your product, you have something.

Third, make every claim checkable. In our market that means a link to the official source under every answer. In yours it will mean something else, but the principle holds: the fastest way through a careful industry is to remove the need for trust. A customer who can verify your work for themselves does not need a reference call, and a sceptic who can check you has nothing left to argue with. Execution over plans, and proof over pitch.

Image Credits: private picture

Thank you Roderick Lucas for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

BY Venture Partners Fund III Closes at $60M to Back Global AI Startups

0
BY Venture Partners team behind the $60 million Fund III investing in AI-native startups worldwide
The BY Venture Partners team announces the closing of its $60 million Fund III to support AI-native startups globally.

BY Venture Partners Fund III has closed at $60 million, marking a new milestone for the Dubai-based venture capital firm as it expands its global investment strategy for AI-native startups. Anchored by the Dubai Future District Fund, the new fund will support early-stage technology companies worldwide, while the opening of a European office in Lisbon strengthens the firm’s presence in Europe’s growing AI and deep-tech ecosystem.

Onfido and Invisible Technologies early backer BY Venture Partners closes $60M Fund III to back the next wave of AI Native entrepreneurs globally

  • Anchored by the Dubai Future District Fund (DFDF), firm expands total AUM to $200M
  • BY Venture Partners launches its European office in Lisbon
  • The firm backed EU-based Onfido, SalesApe, PQShield and Huspy from Fund I and Fund II

BY Venture Partners, a global early-stage venture capital firm headquartered in Dubai, today announced the successful $60 million close of its third vehicle, Fund III. The fund is anchored by the Dubai Future District Fund (DFDF), with participation from established regional institutionals, corporate venture arms, and prominent family offices – including Multi Lane, Transmed Capital, and the Idriss Family Office (KSA). Fund III expands BY Venture Partners’ total Assets Under Management (AUM) to over $200 million.

The Fund Targets AI-Native Startups Worldwide

Empowering AI-Native Founders from a Regional Powerhouse

Fund III will invest primarily up to $1m at the Pre-Seed to Series A stages into AI-native companies that reimagine enterprise workflows and scale globally from day one.

While anchored in the Middle East, BY Venture Partners operates with a global mandate. The firm invests across more than 16 international markets, with two-thirds of its capital deployed outside the MENA region across North America and Europe. Early momentum for Fund III is already underway, with 15 investments deployed to date out of a planned 40-company portfolio, including PQShield, Cosyne, Isometric, Huspy and Invisible.

“We are thrilled to officially announce Fund III and the launch of our European office in Lisbon, Portugal,” said Ghaith Yafi, Founding Partner at BY Venture Partners. “This fund will back AI-native companies with global ambitions. We are particularly excited to invest more across Europe, where hubs such as Madrid, London, Paris and Berlin are driving rapid advances in AI-native software. Our thesis is designed to generate strong, long-term returns for our partners, and we’re incredibly excited about the opportunities ahead with this new fund.”

BY Venture Partners Fund III Strengthens European Presence with Lisbon Office

Deeper Regional Commitment to Europe

Building on its track record of backing high-growth European tech ventures, including early investments in Onfido, PQShield, and Huspy, BY Venture Partners has officially established its European footprint with a new office in Lisbon and two key local investment hires.

“Europe is producing some of the world’s most formidable technical talent, but European founders often face a barrier when bridging the gap to international capital and global commercial scale,” said Sohrab Jahanbani, Partner at BY Venture Partners. “Having backed category leaders like Onfido, PQShield, and Huspy from our earlier funds, double-downing on Europe with our new Lisbon hub is a natural evolution. Our goal is to give ambitious European founders direct access to global networks, cross-border deployment opportunities, and an operator-led team that knows how to build across international markets.”

“Lisbon and the broader Iberian ecosystem have transformed from emerging regional hubs into serious launching pads for world-class AI and deep-tech innovation,” added Abdallah Yafi at BY Venture Partners. “By combining a local presence with BYVP’s global reach across the Middle East and North America, we are uniquely positioned to give Iberian and European founders the capital, operational support, and global commercial exposure needed to compete and win on the international stage.”

Built by Founders, for Founders

BY sets itself apart through its operator-first DNA: all four partners – Ghaith Yafi, Abdallah Yafi, Rami Jisr and Sohrab Jahanbani – are repeat entrepreneurs who built and exited businesses before joining forces as investors. This hands-on, founder-centric approach has earned BY Venture Partners an industry-leading Founder Net Promoter Score of 87.

BY’s track record has been built across more than one market cycle. Fund I and II have produced four unicorns alongside a growing group of companies now valued in the hundreds of millions, and the firm has already returned meaningful capital to its LPs.

With Fund III, BY Venture Partners continues to leverage its global-first, AI-first network to give early-stage founders the operational edge, capital, and global connectivity required to build market-defining technology platforms.

Integration without Code: How Polish Startup GRAFTCODE Works

0
GRAFTCODE: developers need less integration code Przemysław Ładyński, CEO of GRAFTCODE

GRAFTCODE helps developers simplify software development by reducing integration code and making functionality accessible across programming languages, services, and environments.

Przemysław, could you introduce yourself and GRAFTCODE and tell us what inspired you to start the company?

I got into coding almost by accident when I picked up a programming book at the age of nine, and I’ve been building software ever since.

When I was 19, my brother Łukasz and I founded a software development company. Over the years, we delivered a range of projects, including a diabetes management system for hospitals and patients that is now used in 63 countries. Then, the idea behind GRAFTCODE dates back to when I was considering pursuing a PhD. I developed an early proof of concept for runtime bridging, allowing Java applications to use .NET runtimes directly. What started as a fairly niche solution made us realise there was a much bigger opportunity to simplify how different technologies work together.

Over the following years, we invested our own funds and secured more than €6 million in EU grants to develop the technology, eventually expanding it to support 52 technology pairs.

The real turning point came when we extended runtime bridging to support remote communication. Developers could now call functionality from another service almost as easily as a local dependency, without writing and maintaining separate integration code. We realised this could fundamentally change how software is built, allowing the same business logic to be used locally, across microservices, through APIs or exposed to AI agents via MCP.

At the same time, we were seeing growing interest from developers and investors, which led us to establish GRAFTCODE as a standalone company. We were also fortunate to bring together a talented team willing to tackle the technical challenges involved. Since then, we’ve completed our seed funding round and are now looking towards Series A funding.

You and your cofounder have extensive experience in enterprise integration technologies. Which problems did you repeatedly encounter that ultimately led to the idea behind GRAFTCODE?

Since around 2000, we’ve seen several major shifts in integration technology, from SOAP and REST to gRPC, GraphQL and cloud-based messaging systems. Each solved certain problems, but developers still had to write technology-specific integration code.

Every technology introduced its own framework, SDK or programming model for exposing and consuming functionality. This tied applications to specific integration approaches, making significant refactoring necessary if you wanted to change them later.

The problem became even more apparent as software systems grew more complex. Developers were spending increasing amounts of time maintaining controllers, routes, data contracts and other integration code, even when the underlying business logic remained unchanged.

This brought us back to a simple question: why should calling a function remotely be so much more complicated than calling it locally? If you want to unzip a file, you simply install a package through PyPI, NuGet or Maven and call a method like Zip.Unzip(filename). But move that same functionality to a remote service, and suddenly you need HTTP routes, API contracts or SDKs just to call it.

We wanted to return to a basic principle we learned at university: a public method is an interface you can call. That inspired our idea of making the “public method public again”, allowing developers to use remote services like local dependencies. With GRAFTCODE, the underlying communication, whether through HTTP/2, WebSocket, a queue, an event bus, direct TCP/IP or MCP, becomes an implementation detail rather than something developers have to build around.

GRAFTCODE describes its technology as an “integration-free development layer.” What does this mean in practice, and which problem are you solving for developers?

The key distinction is that we’re not removing the integration layer itself but the need to write and maintain integration-specific code. Developers still need to design proper public interfaces, deciding which methods to expose, how exceptions should be handled and how those interfaces can evolve without breaking existing applications. GRAFTCODE removes the extra work required to make that functionality available across different technologies and environments.

In practice, developers add GRAFTCODE Gateway to their project, container or cloud service and expose the modules they want to make available. GRAFTCODE then makes the public methods accessible through strongly typed replicas of those interfaces, distributed via standard package managers like NuGet, PyPI or Maven.

From the consumer’s perspective, it looks like importing and using a normal typed dependency. They do not need to read an API specification or manually work with routes, schemas or protocol-specific SDKs. The available functions appear directly in the IDE, making them easier for both developers and AI coding tools to discover and use correctly.

Then, frontend and mobile applications, IoT devices, robots, and other microservices can consume the same service through load balancers, queues, or event buses; as a public B2B API; or via MCP by an AI agent.

Crucially, developers can also change how they deploy their applications without rewriting the business logic. A module might initially run locally within a monolith and later move to a remote service, or vice versa, with much of that change handled through configuration rather than new integrations.

That’s what we mean by integration-free development: developers still design clean public interfaces but no longer need to build and maintain separate integration code for every transport, protocol or deployment model. It’s close to the idea of a truly polyglot modular monolith, where modules can run locally or remotely, communicate synchronously or asynchronously, and still be consumed in the same way.

APIs and middleware have been fundamental to software development for decades. Why do you believe the traditional approach to connecting software systems needs to change?

APIs are here to stay, and they should be, as long as we understand them as a way of defining what a system exposes to the outside world. What needs to change is the extra code required to make that functionality accessible.

Why should developers have to write more integration code than actual business logic just to make a service available to a JavaScript or React application? Or write another layer of code to expose the same functionality through Azure Service Bus? All of that code then needs to be maintained, reviewed, and understood by both developers and AI coding tools.

AI coding tools are making this problem more noticeable. We’re seeing more AI-generated code and pull requests, and engineering teams can now produce software much faster. But the traditional approach also means developers and AI tools have to manage more integration code, even when the underlying business logic hasn’t changed.

At the same time, developers are also becoming increasingly polyglot. Someone who has spent most of their career working with Java can now use Python for machine learning, C# for business logic and TypeScript for the frontend. Yet each technology can bring its own integration requirements, adding more code to write and maintain.

Developers should be able to choose the best technology for each task and focus on business logic and public methods, rather than learning and maintaining different integration frameworks every time.

AI is generating an increasing amount of software and code. How is this development changing the integration problem that GRAFTCODE is addressing?

AI is making it much faster to build software, but it’s also generating more integration code. When an AI agent creates a new service, it still has to produce controllers, routes, DTOs, schemas and SDKs alongside the actual business logic. When that logic changes, you have to update all those additional layers.

We initially thought AI might solve the integration problem by writing all this code for us. But generating more integration code doesn’t really solve the problem. It just makes generating the problem cheaper.

There’s also the context issue. AI needs to read and understand all that integration code, keep it consistent with the business logic and account for it whenever something changes. That consumes tokens, creates more opportunities for errors and leaves developers with more code to review.

With GRAFTCODE, we want AI to work directly with public methods, their types, parameters and return values. An agent calling a remote service shouldn’t need to know whether the underlying communication uses REST, gRPC, WebSocket, a queue or MCP. It should simply see a strongly typed function it can call. In fact, the best integration code may simply be the integration code you never had to generate in the first place.

What I find particularly interesting is where this could lead. AI could eventually monitor a system and decide when a module should be extracted into a microservice, when to introduce a queue, when to move from Kafka to Azure Event Hubs or when to replace WebSockets with HTTP/2.

In the future, GRAFTCODE could let some of these changes happen through configuration rather than rewriting business code. An AI agent could potentially adjust the Gateway and graft configurations to change how services communicate, without developers having to rebuild the integrations around them.

What makes GRAFTCODE technically different from existing API, middleware and integration solutions, and where do you see your strongest competitive advantage?

I think our biggest differentiator is the technology and system design itself. GRAFTCODE allows developers to build simpler codebases focused on business logic, without compromising on security, authentication, scalability or observability.

We’re not trying to replace cloud messaging platforms, queues or event buses. We want developers to keep using them. What we’re challenging is the traditional way of exposing and consuming functionality through technology-specific controllers, API contracts, SDKs and frameworks just to make functionality accessible across different systems.

This also has implications for AI-assisted development. With less integration code to process and maintain, AI coding tools need less context, reducing token usage and making generated code easier to review. We also support MCP natively, allowing the same public methods to be exposed to LLMs and AI agents without building separate integrations.

On the performance side, runtime bridging operates largely through the underlying runtimes’ native layers, which can reduce overhead compared with traditional integration stacks. Depending on the use case, this can improve resource efficiency and let you process more calls with the same CPU and memory.

Another important difference is architectural flexibility. Developers can build a modular monolith and later extract individual modules into microservices through configuration without changing the consuming code. Those modules can even be written in different languages, such as Java, .NET or Python, while remaining part of the same architecture. Access to queues, event buses and other cloud services is also being simplified through open-source extensions developed by our team and the community.

All of these capabilities build on the same underlying approach: making public methods accessible across different runtimes, deployment models and communication channels.

Which companies and development teams are your primary target customers, and in which use cases does GRAFTCODE currently provide the greatest value?

Almost every software project could benefit from GRAFTCODE, but right now our POCs and early adopters are mostly teams building business-critical distributed systems designed to run for years. These might be systems at the core of an organisation’s operations or the software product itself.

For these teams, the benefits add up over time. Less integration code means less maintenance, fewer breaking changes, easier onboarding and more flexibility to change the architecture as requirements evolve.

That’s also why we’ve made the core platform free. We want developers to be able to try GRAFTCODE without barriers, while offering paid plans for enterprises that need higher SLAs, the ability to run the grafting process within their own cloud tenant or fully on-premises deployment to keep their public interfaces isolated. Our goal is to make grafting as natural a part of software development as using Docker, Terraform or Bicep.

Building core developer infrastructure is technically demanding. What have been the biggest challenges in developing GRAFTCODE so far?

The first challenge was getting the architecture right and staying disciplined about its underlying principles. When you’re building something that needs to work across different technologies, deployment models, communication channels and cloud environments, the underlying design has to be universal.

Programming languages are a good analogy. With a relatively small set of concepts in C#, Java or Python, developers can build anything from a simple IoT device to a complex AI system or global e-commerce platform. We wanted GRAFTCODE to work similarly, using a consistent set of abstractions that could support very different use cases without introducing new exceptions or complexity every time we added a capability. Getting that right has been one of our biggest technical challenges, and it remains so as we expand the platform.

The second challenge is keeping the technology reliable as more developers use it. Once people build their systems around GRAFTCODE, they need to know it won’t break when we introduce something new. That means maintaining backward compatibility, introducing changes gradually and making sure existing projects can upgrade without issues.

GRAFTCODE recently raised €2.1 million in funding. What convinced investors about your approach, and how will you use the new capital to accelerate the company’s development?

Initially, convincing investors wasn’t straightforward. GRAFTCODE was still a concept rather than a usable product, and explaining something so different from traditional integration approaches through slides alone was difficult, even to experienced CTOs and technology leaders.

The turning point came when we developed a way to demonstrate the actual developer experience. Once investors could see how it worked and the layers of complexity it could remove, they found the value much easier to understand. There was often an initial “wow” moment, followed by another as they started to realise the broader implications.

We’ve used the €2.1 million investment to bring GRAFTCODE to market and develop it towards a stable, production-ready release, including the enterprise capabilities needed for larger projects.

We’re now moving beyond the alpha and beta early-adopter phase, with larger proof-of-concept projects involving enterprise systems, including IBM Maximo environments and distributed applications developed by software houses. We’re also seeing growing interest in the free tier, with more than 4,000 grafts generated monthly by anonymous users, a figure that has recently been close to doubling month over month.

And we’re preparing for a pre-Series A round, with plans to scale more broadly next year after Series A funding. The seed investment helped us turn the technology into a product developers can use. The next stage is about demonstrating that GRAFTCODE can become a widely adopted approach to software development.

You are building a developer-infrastructure company from Europe. What advantages and challenges come with developing a globally relevant technology company from Warsaw?

Poland has an incredible pool of engineering talent, with Polish engineers contributing to major technology projects at companies like OpenAI, ElevenLabs and SpaceX. Warsaw combines that technical expertise with a creative, increasingly international startup culture. Mindsets have also shifted, with more founders thinking globally from the start and pursuing ideas that might once have seemed out of reach.

Building a global technology company from Warsaw comes with challenges, particularly around international visibility and relationships, but we’ve found fewer barriers than expected. We’re already having promising conversations with US-based venture capital firms and receiving positive feedback about our technology and company structure, so being based in Poland hasn’t been an obstacle.

What are the next major milestones for GRAFTCODE, and where would you like to see the company over the next three to five years?

Our immediate priority is getting more developers to try GRAFTCODE and making it easier for them to create their first graft. It’s still a new concept for many developers, so we need to make the benefits clear from the moment they start using it.

Looking five years ahead, our goal is to have around two million projects actively using GRAFTCODE, alongside a strong base of enterprise customers on paid plans to support sustainable growth.

Our ambition goes beyond building another integration tool. We want to make traditional REST or gRPC integration unnecessary in many scenarios by offering developers a simpler way to connect software.

We also plan to make most of GRAFTCODE’s code source-available or open source and eventually contribute our Intention Invocation Protocol (IIP) to the Cloud Native Computing Foundation as an open standard. This would allow other developers and companies to build their own tools and infrastructure around the same approach.

Ultimately, I’d like grafting to become a normal part of how developers build software.

What are the three most important pieces of advice you would give to founders building highly technical startups today?

First, build for a category, not just a feature. Think about how your idea could change an industry or even become a global standard. Improving an existing process by 10 or 20% is one thing, but creating something fundamentally different opens up much bigger opportunities.

Second, give your vision enough time to become reality. Deep technology takes time to develop, so make use of non-dilutive funding wherever possible. Grants and research programmes can give you the freedom to solve difficult technical problems and bring your product closer to market readiness without giving away too much equity too early.

Third, don’t be afraid to think even bigger, and find a team ambitious enough to build it with you. Once your original concept starts working, you’ll often discover applications and opportunities you couldn’t have anticipated at the beginning. Some of the most interesting possibilities only become clear when you start building.

Image Credits: GRAFTCODE Fotografia Wizerunkowa. Your Professional Image. www.ArekMarkowicz.pl

Thank you Przemysław Ładyński for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

Lette raises $6.5m to scale AI-run leasing and resident operations for UK rental operators

0
Lette: AI for residential operators raises $6.5m Lette AI

Lette raises $6.5m to scale AI-powered property management across Europe

Leading European proptech has opened a London office, grown its team sixfold in just one year, and helped one operator add more than 1,000 homes without increasing headcount.

The company has raised $6.5m, led by Peak Capital, with backing from leading investors across Europe and the UK, alongside notable angels including Des Traynor.

London, 27.10.2026: Lette, the AI operating system for institutional residential operators, has raised $6.5m in seed funding to scale its UK operation where its customers include Fortune 500 real estate firm JLL and large financial institutions. The round was led by Peak with participation from Pitchdrive, Heliad, Foreword VC and Adeline, as well as backing from prominent angels such as Des Traynor, co-founder of Intercom.

Changing rental regulations increase pressure on residential operators

Since the Renters’ Rights Act came into force on 1 May, fixed-term tenancies have ended in England, and most private renters can leave with two months’ notice at any time. Retention is no longer settled once a year at renewal. Operators now win or lose it every month, so the service a resident gets matters from the very first enquiry, long before move-in. Every touchpoint after that feeds straight into occupancy and income. Yet most teams still run resident service from inboxes, spreadsheets, disconnected point solutions, while portfolios grow faster than headcount.

Mohan Sai, co-founder and CEO, Lette:

“Institutional operators across Europe have never had a platform built around how their teams lease homes and look after residents. Lette takes a home from first enquiry to signed lease and stays with the resident after move-in, working alongside the systems operators already have. We’re using this funding to go deeper for rental operators. Now that residents can leave at two months’ notice, every day a home sits empty is lost rent, and that is what we help operators win back.”

AI automation helps operators manage more homes with fewer manual processes

Across more than 30,000 residential units, Lette handles over 60% of resident support and maintenance requests automatically and has cut the time it takes to lease a home from two weeks to under four days. One of the leading build-to-rent (BTR) operators has added more than 1,000 homes without increasing headcount.

Lette replaces the patchwork around the property management system (PMS) for operators across BTR, PBSA, PRS, and single-family housing. Its AI agents run leasing end to end and answer residents in seconds, at any hour and in multiple languages, through Lette’s AI-powered resident app, email, WhatsApp, SMS or voice calls.

They manage maintenance from first photo to completed repair and spot missed rent early, so teams can step in before arrears build. Lette syncs with Yardi, MRI, Res:Harmonics and other large PMS systems, and writes every update back, so the PMS stays the source of truth and teams go live in weeks with nothing to migrate.

Jakub Rajek, co-founder and CPO, Lette:

“Housing is a human industry. Letting agents and property managers come into this job to look after people, yet their days are still spent chasing leads, copying details between systems and updating spreadsheets. We started Lette to automate that repetitive work and give teams their time back, so they can pick up the phone when it matters and be there when a resident really needs them.”

London expansion and new hires support Lette’s European growth

Lette opened its London office and grew its team sixfold. Its UK team includes two senior industry hires: Mitch Hammond, formerly of OnTheMarket, and Abhiram Mishra, formerly of QX Global.

The funding will be used to further grow the UK team and hire across product, engineering and customer operations. It will also fuel expansion into new European markets in 2027.

JLL highlights efficiency and resident experience

John Coddington, Head of Residential for Property Management, JLL:

“Margins in residential are under pressure, and our clients expect us to run their buildings as efficiently as possible. Working with Lette helps us do that. It streamlines the journey from first enquiry to signed lease and gives us a real-time view of how each building is performing and ensures that the main focus is on residents.”

Investors see long-term potential in AI-powered residential property management

Thijs Dijkman, General Partner, Peak:

“We see a clear opportunity to build the AI-native operating system for residential property in Europe, and we believe Lette is leading the way. Mohan and Jakub bring deep technical expertise and sharp commercial judgement, and have moved quickly to earn the trust of major operators in the UK and Ireland. By building around the full resident lifecycle, they are creating a platform that is becoming central to how those businesses operate, with the operational data and customer relationships to build a lasting advantage. That is what convinced us to invest, and we’re excited to help the team realise that ambition.”

Picture Lette AI 

Source Redgert

Aiva co-founders on hospitality AI, hotel software, and scaling up

0
Aiva: How hotels use AI to improve guest experiences Image photographer Jo Berrojalbiz

Aiva uses AI to help hotels connect guest data, anticipate individual needs and create more personalized experiences while improving operations and revenue.

Lucía and Paula, could you introduce yourselves and Aiva and tell us how the idea for the company came about?

Lucía: I’m Lucía, co-founder and CEO of Aiva. I own go-to-market, sales and strategy. I come from a hotel family, studied Economics at UCL, and ran operations at a resort in Ibiza before starting Aiva.

Paula: I’m Paula, co-founder and CTO. I own product, engineering and infrastructure. I’m a software engineer, and I grew up in Ibiza alongside Lucía, so hospitality has been part of my life from the start.

Lucía: Aiva gives hotels the intelligence to anticipate what guests want and the ability to make it happen. The idea came from seeing the gap every day in operations. Guests stay a week and want things, and nobody asks them at the right time. It isn’t that staff don’t care. Nobody has the context or the hours to do it for 400 rooms at once.

You have been friends for many years. What made you decide to become cofounders, and how do your different backgrounds complement each other?

Paula: We’ve known each other for over twenty years. The hardest thing to find in a co-founder is someone you trust completely when things go wrong. We already had that.

Lucía: The split is clean. I’ve been on the operator side. I know what a front desk looks like at 11pm in August and what a general manager will actually approve. Paula is a software engineer who understands this industry because she grew up surrounded by it. That’s rare. She builds for hotel teams with real empathy for how they work, and she turns that into a system that works reliably across messy hotel software. We don’t overlap on who decides what, and that matters as much as the friendship.

Lucía, you previously worked as a hotel manager. Which problems did you repeatedly encounter in the hospitality industry that ultimately inspired Aiva?

Lucía: Three things kept coming up. First, the data wasn’t where decisions were made. The property management system knew who was in-house, but the spa, restaurants and activities each ran their own tools, so nobody could see the whole guest. Second, most of what staff knew about guests was never written down. “The couple in 214 asked about a boat trip.” “This family always eats late.” Those conversations hold the real signal, and they disappear at the end of a shift. Third, whether a guest heard about the sunset cabana depended on who they happened to talk to. So the opportunity wasn’t more software. It was being present in the guest conversation, with context, at the right moment.

Aiva connects hotel systems with guest information. What exactly does the platform do, and what problem are you solving for hotels?

Lucía: Aiva gives hotels the intelligence to anticipate what guests want and the ability to make it happen. Hotels already know a lot about their guests, but that information sits across disconnected systems. Aiva connects guest preferences with hotel services, availability and operations, then coordinates the actions needed to deliver the right experience at the right time. For guests, that means a stay that feels more personal and effortless. For hotels, it means opportunities to grow revenue throughout each stay while reducing the manual work behind delivering great service.

Hotels already work with numerous digital systems and large amounts of guest data. What makes Aiva different from existing hospitality technology solutions?

Lucía: Most hospitality tech falls into one of two groups. Some tools are systems of record that store data. Others are messaging tools that send what they’re told. Aiva sits between them. It decides what a guest should be offered and when, and then makes it happen. We’re measured on outcomes during the stay, not on how much data we store.

Paula: There’s also a structural difference. Every conversation Aiva has creates a record that doesn’t exist anywhere else: what a guest asked for, what was offered, what they bought, and when. That history never existed in digital form before. The more we run, the better we get at anticipating what guests want, and incumbents can’t copy that by adding a feature.

Who are your primary customers today, and what benefits can hotels expect when they integrate Aiva into their existing technology stack?

Lucía: Our customers are four- and five-star resorts that want to move before the rest of the market and grow their margins. They have longer stays and a wide range of things for guests to enjoy on property, so anticipating what guests want makes the biggest difference there. Hotels can expect measurable additional revenue from services during the stay, priced so the return is a clear multiple of what they pay. They also get fewer small requests landing on staff and, for the first time, a clear view of what their guests actually want.

How has Lucía’s hands-on experience in hotel operations influenced the technical priorities and product decisions you make at Aiva?

Paula: It gives us three non-negotiables. First, it can’t add work for staff. If a feature creates a new task for the front desk, it doesn’t ship. Second, it has to meet guests where they already are, which means WhatsApp and voice, not another app to download. Third, it has to integrate cleanly with the property management system. Lucía knows that asking a hotel to change its core system ends the conversation.

Lucía: It also shapes what we choose not to build. We deliberately don’t do room-rate revenue management. That’s a solved, crowded problem, and it isn’t where resorts lose money during the stay.

Building integrations across different hotel systems can be technically complex. What have been the biggest technological and operational challenges so far?

Paula: Hotel systems are fragmented and often old. Every property management system handles data differently, and some barely expose it. Reading data is one thing. Writing reliably, like posting a charge to a guest’s bill, is much harder, and that’s where most integrations fail. We’ve prioritised depth over breadth, so we get one integration fully right before adding the next.

Lucía: Operationally, the hard part is proving value properly. Hotels have been sold a lot of promises. We run pilots with control groups so the results hold up to scrutiny. It’s slower, but it’s the only kind of proof a revenue owner trusts.

Aiva announced a $1.5 million pre-seed round backed by Comma Capital and 645 Ventures. What convinced these investors, and how are you using the funding to accelerate Aiva’s growth?

Lucía: I think three things convinced them. First, a team that has lived the problem from the operator side and can build the solution. Second, a clear starting point with a direct path to revenue, rather than a vague platform pitch. Third, a data advantage that compounds with every hotel we work with.

Artificial intelligence is becoming increasingly important in hospitality. Where do you see the greatest opportunities for AI in improving hotel operations and the guest experience?

Paula: The biggest opportunity isn’t replacing staff. It’s covering the gaps between them. Hotels already know what great service looks like. They just can’t deliver it to every guest at every moment. Technology that holds context across the whole stay closes that gap.

Lucía: The longer-term opportunity is data. Hospitality has always run on what staff remember. Once those guest interactions are captured, hotels can understand their guests in ways that were never possible before: what to offer, how to staff, what to build. That’s where it compounds.

What are the next major milestones for Aiva, and where would you like to see the company over the next three to five years?

Lucía: In the near term, we’ll convert our pilots into paying customers with published, controlled results. We’ll go deeper on integrations across the systems our resorts use, and turn what we’ve learned into a repeatable way of working with each new property.

In three to five years, I want Aiva to have closed the gap between technology and hospitality. I want it trusted by owners, operators and brands because it grows revenue and improves operations while protecting what makes this industry special: the experience. We’ve built Aiva from inside the industry, not for it, and that shows.

What are the three most important pieces of advice you would give to founders building a technology company together with a close friend?

Lucía: First, split ownership completely and write it down. Who decides what should never be ambiguous. Friendship is not a governance structure.

Paula: Second, have the hard conversations early: equity, roles, what happens if one of you wants to leave. Do it while it’s hypothetical, because it’s much harder when it’s real.

Lucía: Third, protect the friendship from the company, not the other way round. Disagree hard on the work, and never make it personal.

Image photographer Jo Berrojalbiz

Thank you Lucia Mari Sanguino and Paula Rodriguez Jou for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

Reverion raises $175m to scale its fuel cell power plants

0
Reverion funding round: $175m for new German factory

Energy start-up Reverion, based in Eresing near Munich, has closed a $175m Series B round. Deeptech and climate fund Kembara led the investment. Reverion will spend most of the money on a new factory in Germany, which it says will raise output tenfold.

Kembara leads the Series B as Allianz and KfW Capital join

  • Amount: $175m
  • Round: Series B
  • Lead investor: Kembara, the European scale-up fund of Mundi Ventures
  • New investors: Allianz, KfW Capital, aurum Impact, Carbon Equity
  • Existing investors: Extantia, Energy Impact Partners, alfa8, UVC Partners, EIC Fund, Possible Ventures
  • Previous round: $62m Series A (2024)
  • Founded: 2022, as a spin-off from the Technical University of Munich (TUM), by five founders
  • Headquarters: Eresing, Bavaria

The new round takes the total raised across Reverion’s Series A and B to around $237m.

Power from gas, without combustion

Reverion builds power plants based on solid oxide fuel cells (SOFCs). These cells turn gas into electricity through an electrochemical reaction rather than by burning it. The plant also captures the CO₂ from the gas stream in pure form. Operators can then reuse it or store it permanently.

When the plant runs on renewable gas such as biomethane, the captured CO₂ is biogenic. As a result, Reverion says the plant is carbon-negative in operation. The company puts its electrical efficiency at 74.2%, which it describes as a world record. It says it measured this figure at customer sites, using early units from pre-series production. According to Reverion, that is nearly double the efficiency of conventional generators.

The system also works in reverse. In electrolysis mode, it turns surplus electricity into gases that can be stored. This gives operators an asset that can respond to price signals in both the power and gas markets. Stephan Herrmann, CEO and co-founder, sees this as the core of the business: “Solar and wind give us clean energy, but only when the weather cooperates. What the world needs is clean power on tap.”

Seven plants are already in regular operation at customer sites. Reverion has also raised output per unit to 500kW. With the new funding, it plans to push the product into the megawatt class. “That opens up entirely new markets for Reverion,” Herrmann says.

Data centres emerge as a key growth market

So far, most of Reverion’s customers have come from the biogas sector. Now the company is turning its attention to data centres. Many operators face long delays in securing a grid connection. At the same time, public pushback over their energy use is growing. Reverion’s answer is power generated on site. Its plants draw on local gas infrastructure and supply continuous power. As a result, operators become less exposed to grid expansion delays and volatile electricity prices.

The lead investor shares this view. “Solid oxide fuel cells are the most efficient way to convert gas into electricity,” says Robert Trezona, Climate Lead at Kembara. In his view, the growth market lies in powering data centres, where a negative carbon footprint matters as much as efficiency. “Hyperscalers need massive, reliable power, but they cannot compromise on their climate commitments,” Trezona adds.

Felix Fischer, COO and co-founder, reports strong demand from abroad. He says utilities and industrial customers increasingly see dispatchable clean power as essential to energy security. The fresh capital should therefore help Reverion clear its order backlog quickly. In the long run, Fischer is aiming for profitability.

New factory with 250MW capacity and up to 800 jobs

Reverion will invest most of the funds in a new production site in Germany. The factory is set to reach an annual capacity of 250MW, ten times its current output. It is also expected to create up to 800 jobs. At the Eresing headquarters, the team has recently grown from 100 to more than 200 staff.

A large project pipeline lies behind the expansion. According to the company, it carries revenue potential of more than $2bn. Reverion also plans to deliver its first projects outside Germany later this year. For Herrmann, the round marks a turning point: “By closing this Series B, we are laying the foundation for industrial mass production.”

FAQ

How much has Reverion raised?

Reverion raised $175m in its Series B funding round. In 2024, it secured $62m in a Series A.

Who are Reverion’s investors?

Kembara led the round. Allianz, KfW Capital, aurum Impact and Carbon Equity joined as new investors. Existing backers Extantia, Energy Impact Partners, alfa8, UVC Partners, EIC Fund and Possible Ventures also took part.

What does Reverion do?

Reverion builds power plants using solid oxide fuel cells. They generate electricity from gas without burning it and capture pure CO₂ in the process. In reverse mode, they turn surplus power into storable gases.

What will Reverion use the money for?

Most of the funds will go into a new factory in Germany with 250MW of annual capacity and up to 800 jobs. Reverion also plans to scale its plants into the megawatt class.

When was Reverion founded?

Five founders from the Technical University of Munich set up Reverion in 2022. The company is based in Eresing near Munich.

Picture Source Reverion

From Belfast to global markets: How sovereign AI company Whitespace scales

0
Whitespace: AI and Technology for Trusted Operations founder  Paul Jenkinson

Whitespace develops AI and technology for organisations that need secure, resilient and trusted solutions in complex operational environments.

Could you briefly introduce Whitespace and tell us how the company was founded?

I co-founded Whitespace in Belfast in 2015. From the beginning, the ambition was to build technology that could solve difficult, real-world problems rather than technology for technology’s sake.

Today, Whitespace is a British sovereign AI company helping organisations operationalise trusted AI in complex and highly regulated environments. We’ve built much of our credibility in defence and government, where resilience, security and control really matter, and we’re now taking that capability into a much broader global market.

You founded Whitespace around a decade ago. How has the company evolved since then?

We’ve evolved enormously. Whitespace started by building digital products and solving complex workflow problems, which gave us a strong foundation in understanding how organisations actually adopt and use technology.

Over time, particularly through our work in defence and government, we saw a much bigger opportunity emerging around AI. That led to Collective, our AI operating system, which provides the environment through which organisations can use AI securely and build and deploy operational AI applications.

The company has evolved with the technology, but the principle has remained remarkably consistent: start with the operational problem and build technology around the outcome.

What is the vision behind Whitespace, and what role does sovereign AI play in it?

We believe AI is approaching an important inflexion point. The last few years have been about AI learning from historical data, and it has learnt so well it can now generate credible new content, whether text, images, audio, video or code. However, AI that has learnt about the past is very different from AI that can help you decide the future. This is the real inflexion point that we are leading on – AI becoming operational, helping organisations understand situations, make decisions, act, learn from what happens in real time and adapt.

Our vision for Whitespace is to help organisations make that transition. Those that can make trusted decisions faster, continuously learn and adapt will have an enormous advantage. We call that Decision Superiority, and it is fundamental to operational resilience.

Sovereignty is an important enabler of that resilience, but I don’t define sovereignty simply by where a company or model was developed. It comes down to control, choice and resilience: control over your data and technology, the freedom to choose and change suppliers or models, and the ability to continue operating when circumstances change.

Ultimately, we’re building for a world where AI isn’t simply something organisations ask questions of, but something they can trust as part of how they operate.

Whitespace already works with organisations such as the Royal Navy and the British Army. What are their key requirements when it comes to AI?

Defence organisations don’t lack interest in AI. The challenge is turning AI into something they can trust and use operationally.

That means security, governance, audibility and control are essential, but so is resilience. Technology may need to operate across cloud, on-premises, edge and disconnected environments, often with highly sensitive information.

That’s what we’ve designed Collective around. It allows organisations to bring together different models, data, knowledge and AI capabilities within a governed environment, rather than becoming dependent on a single model or supplier.

The technology has to work around the operational environment, not the other way around.

What sets Whitespace apart from other companies developing AI solutions?

We’ve spent a decade building credibility in some of the most demanding operational environments in defence and government. Impressive AI technology means very little if organisations don’t trust you to deploy it against real problems.

Our approach is also different. We start with the decision or operational challenge, rather than a model or dataset looking for a use case. Through Collective and our team, we work alongside customers to build capabilities around those problems.

Collective is designed around resilience and choice, allowing organisations to use different models and technologies without becoming locked into a single provider. And importantly, we build learning into the process – helping organisations decide, act, learn and adapt.

Ultimately, we combine technology, operational experience and proximity to the customer. We’re building AI alongside organisations that need it to work in the real world.

Sovereign AI has become an important topic for governments. What does technological sovereignty mean to you in practice?

Sovereign AI is becoming a widely used term, and I think we need to be careful about what it actually means. A company being British, or technology being built in the UK, does not automatically make the capability sovereign.

For me, sovereignty comes down to control, choice and resilience. Who controls your data and technology? Can you choose where it runs and change models or suppliers? And can you continue operating if access to a provider changes?

That doesn’t mean everything needs to be built domestically. Organisations should be able to use the best technology available without becoming dependent on any single component or supplier.

Sovereignty isn’t isolation, and it isn’t simply a label based on where something was built. It’s having the control and choice to keep operating when circumstances change.

Defence is a highly demanding environment for technology. What have been the biggest challenges for Whitespace so far?

Ironically, the technology often isn’t the hardest part. One of the biggest challenges is getting innovative technology through the processes required to put it into operational use.

Defence understandably has extremely high standards around security, assurance and risk, but procurement processes weren’t designed for the pace at which AI is developing. Smaller technology companies can sometimes prove a capability quickly and then spend considerably longer navigating the route to deployment.

I don’t think the answer is lowering standards – particularly in defence. It’s creating procurement and adoption models that maintain those standards while allowing genuinely capable technology to move much faster from experimentation into operational use.

You have successfully exited two companies and invested in more than 100 tech businesses. How has that experience shaped the way you lead Whitespace?

It’s taught me that technology companies succeed by solving problems people genuinely care about.

I’ve seen incredibly sophisticated technologies struggle because they were looking for a problem, and comparatively simple ideas become enormous businesses because they solved something important.

That’s shaped how we’ve built Whitespace. We spend a lot of time close to customers and the environments in which our technology will actually be used. It’s also taught me not to become too attached to a particular technology or business model. Markets change incredibly quickly, particularly in AI, and founders need to be willing to learn and adapt with them.

How do you see the role of AI in defence evolving over the next few years?

We’re going to see AI move much further into operational environments. The focus will shift from isolated experiments and individual use cases towards trusted, auditable systems that can support people operating in complex and high-pressure situations.

That will make resilience increasingly important. Defence organisations will need AI that can operate securely across different environments, continue functioning when connectivity is constrained, and give users confidence in how outputs and decisions are reached.

The technology is moving quickly enough to make this possible. The challenge now is ensuring procurement, infrastructure and adoption can move quickly enough with it.

What are the next steps for Whitespace, and where do you see the company in the future?

We raised an oversubscribed $13 million Series A last year and are now preparing for our Series B funding round as we enter the next stage of Whitespace’s growth.

We’ve scaled significantly over the past year, and our ambition is to grow the team by a further 50% as we scale Collective, deepen our work across defence and government, and expand our presence internationally, particularly across the US and EU.

Defence has given us an extraordinary environment in which to build and prove our technology, but the challenges we’re solving – operational resilience, complex decision-making, organisational knowledge and control over AI – exist across many industries and markets.

We’re building a global AI company from Belfast, and the next phase is about taking what we’ve proven in some of the world’s most demanding environments and scaling it internationally.

Finally, what three pieces of advice would you give to other founders building technology companies today?

First, spend more time talking to customers than talking to investors. Funding is important, but ultimately customers build companies.

Second, solve a real problem. Don’t start with a technology and then try to manufacture a use case around it.

Third, be prepared to adapt. Whitespace today looks very different from the company we founded in 2015. The ambition hasn’t changed, but the technology, market and opportunity have. Knowing what shouldn’t change – and what absolutely should – is an important part of building a company.

Picturecredits Whitespace

Thank you Paul Jenkinson for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

Tagsight CEO on industrial AI, engineering drawings, and global growth

0
Tagsight, Engineering and AI for Industrial Workflows Image Muaawia Jannat, founder of Tagsight Technologies Inc., based in Calgary, Canada. Image supplied courtesy of Tagsight Technologies Inc.

Tagsight combines Engineering and AI to turn information from technical drawings into structured records and streamline complex industrial workflows.

Could you briefly introduce Tagsight and tell us how the idea for the company came about?

Tagsight is engineering document management and workflow automation software. It helps engineers turn information in drawings and technical documents into records they can review and use, without having to compile everything manually.

I wanted to work on a challenging problem where AI could help, but still struggled to produce the result people needed consistently. Conversations with electrical and process engineers brought me to the amount of time they spent extracting, checking and reconciling information across documents.

The information was often already there. Getting it into a usable, consistent form was still a considerable amount of work. That interested me both as a technical problem and as something worth building a business around. Experienced engineers were spending time on tasks that better software should help them complete much faster.

Who is behind Tagsight, and what experiences led you to focus on engineering data and industrial software?

I’m Muaawia Jannat, founder of Tagsight, based in Calgary. I come from an entrepreneurial family and began building Tagsight while studying computational and applied mathematics at the University of Calgary.

I developed the platform myself, including the AI processing systems, the application and the cloud infrastructure. We have built the company without outside equity investment, and I still lead the product and technical development.

I work with advisors who bring more than 30 years of combined experience in electrical and process engineering. Their experience has been important in understanding what engineers need from the software, including details that would not be obvious from studying the documents alone.

Alongside Tagsight, I work on algorithms and publish technical writing. My writing on engineering information has appeared in the UK’s Engineering Maintenance Solutions, and Calgary.tech recently featured the company.

Engineering teams often work with large amounts of information stored in technical drawings. What problems does this create in day-to-day engineering workflows?

A drawing may contain the information needed for several different tasks, but someone still has to locate it, organise it and put it into the right records. That might mean building an instrument index, preparing an equipment register or checking information against another document.

Revisions add another layer of work. A change on a drawing can affect several records, so someone needs to establish what changed and where that change needs to be carried through.

The burden is keeping all of that information consistent as a project progresses. Copying one item is straightforward. Doing it across a document set, retaining the context and checking subsequent changes takes a lot of skilled attention.

Tagsight turns information from industrial drawings into structured records that engineering teams can review and use. How does this process work in practice?

An engineer uploads a drawing set into a workspace. Tagsight extracts the relevant information and organises it into engineering records.

For a piping and instrumentation diagram, those records can include an instrument index, an I/O list and an equipment register. The engineer can inspect the extracted information alongside the original drawing, check where an entry came from and make corrections.

The reviewed records can then be exported to Excel or supported engineering formats.

Instead of starting with an empty spreadsheet, the engineer starts with prepared information and the source available for checking. The aim is to make that information useful in the next task, rather than simply produce a summary of the drawing.

AI is becoming increasingly common in engineering software. Where does AI create the greatest value within Tagsight, and where is human verification still essential?

AI is most useful in the detailed preparation work: identifying information in drawings, organising it and reducing the amount that has to be entered by hand.

The engineer still needs to determine whether that information is correct, complete and suitable for its intended use. Recognising a component on a drawing does not amount to approving an engineering decision.

Keeping that review step does not give the software a pass on accuracy. It still needs to produce useful work and save time once checking and corrections are included. Otherwise, we have only moved the effort from one task to another.

Engineering data can be highly sensitive and errors can have significant consequences. How do you approach accuracy, security and reliability?

These documents can relate to infrastructure where a mistake has consequences for equipment and people’s safety. We do not treat an AI-generated record as an approved engineering deliverable.

The extracted information needs to remain traceable to its source, open to correction and subject to engineering review before it is relied on. Different drawing styles and document quality also create different challenges, so reliability has to be considered across the kinds of documents people actually work with.

On confidentiality, we do not train models on customer engineering data. Those documents can contain years of proprietary work. Protecting that intellectual property is fundamental to the relationship we want with engineering firms. Using our software should help them make better use of their information while leaving their expertise and intellectual property theirs.

Tagsight has users on its evaluation plan across more than 30 countries. How many companies are actively using the platform today, and how many of them are paying customers?

We have more than 100 people on Tagsight’s evaluation plan across more than 30 countries.

We have recently started ramping up the commercial side of the business and are keeping active-company and paying-customer figures private at this stage.

We are in early discussions with a few engineering, procurement and construction firms in Canada and the United States, and we recently demonstrated Tagsight to a major EPC in Taiwan. We are also seeing interest from Europe, particularly the Netherlands and Germany.

That international interest has been encouraging at this stage of the company. Our focus now is on growing commercial adoption.

You decided to address a highly specialized industrial market rather than build a broad AI product. Why did you choose this particular niche?

I was interested in work that still required substantial technical development, even with capable AI models available.

Engineering drawings are a good example. A model might recognise a label but associate it with the wrong item, or handle one drawing well and miss important information on another. The task requires understanding symbols, text and relationships, then producing records that an engineer can actually use.

That gap between what AI can attempt and what the work requires is what interested me. There is a difficult problem to solve, and a clear reason to solve it: engineering firms are already spending considerable time doing the work manually.

It also serves companies of different sizes. A small specialist firm with decades of experience can benefit from better tools just as a large EPC can.

Industrial companies often rely on established systems and workflows. What is the biggest challenge when convincing engineering teams to adopt a new software solution?

The biggest challenge is demonstrating value on their own work.

A team needs to see how the software handles its documents, how much checking is required and whether the result fits the tools and deliverables it already uses. Those questions matter more than a demonstration on a carefully selected example.

I also do not expect a firm to change its whole process around our product. Established workflows often reflect years of experience and accountability. We need to understand those processes and show where Tagsight can remove effort without creating unnecessary disruption or taking control away from the engineer.

Building internationally from Canada gives Tagsight access to a global market from an early stage. Which regions or industries currently offer the greatest opportunities for growth?

North America and Europe are both important to us. We are having early conversations with EPCs in Canada and the United States, and the interest from the Netherlands and Germany makes Europe an important part of our commercial outlook as well.

Our focus is on electrical, process and controls engineering, including both specialist firms and larger EPCs. That includes work on new infrastructure and existing facilities, where drawing archives and successive revisions can involve substantial document reconciliation.

Data centres are another area of interest because of the electrical and supporting infrastructure involved. We see an opportunity to support the engineering firms delivering those projects.

The company is based in Calgary, but we are building for an international engineering market.

What is your long-term vision for Tagsight, and what are the next major milestones for the company?

I want Tagsight to become a standard part of how engineering firms manage their information and deliver projects.

A firm may have spent twenty years developing its expertise. Our role is to help it get more work done with that expertise by reducing the repetitive effort around documents and data.

The next milestones are to expand commercial adoption, improve processing speed and reliability, and support more of the documents and workflows engineers already use.

We do not intend to become an engineering services company ourselves. We build software for engineering firms so they can deliver their services better. Their engineering knowledge, client relationships and intellectual property remain theirs.

What are the three most important pieces of advice you would give to founders building AI-powered B2B software for specialized industries?

First, learn what the completed work needs to look like. Ask practitioners to show you the deliverable, the checks and the steps required to get there. That helps you understand what the product actually needs to accomplish.

Second, account for the person who is responsible for the result. Give them a practical way to inspect and correct the output. Measure whether you save them time across the whole task, including review.

Third, work with real inputs early. Different drawing styles, older scans and inconsistent information will reveal problems that clean examples do not. Those are the problems the product will have to handle in practice.

Image Muaawia Jannat, founder of Tagsight Technologies Inc., based in Calgary, Canada.
Image supplied courtesy of Tagsight Technologies Inc.

Thank you Muaawia Jannat for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

Evveko founder on Istanbul urban renewal and PropTech growth

0
Evveko: renewal platform for apartment owners Yusuf Kara Founder, Evveko Picture credit: Emlak Konut – Anahtar Fikirler Summit

Evveko helps owners navigate apartment-building renewal by connecting them with verified contractors and making proposals easier to compare

Could you introduce yourself and Evveko and tell us what inspired you to start the company?

I’m Yusuf Kara, founder of Evveko. Evveko is an Istanbul platform that helps the owners of an apartment building go through urban renewal (kentsel dönüşüm) together: they apply for their building, verified contractors reach them, and each owner can see what a proposal means for his or her own flat. The idea came from watching renewal decisions stall for years, not because the numbers were bad, but because a dozen owners could not compare proposals on the same basis or trust the company across the table.

Your background is in civil engineering. Which experiences made you realize that apartment-building renewal needed a better coordination process?

Working in construction, I saw the same meeting again and again: one contractor, many owners, a proposal expressed as a percentage split of flats, and very little shared information. Owners did not know their building’s zoning rights, their own share of floor area, or how to compare two offers. The technical part of renewal is well understood in Turkey; the coordination part is not.

What are the biggest challenges owners face when trying to agree on a renewal project?

Istanbul renewal projects typically need the agreement of the owners who hold a majority of the shares, so a building is only as fast as its most hesitant owner. The recurring issues are information asymmetry, fear of choosing an unreliable contractor, rent and relocation costs during construction, and simple uncertainty about “what will my new flat look like and what will I pay?”.

How does Evveko work, from an owner’s application to comparing proposals?

An owner or building manager applies online in about two minutes. After a short phone conversation, the application is published on the platform in one of two models. In the direct-contact model, contractors whose documents have been approved by Evveko can message the owners through the platform; owners’ phone numbers stay hidden. In nine districts we also run a managed-dossier service: we prepare the building’s zoning information, unit list and floor areas, and contractors submit proposals on the same data, so owners compare like with like. Our calculators turn construction prices and the flat allocation into an estimate for each owner.

How does Evveko check contractors before they can contact owners?

A contractor cannot send a proposal or a first message until its tax registration and its construction contractor authorization certificate (yapı müteahhidi yetki belgesi), which is issued by the Ministry, have been reviewed and approved by our team. We describe this honestly as a document check; it is not a guarantee of the contractor’s work, and we always encourage owners to review contracts with their own lawyer.

How does your business model work?

Owners never pay. Contractors can use the platform for free with one new application contact per month; paid monthly packages give them more contact rights plus tools such as specification, contract and flat-allocation modules. In managed-dossier projects, Evveko earns a success commission from the contractor when the renewal contract is signed.

What have you learned from operating across all 39 districts of Istanbul?

Demand is everywhere, but the market is very local: land values, building ages and contractor networks change from one neighbourhood to the next. That is why we open applications city-wide but keep the hands-on dossier service in nine districts where we know the ground well.

What traction has Evveko achieved so far?

Since we started taking applications at the end of 2025, around 140 buildings have applied, close to 600 people have registered and about 95 contractor firms have created accounts. Our renewal guides reach over 3,000 visitors a month from Google search, and our Android app is live. Renewal decisions take many months, and we do not yet have a completed renewal delivered through the platform; our focus now is increasing the number of verified contractors who actively respond to owners.

What have been the biggest challenges in building trust?

Trust has to be earned on both sides at once. Owners are cautious because the sector has well-known horror stories; contractors are cautious because they have been asked for many “free” offers that went nowhere. Being transparent about what we check and what we do not, and not charging owners anything, has been essential.

How is Evveko financed?

Evveko is founder-funded so far. We are alumni of Emlak Konut’s PropTech programme and are based at BTM, the Istanbul Chamber of Commerce’s innovation and incubation centre. We will consider external investment once the contractor side of the marketplace is repeatable.

What are the next milestones, and could the model expand beyond Istanbul?

Our next milestones are growing the pool of document-verified contractors, reaching our first signed renewal contracts through managed dossiers, and bringing document upload to the mobile app. Urban renewal is a national programme in Turkey, with major cities such as Izmir, Bursa and Ankara facing the same challenge, so expansion within Turkey is the natural next step. Multi-owner building renewal is a problem in many earthquake-prone and ageing cities, so the model could travel later on.

Three pieces of advice for PropTech founders in an emerging market?

First, the software is the easy part; the offline process around it is the product, so spend time in the meetings your users sit in. Second, be precise about your promises: in real estate, one overclaim can cost you the trust you spent a year building. Third, watch the side of the marketplace that is harder to win; for us it has been the contractors, not the owners.

Image Yusuf Kara Founder, Evveko Picture credit: Emlak Konut – Anahtar Fikirler Summit

Thank you Yusuf Kara for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

Growth Without Employees: How Vizura Studio Redefines B2B Tech Branding

0
Branding: Vizura Studio for Technology Companies Vedran Obradović Vizura Studio

Vizura Studio founder Vedran Obradović explains why branding matters for technology companies and how he is building an international specialist studio from Zagreb.

Could you briefly introduce yourself and Vizura Studio and tell us what inspired you to start your own branding studio?

I’m Vedran Obradović, founder and designer behind Vizura Studio®, a one man branding studio based in Zagreb, Croatia. I work mainly with B2B and technology companies across brand strategy, positioning, logo design, identity systems and digital experiences.

Vizura really came from wanting to build the kind of design business I personally would want to hire.

I never liked the idea of a client speaking to one person during sales, someone else during strategy, and then seeing the actual work passed further down the chain. I wanted the person making strategic decisions to also be the person designing the identity and speaking directly with the client.

Anzeige

Over time, that preference became the actual business model.

What interests me now is seeing how far a deliberately small studio from Zagreb can go internationally without pretending to be a much larger agency.

You describe Vizura Studio as a one-man branding studio rather than a traditional agency. Why did you consciously choose this business model?

Because I think growth and headcount are two different things.

Creative businesses are often expected to follow the same path: hire more people, add account managers, create departments and eventually become an agency. I never really accepted that as the only definition of progress.

I wanted Vizura to grow through better work, stronger clients, larger problems, deeper expertise and more international reach.

A one man model also creates a very simple promise. The person you speak with at the beginning is the same person thinking through the strategy, designing the identity and caring about the final detail.

Fewer layers also mean less information gets diluted between stages.

Capacity is obviously more limited, but I would rather solve that problem carefully than make the business bigger simply because bigger is supposed to mean more successful.

So I’m not keeping Vizura small because of a lack of ambition. I’m testing whether ambition can look different.

What does strong branding mean for B2B and technology companies, and why is it particularly important for startups?

For me, strong branding is not about making a company look expensive. It is about making the company easier to understand, easier to remember and easier to trust.

B2B and technology companies often sell something complex, invisible or technically difficult to evaluate quickly.

Buyers usually cannot inspect an entire product before forming an opinion. They are already judging the company through its website, messaging, visual identity, presentation and overall consistency.

Startups sometimes treat branding as a cosmetic layer that can be added once all the “serious” work is finished. I think that underestimates how much perception affects growth.

A company can have an excellent product and still create unnecessary friction if it looks unclear, generic or less mature than the technology behind it.

Good branding helps close that gap between actual capability and perceived capability.

You have worked with companies across technology, AI, enterprise IT and electronics. What are the biggest branding challenges you see in these industries?

One of the biggest problems is sameness.

Technology companies are often surrounded by the same references, same competitors and increasingly the same AI generated inspiration. Everyone wants to communicate intelligence, speed, innovation and trust, so entire categories gradually start using the same visual language.

Complexity is another major challenge.

Technical teams usually understand exactly why their product is exceptional, but a lot of that difference gets lost by the time someone encounters the company from the outside.

I have recently worked across projects including heyMirai, Deepsea Networks, Verticomm, Talentix, Breach.ai and Soldered Electronics. The industries and products are different, but the underlying problem appears surprisingly often.

Companies know what makes them different internally. Branding has to make enough of that difference visible externally without reducing a sophisticated product into vague marketing language.

Many founders invest heavily in developing their product but think about branding much later. At what point should branding become part of a startup’s strategy?

Earlier than most founders think, but that does not necessarily mean investing in a huge branding project on day one.

Early on, clarity matters most. Who is this for, what problem are we solving, why should somebody care and why are we meaningfully different?

A more complete identity system becomes increasingly important once the company starts asking the market for greater trust.

That moment might come when moving upmarket, raising capital, hiring important people, entering a more competitive category, approaching enterprise customers or simply reaching the point where the product has matured faster than the brand.

I see that last situation quite often.

Product, team and ambition evolve quietly while the brand keeps communicating the much earlier company.

Once the gap between what the business has become and what the market perceives becomes too wide, branding stops being decoration and starts becoming a business issue.

How do you translate complex technologies and products into a brand identity that customers can quickly understand and trust?

I normally begin by removing complexity before adding design.

Technology companies naturally want to explain everything because they have spent years building everything. Customers rarely need everything at once.

My first question is usually not what the logo should look like. It is what someone needs to understand within the first few seconds for the rest of the story to make sense.

Positioning, language and visual identity should then reinforce the same core idea.

Visual design becomes a kind of compression system. Typography, hierarchy, colour, imagery, motion and the logo all help communicate maturity, precision and character before someone reads a detailed explanation.

Trust rarely comes from one impressive element.

It comes from many small signals consistently agreeing with each other.

Vizura Studio is based in Zagreb, but you are building an international specialist business. How have you managed to attract and work with clients beyond your local market?

The internet removed geography much faster than it removed perception.

Technically I can work with a company almost anywhere, but that does not automatically mean an international client will trust a designer in Zagreb with an important part of their business.

A lot of the work has therefore been about reducing that distance through portfolio quality, communication, positioning and the way Vizura presents itself.

Platforms such as Upwork played an important role earlier because they created access to international companies that would otherwise have been much harder to reach.

Every strong project then becomes another piece of proof.

My goal now is to make Vizura itself visible enough that geography becomes interesting context rather than something that needs to be overcome.

I actually like building the studio from Zagreb. I do not think somebody has to move to London, New York or San Francisco before they are allowed to think internationally.

What are the advantages of working as a highly specialized independent studio compared with building a larger agency team?

Speed of understanding is probably one of the biggest advantages.

When the same person hears the founder explain the problem, develops the positioning, explores the identity and builds the final system, very little information disappears between stages.

Decision making is also faster because there are fewer layers of interpretation.

Accountability becomes very clear too. There is nowhere for work to disappear inside the organisation. If a decision is good, I made it. If something is wrong, it is also mine to solve.

Specialisation matters just as much.

I would rather become exceptionally useful to a narrower type of client than moderately useful to everyone.

For Vizura, that increasingly means B2B and technology companies where clarity, trust and perceived maturity genuinely affect business outcomes.

I do not think this model is automatically better than a large agency. Some projects genuinely need large multidisciplinary teams.

But many companies are looking for senior thinking, direct collaboration and speed more than organisational size.

At the same time, where do you see the biggest challenges of running a one-person business while working with international clients?

Capacity is the obvious challenge.

When you are the strategist, designer, project manager, salesperson and studio owner, growth cannot simply mean putting more projects into the calendar.

That forces me to be disciplined about which projects I accept and sometimes means saying no to work that would look attractive financially in the short term.

Poor prioritisation also becomes expensive very quickly. If I spend three hours on something that does not matter, there is no larger team absorbing the mistake.

On the other hand, those constraints have made me much more conscious about systems, communication and how projects are structured.

The next challenge for Vizura is increasing leverage without destroying the reason the model works in the first place.

I’m much more interested in better systems, technology, selective partnerships and smarter processes than automatically turning the studio into a traditional agency.

AI is changing both the technology sector and the creative industry. How is artificial intelligence affecting branding and design, and where do you still see the value of human expertise?

AI is making execution abundant.

Concepts, images, copy and variations can now be produced at a speed that would have sounded ridiculous only a few years ago.

I think that is genuinely useful.

An interesting consequence appears when polished output becomes easier to create. Simply producing something polished becomes less valuable.

Value starts moving toward judgment.

Which idea is actually relevant? Which direction is ownable? What should the company avoid saying? Which visual choice is distinctive rather than fashionable? What will still make sense several years from now?

AI is very good at giving you more.

Branding often depends on knowing what to remove.

There is also a real risk of companies using the same models, prompts and reference pools gradually moving toward the same average aesthetic. Parts of AI and SaaS already show signs of that.

So I do not see human expertise disappearing. Its value is shifting further toward taste, context, decision making and responsibility for the final answer.

What are your plans for Vizura Studio over the next few years, and how do you want to grow without becoming a traditional agency?

I want Vizura to become more specialised, more recognised and more international without becoming unnecessarily complicated.

The direction is increasingly focused on B2B and technology brands, especially companies where trust, complexity and differentiation are real business problems rather than purely aesthetic ones.

I also want the studio to become known for a point of view, not only for a portfolio.

That means publishing more, contributing to conversations around branding and technology, building stronger case studies and creating visibility beyond platforms where somebody is already actively searching for a designer.

Growth for me would mean better projects, stronger relationships, greater reach, smarter systems and more intellectual property around the way I work.

There may absolutely be specialist collaborators and partners around Vizura as projects become more ambitious, but I want to protect the direct relationship between the client and the person responsible for the thinking and work.

I would rather build an extremely strong specialist studio than a larger agency simply because larger sounds like progress.

Finally, what three pieces of advice would you give founders who want to build a specialized business and establish themselves internationally?

  1. Be specific enough that people can remember why you exist. Trying to be relevant to everybody usually makes a business harder to remember. Specialisation gives the market a reason to associate your name with a particular type of problem.
  2. Build proof before trying to manufacture perception. Strong positioning and a good website help, but eventually people need evidence. Do excellent work, document it properly, collect real results and turn every strong project into credibility for the next one.
  3. Do not wait for geography to give you permission. International clients do not necessarily care where your desk is. They care whether you understand the problem, communicate clearly and can deliver at the level they need.

International credibility is usually built one project, one relationship and one piece of proof at a time.

That has probably been one of the biggest lessons for me personally.

Zagreb is where Vizura is based. It does not have to define the boundary of what Vizura can become.

Picturecredits Ilaria Perrella

Thank you Vedran Obradović for the Interview

Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.

LATEST NEWS

Moonlit: Data Layer and Commentaries for Legal AI Roderick Lucas

From Corporate Innovation to an Independent Startup: A Bold Move into LegalTech

0
Moonlit founder Roderick Lucas explains how the company is transforming legal research through verified legal data and AI-powered technology. He discusses the Data Layer, freely accessible Commentaries, the company's origins at Deloitte and its plans for international growth.