Then I hit the next problem.

The memory was useful, but it was trapped in one shape. Claude Code had one way to hold project rules. Codex had another. ChatGPT had another. Local agents had files. Some frameworks had vector stores. Some had graph stores. Some had nothing. Every tool was learning the same things about me and my projects, but none of them could share those memories in a clean way.

That is why I started Universal Memory Protocol, or UMP.

The simple version:

MCP lets agents use tools. A2A lets agents talk to agents. UMP lets agents carry memory.

It is not meant to be a new database. It is not meant to replace Recall, Mem0, Letta, Zep, Obsidian, Postgres, SQLite, Redis, or a vector index. It is the small contract between them.

The Shape

UMP is deliberately small:

1. A portable memory record.
2. Six core operations.
3. MCP, HTTP, and file bindings.
4. Conformance levels from simple export to full signed runtime.

The record is the main thing. A memory needs a type, a body, a scope, time fields, lifecycle hints, relations, provenance, consent, and integrity.

In normal words:

what is this memory, who owns it, where is it valid, when was it true, where did it come from, who may see it, and can I verify it?

That sounds obvious, but most agent memory today does not carry all of that. It might have text and an embedding. It might have a user id. It might have a timestamp. But the moment you try to move it from one agent or store to another, the missing fields matter.

If a memory says “use pnpm”, is that global, repo-specific, team-specific, or only true for one branch? If it says “the deployment target is staging”, was that true yesterday or is it true now? If an agent wrote it, did the user approve it? If it contains a secret or personal detail, should it be exported at all?

UMP puts those questions into the record instead of leaving them as product-specific behavior.

How I Came To It

The first version of the idea came from pain, not architecture.

I use multiple agents. I switch between tools. I also work across enough repos that the same mistake keeps coming back in different clothes. One agent learns a rule, another agent does not know it, and I become the bridge.

Recall proved the useful part: corrections can become repo memory, memory can be ranked, stale memories can be retired, and the agent gets better without a giant instruction file.

But Recall also made the protocol gap obvious. The useful abstraction was not “Recall”. It was:

an agent needs to ask for relevant memory, write new memory, revise old memory, forget unsafe memory, and prove where memory came from.

That maps cleanly to operations:

That is enough for a small client. It is also enough for adapters. A fancy graph memory system and a simple JSON file can speak the same verbs, while still behaving differently underneath.

What It Fixes

UMP fixes four practical problems.

First, memory lock-in. If Claude learns a project rule and Codex cannot read it, that is not memory. That is product state. UMP makes the memory record portable so it can move between hosts and stores.

Second, stale memory. A lot of memory systems overwrite facts. That is dangerous because old context disappears and the agent cannot reason about when something was true. UMP uses bi-temporal records and supersession. A memory can be replaced without pretending the old one never existed.

Third, trust. Recalled memory is not sacred. It can be wrong, stale, malicious, or out of scope. UMP treats memory as untrusted input and requires safe rehydration before it enters the model context. The context block says, in effect, “these are references, not instructions.”

Fourth, ownership. A useful memory record should carry provenance, consent, and eventually signatures. UMP uses existing standards where they fit, like W3C PROV for provenance, DID for owner identity, and RFC 8785 JSON canonicalization for deterministic signing.

The important point is what UMP does not try to fix. It does not decide which embedding model is best. It does not mandate graph search. It does not freeze a decay curve. It does not tell Recall, Zep, Letta, Mem0, SQLite, or Postgres how to rank memory.

It standardizes the parts that must match for memory to travel. The intelligence stays inside the engine.

How It Runs

The fastest way to use it is through MCP, because most agent hosts already know how to talk to MCP servers.

{
  "mcpServers": {
    "ump": {
      "command": "npx",
      "args": ["-y", "@universalmemoryprotocol/core", "ump-memory"]
    }
  }
}

That gives the host ump.recall, ump.remember, ump.get, ump.revise, ump.forget, and ump.capabilities.

By default, the reference server writes a portable file at:

~/.ump/memory.ump.json

Point another MCP host at the same store and it can use the same memories. That is the money shot: write in one agent, recall in another.

There is also an HTTP binding for apps that do not speak MCP, and a file binding for plain exports. That matters because adoption should not require the full runtime. A project can start at L0 with a *.ump.json or *.ump.md file, then move to an L1 or L2 server later.

How Fast It Is

For the default local file store, the answer is boring and good: around 5ms recall at 3,000 records in the current benchmarks. That is the right default for most project memory. It is local, portable, and fast enough that the agent does not feel like it is waiting on a separate brain.

The richer Recall-backed path costs more because it does actual semantic retrieval. In my current benchmark notes, it is roughly 100ms to write and roughly 200ms to recall after warming the local embedding model. The tradeoff is quality: paraphrase top-1 recall improves from 1 out of 8 with lexical matching to 5 out of 8 with Recall’s vector plus BM25 search.

So the rule is simple:

Fast memory is useful because agents ask for memory often. But retrieval quality matters too. UMP keeps that choice open. You can start with the file store, then swap the backend when the shape of the work needs it.

The Part I Care About

The part I care about is not that UMP exists as a spec. Specs are cheap.

The part I care about is the round trip:

an agent writes a memory, another agent recalls it, the record is still owned by the user, and the receiving agent treats it as scoped reference data instead of hidden instruction text.

That is the missing piece for serious agent work. Agents are getting better at tools through MCP. They are getting better at coordination through A2A. But they still forget, fork, and trap memory inside product-specific state.

I do not want every new agent to start from zero. I also do not want all my working memory locked inside one vendor.

UMP is my attempt to make the layer small enough to adopt and structured enough to trust.

One record. Six operations. Memory that moves.

Then you watch long enough and the same shape keeps showing up. The agent looks great for the first half of the task, sometimes the first ninety percent, and then the workflow hits a login wall, a captcha, a 3-D Secure popup, a card form that wants a human phone tap, and everything stalls. The agent was good enough to make the stall feel absurd. That is new. A year or two ago the impressive part was that it could move through the task at all.

That is the actual story of computer use right now. Agents got useful faster than the systems around them got ready to trust, verify, and bill them.

the cursor is the new interface

For a few years we assumed AI would live in a chat box. Type, answer, repeat. The interface was words.

That assumption is dead. The interface is your operating system now. The agent gets the mouse, the keyboard, the browser tabs, sometimes your card. It does not describe how to do the thing. It does the thing.

Every serious lab is on this. Anthropic shipped computer use in late 2024, and Claude has been driving desktops since. OpenAI followed with Operator. Google has Gemini computer use plus Project Mariner inside Chrome. Perplexity built Comet, an entire browser shaped around an agent. Manus came out of China with a general-purpose agent that books trips, files paperwork, and scrapes whatever you point it at. Microsoft and Apple are wiring this into the OS itself, quieter, slower, much closer to where the real leverage is.

Pick any of them. The message is the same. The agent is the new user.

how far we actually got

Two years ago, asking a model to complete a real multi-step task on a real desktop was a coin flip at best. OSWorld, the most honest early benchmark for desktop agents, was sitting at around 14% when it launched in 2024. The progress since has been fast enough that any single number starts going stale almost immediately.

On “can the agent see and click the right thing”, the field is getting very good. Pixel-grounding benchmarks like ScreenSpot are above 90% for the top models. The eyes work. The hands mostly work. The old joke that agents cannot use computers is aging badly.

On “can the agent finish a real workflow”, the answer is messier. The best systems are now brushing against human baselines on OSWorld-style tasks, which is a ridiculous improvement from 2024. But benchmark parity is not the same thing as operational trust. Newer cross-application evals still show ugly failure rates once the task requires several apps, conditional judgment, cleanup, and persistence. Even a 75% task success rate means one in four things still falls over somewhere.

And that “somewhere” is almost never “I could not read the button”. It is the page reloaded, the login screen came back, a captcha appeared, a popup blocked the click, the cart wants your card, or the agent did the right local action inside the wrong global state.

The cursor is not the bottleneck. The world around the cursor is.

the five shapes people are shipping

There is a tendency to talk about “computer use” like it is one product. It is at least five, and the shapes have very different trade-offs.

The desktop agent runs on your machine and can touch anything you can touch. Anthropic’s computer use sits here. Max power, max blast radius. If it gets confused, it can delete things you cared about. Trust bar is high. Best for power users and developers who can sandbox it.

The browser agent lives inside a tab. Perplexity Comet, Arc’s agent, the various Chromium-based experiments. Safer becuase the world it can break is small, but it hits a wall every time a workflow leaves the browser. Try to download a PDF, sign it, attach it back somewhere, and the seams show up immediately.

The managed agent runs in the cloud. OpenAI Operator is the cleanest example. Convenient because you do not give it your laptop, but the moment the site you care about decides cloud IP’s look like bots, you are stuck in captcha purgatory.

The OS-level agent is the long game. Apple, Microsoft, and Google’s mobile push are all trying to wire agents into the system itself: real accessibility trees, real intents, real content types. When the OS exposes structure, the agent stops guessing. This is also the lane with the most patience, which is why Apple in particular looks slow untill they suddenly are not.

The generalist agent is the demo champion. Manus, Mariner-style long-horizon planners. They will plan your trip, file your form, scrape your competitor. They will also confidently do the wrong thing for ninety steps before failing in a way you cannot easily unwind.

Each shape is real. None of them is finished.

where the workflow actually breaks

If you sit and watch a serious computer-use demo end to end, the failure mode is almost always the same. The agent looks brilliant for the first half of the task and then loses to something boring.

It is not glamorous. Finding the product is easy. Adding it to the cart is easy. Then auth shows up, fraud signals trip, a phone-based 3-D Secure challenge fires off, and the agent stalls because the verification was designed to assume there is a human holding a phone, not a long-running automation.

Most demos quietly stop right before this cliff. The honest ones hand control back to the user at checkout, which kind of defeats the point of an agent.

the protocols are the actual story

The reason buying is so painful is structural. The stack assumes a human in a browser, with cookies, a card on file, a phone for 3-D Secure, and a fraud score built from device fingerprints and behavior. An agent breaks almost every one of those assumptions, and the merchant has no clean way to know “this purchase was authorized by Edi, with these limits, through this agent, for this purpose”. So they either block it, or they let it through and hope.

This is what protocols are quietly fixing. Three layers matter.

MCP is the floor. It is the boring, beautiful plumbing that lets an agent talk to a tool, a database, a file system, an API in one standard way. It is already widely adopted across Anthropic, OpenAI, Cursor, and most serious IDEs. If you are building anything agentic, MCP is the layer you build on, not around.

A2A is the layer above. Google and a coalition of partners pushed it out in 2025 as an open protocol for agents from different vendors to talk to each other. My booking agent calls your inventory agent, they negotiate, work happens, result comes back. If A2A actually catches on, the web stops being a pile of HTML that an agent has to squint at, and starts being a network of cooperating services with structured handshakes.

AP2 is the one I find most concrete. The Agent Payments Protocol, announced by Google with Mastercard, American Express, Coinbase, PayPal and a long list of issuers in late 2025, is an attempt to do for agent commerce what 3-D Secure tried to do for online cards. The agent presents a verifiable mandate signed by the human. The merchant verifies it. The issuer verifies it. Payment flows, with cryptographic evidence at every step. “This agent bought this item for this user with this budget” finally has a real signature behind it instead of a session cookie and a prayer.

If you are a merchant, this is the upgrade path you cannot ignore for long. Either you wire up agent-friendly payments with verifiable mandates, or you start quietly blocking a non-trivial slice of your traffic, because that slice is no longer human.

the messy middle is where we live

The bad news is that none of these protocols are live across the long tail. MCP is the closest. A2A is real but mostly between cooperative parties. AP2 has the right names on the press release and nowhere near enough merchant support to run your week through it yet.

So agents in 2026 are stuck doing two jobs at once.

That is why the moment feels so strange. Agents are good enough to use every day, and not good enough to forget about while they hold your card, your calendar, your inbox, or your company account.

One job is helping the long tail of legacy sites and apps that will never speak A2A by pretending to be a human. This is a perception and resilience problem. Better screen understanding, better recovery when a popup appears, better memory of “I already tried this and it failed”. The flashy demo lives here, and so does most of the brittleness. Every UI redesign quietly breaks an agent somewhere.

The other job is helping the leading edge of services adopt MCP, A2A, AP2, so the next round can be cleaner. This is mostly a trust and identity problem. Who signed the mandate, who is liable, how do we revoke, what audit trail do we keep. Less glamorous. Much more durable.

The winners over the next few years will not be the labs with the flashiest demo. They will be the ones that solve the perception problem and the trust problem at the same time, so the agent is both capable of running a task on a legacy site and credible enough to do it on a modern one. Most of the current crop is good at one and pretending about the other.

what to actually do

If you build software, four things are worth doing this year. Design your UI so an agent can also use it: real accessibility trees, structured labels, predictable flows, not just whatever the design system spat out. Ship an MCP server if you have any tool surface worth exposing. Start thinking about an A2A integration even before you build it, because the shape of your data and identity model matters more than the wire format. If you take payments, track AP2 and similar mandates, even if you do not implement yet, because the fraud and identity decisions you make in 2026 will determine whether you can adopt cleanly in 2027.

If you do not build software, the practical version is shorter. The next few apps you install, ask whether an agent could run it for you. If yes, thats your new productivity ceiling. If no, that is a future migration waiting to happen.

The cursor is moving. Whether it is moved by you or by something acting on your behalf is going to become a question you ask several times a day. I am not nostalgic about clicking through forms. I am, however, nervous about the gap between what these agents can already do and what the systems on the other side are ready to verify, trust and bill. That gap is the work of the next two years, and the companies that close it first are going to look very different from the ones currently winning the demo cycle.

The demo is the easy part. The plumbing under it is the rest of the decade.

This is not only a developer problem. If you run a business, use a banking app, store files in the cloud, or rely on any software at all, you are sitting on top of the same gap. The people building the software are stretched, the libraries underneath are someone else’s code, and the patches arrive long after the holes are already known.

I keep coming back to this when I look at the code I ship, the dependencies I pull in, the agents I let touch my repos, and the speed at which everything around it is moving. The honest answer is that most of us, including me, are not running the kind of security checks the current world deserves. We rely on a mix of “it builds”, “the tests pass”, “I trust the maintainer”, and “I will patch later”. Later usually never comes.

That worked, sort of, when finding a real exploit took a person, weeks of reading, and some luck. It does not work the same way now.

Exploits got cheaper

A few years ago, finding a vulnerability in a serious codebase was a craft. You needed to read the source, understand the protocol, build a mental model of memory, sessions, parsing, auth, and then find the one place nobody thought about. That is still real work, but the floor has dropped.

Now you can hand a model a codebase, a compiled app, a recent change, or a CVE description (CVE is just the public ID for a known security bug), and it will tell you where similar patterns probably live. It will write the proof of concept. It will write the fuzzing harness, the small program that throws garbage at the code until something breaks. It will draft the exploit. Not always correct, not always exploitable, but very often “good enough to be dangerous”.

read code at scale
spot pattern reuse across files
generate payloads in seconds
rewrite the same exploit for ten variants
turn a CVE description into working code
chain small bugs into something useful

That is the new baseline. It does not require a nation state, it requires an API key and patience.

The defensive side has the same tools, in theory. In practice, defenders are slower, because defense is harder than offense. You only need to find one bug. The defender needs to find all of them, in code they often did not write, against an attacker who keeps trying.

Developers don’t get told, or don’t patch

The other half of the problem is human.

Most developers do not read security advisories. They do not run advisory dashboards. They do not check release notes of the libraries they use. They do not know which third-party piece of code, three layers down inside another library, just shipped a critical fix. They install it once, lock it, and move on.

If you are not a developer, picture it like this. Every app you use is a stack of building blocks. Most of those blocks were made by other people. When one block at the bottom turns out to have a hole, every app on top of it has the same hole until someone swaps the block. Most teams are slow to swap.

Some teams have automation. Dependabot opens PRs. GitHub flags advisories. Sometimes a security team forwards a Slack message. But the merge rate is the real metric. Lots of those PRs sit there. Lots of those advisories get closed without action. Lots of teams wait until something breaks in prod to look at it.

Then add the new layer:

agents committing code
agents running migrations
agents installing packages
agents reading secrets
agents calling external APIs
agents creating PRs nobody fully reviews

Every one of those is also a security surface. Not because the agent is malicious, but because the agent moves faster than your review pipeline. If a new dependency is added by an agent and merged by another agent, no human ever looked at the transitive tree. That is fine until it isn’t.

The patch gap is the real bug

When a serious bug becomes public, the world splits in two. There is a small group that patches within hours, and there is everyone else.

The everyone else group is not lazy. They are busy. They have a roadmap. They have features. They have customers. They have an oncall. They have a backlog. The patch goes on the list and the list is long.

Attackers do not wait for the list. The window between disclosure and exploitation in the wild keeps getting shorter. Public PoCs land within days. Mass scanners pick up signatures within hours. By the time a team gets around to upgrading, the weaponized version is already touring the internet.

This is the gap that AI on the defensive side has to close, because no human team is going to close it manually for every project they own.

What better AI security should actually do

Most current “AI security” pitches are still the old security stack with a chatbot bolted on. That is not enough. The shape of the work is different now.

What I actually want is something like a constant listener.

watch the repos I own
watch the dependencies they pull in
watch the advisories the moment they publish
watch the agents that touch the code
watch the diffs the agents create
watch the secrets that show up in logs
watch the configs that change in production

And when something changes, tell me. Not “here is a 40 page report once a month”. More like “this thing you shipped last Tuesday now has a public exploit, here is the upgrade, here is the diff, and by the way the staging deploy already pulls the patched version, want me to roll prod”.

That is a very different product than a scanner that runs once a day and emails a PDF.

It needs to know:

which projects are mine
which versions are deployed where
what the blast radius of an issue is
what fix is safe and what fix needs review
which agent or human last touched the affected code
what to do when nobody answers

That last one matters. A lot of the security gap right now is that there is nobody on the other side of the alert. The alert fires into an empty channel. A good agent should keep nudging until something happens, and escalate if it doesn’t.

The new threat model is also AI

There is another piece nobody likes to talk about much. The threat model now includes other agents.

If your code or product is being read, indexed, or poked at by automated systems, those systems are going to find weak spots a human attacker would not have bothered with. Prompt injection is one of the new ones: hiding instructions inside a piece of text (a customer message, a webpage, a document) that the AI then reads and obeys, as if you typed them yourself. Other categories include leaking secrets through chat, tricking an agent into calling internal services, or abusing the tools you gave it. The reward is too good. Many systems are now reachable through “make the agent do X” instead of “make the server do X”. That is a different category and most of our existing defenses do not cover it.

So security AI also has to think about agentic abuse:

what tools is my agent exposing
what data goes into prompts
what comes back from the model
what side effects can a tool call cause
what would a hostile prompt try to do with my agent
what is the smallest reasonable scope for each tool

If you do not design for this, the first time your agent gets prompt injected through a customer ticket or a scraped page, you will learn quickly.

what i’m doing about it

I do not have a clean answer yet, and I am suspicious of anyone who says they do. But I am very sure of the direction.

The next layer of security tooling has to be:

always on, not weekly
repo and runtime aware, not just static
fast at turning advisories into patches
aware that agents are part of the surface now
opinionated enough to act, not only report
open enough that you can trust what it does

Some of this can be glued together from existing tools. Some of it does not exist yet. Some of it is going to look like a small agent that lives next to your repos and never sleeps.

I think 2026 is when this stops being a “nice to have” for serious teams. The cost of ignoring it is going up every week, because the attackers already upgraded their tooling. The defenders should too.

The boring summary, for builders and users alike: AI did not invent insecurity, but it removed every excuse we used to have for not paying attention. The patch is still our job. The work is just faster on both sides now, and the side that automates better is going to win the next few years.

I open sourced Recall a while back, and I want to write down why, becuase it is the kind of tool I wish someone else had built so I would not have to.

The short version is, every project has unwritten rules. The long version is, those rules keep biting me when an agent ignores them for the fifth time in the same week.

The Rules That Never Make It Into a .md

You can write a CLAUDE.md, AGENTS.md, or README and put the obvious things in there. Tech stack, commands, conventions, deployment notes. Fine. That covers maybe 20% of how a project actually works.

The other 80% lives in your head:

never run migrations without a backup first
in this repo we always update the changelog before merging
in that other repo we never touch the auth middleware without pinging someone
when you commit, also run the docs gate, every single time
after a refactor, regenerate the types, do not skip it
this codebase uses pnpm, the other one uses npm, do not mix them up

You cannot put all of that into a markdown file. Or you can, but nobody, including the agent, will read 4000 lines of “and also remember this.” It becomes noise. Most of it is conditional, situational, or only matters after you have made the mistake once.

So you end up repeating yourself. “Don’t do X.” “Yes, run the tests first.” “I told you to use trash, not rm.” Every conversation, every new session, same corrections. The agent is smart but it has no memory of the last time you yelled at it.

That is the gap Recall fills.

What It Actually Does

Recall is a local memory layer for coding agents. Repo-scoped, file-based, owned by you. Nothing leaves your machine unless you wire a provider.

It learns from corrections, from review feedback, from session outcomes, from explicit “remember this” calls. It compiles those into a small set of trusted instructions per repo. Then it injects them into the agent at the right moment, so the agent shows up to the next session already knowing the rules.

The flow is roughly:

you correct the agent once
Recall captures that as a memory
next session in the same repo, the rule is already in context
if you contradict it later, Recall updates or retires it

It also runs a small daily maintenance pass that merges duplicates, retires stale entries, and tightens fuzzy ones. Memories that are wrong now do not stay forever.

Connects Without an Extra Bill

This part matters to me. I did not want yet another subscription with its own context window, its own tokens, its own dashboard.

Recall connects to the agents I already use, two ways:

Hooks. On SessionStart it injects a minimal block of relevant memories into the agent’s own context. On UserPromptSubmit it does a per-prompt relevence check and adds anything that fits. The agent uses its own tokens to read it. There is no second model running, no proxy, no extra cost.

MCP. When the hook block missed something, the agent can call recall.query, recall.list, recall.report_correction, and friends as regular tools. Same model, same tokens, just a few more tool calls.

So the cost is whatever you were already paying your agent provider. Recall itself is local, free, and does not phone home.

Why Opensource

Because this is exactly the kind of thing that should not be closed.

Memory for agents is going to be a default feature, not a moat. Everyone building serious agentic workflows is going to need something like this, and a closed SaaS version of it is a bad idea: your corrections, your repo conventions, your unwritten rules are some of the most sensitive things about how you work. You do not want them on someone else’s server, indexed for “improvement.”

Local first, file based, inspectable, forkable. If you do not like how it ranks memories, change it. If you want a different injection style, override it with an env var. If you want to plug it into a different agent runtime, the hooks and MCP are documented.

This also fits what I was writing about last week. The code alone is not the moat. The moat is the context, the workflow, the trust. Open sourcing the memory layer is not giving anything important away. It is making the layer better for everyone, including me.

What I Want From It

Honestly, I want to stop repeating myself.

I want every repo I touch to remember the unwritten rules. I want new agents I try to inherit those rules without me having to brief them again. I want the corrections I make today to be in context tomorrow. I want to stop writing “do not run X without Y” for the hundreth time.

Recall is not done. It is the kind of project I will keep rethinking because the problem keeps changing. Agents get better, hooks get better, MCP gets better, and the way memories should be retrieved and ranked will keep moving with that.

But the core idea I am sure about. Every project has rules that do not fit in a markdown file. Agents need a place to keep them. That place should be local, opensource, and ride on top of the tools you already pay for.

That is Recall.

I have been working on neni.me, a legal research app built on top of Statute Atlas.

The idea sounds simple if you say it too fast: put Kosovo laws into a database, add embeddings, let people ask questions, return answers with citations.

But that is the demo version of the problem. The real version is much more annoying and much more interesting.

Legal text is not a normal document collection. A constitution, a statute, a regulation, a court decision, and a small amendment are all text, but they should not be treated the same. They have structure. They have dates. They have article numbers. They have official sources. Sometimes they change. Sometimes they reference each other. And if the answer is wrong, “the model sounded confident” is not a good excuse.

So the main work was not building a chat UI. The main work was turning a messy legal corpus into something that can be searched, cited, and trusted.

A Lot Of The Work Is Ingestion

Before the RAG part can be good, the documents have to be clean enough.

Neni has to fetch legal sources, parse the pages or PDFs, extract the actual law text, split it into articles and sections, and keep the metadata around. Things like country, source, document type, publication date, effective date, title, article number, and source URL matter a lot.

If you loose that structure, retrieval becomes mush.

This is why I care about chunking by article or section instead of just cutting every document into random token windows. If someone asks about a legal rule, the answer usually lives inside a specific article, not in some arbitrary slice of 800 tokens. The chunk should know where it came from.

The constitution is a good example. You do not want it only as one big PDF blob. You want each article to exist as a searchable unit, while still keeping its connection to the whole document. Same for statutes. Same for future versions.

Vector Space Is Useful, But Not Magic

The way most people explain this is: embed every chunk, put it in vector space, then find the closest chunks to the user question.

That is basically true, but it hides the hard part.

Legal search needs both semantic similarity and boring filters. If someone asks about a Kosovo company registration rule, the system should not return something that only matched because the wording was kind of similar. It needs country filters, document-kind filters, source trust, article metadata, and sometimes date filters.

So the retrieval layer is more like:

understand the query
normalize it into legal language
search textually
search semantically
merge the results
rerank the best candidates
only then ask the model to answer from those citations

That last part matters. The model should not answer from memory. It should answer from evidence.

Language Makes It Harder

Another problem is how people actually ask questions.

Nobody writes like an official gazette. People ask in Albanian, English, mixed language, Gheg, with missing diacritics, with abbreviations, sometimes with half a sentence. The indexed law text is formal. The query is usually not.

So the system needs a small query-understanding step before retrieval. Not to answer the user, but to translate the question into better search hints: legal domain, possible law titles, and a few formal Albanian rewrites.

This helps a lot because the user might say “qka duhet per shpk”, while the law might talk about “shoqëri me përgjegjësi të kufizuar” or “Ligji për Shoqëritë Tregtare”.

That is the kind of detail that makes the difference between a nice demo and a tool people can actually use.

Performance Is Its Own Product Feature

RAG systems can get slow very fast, idk this part is where the nice demos usually start to break.

Every question can trigger query routing, embeddings, lexical search, vector search, reranking, and final answer generation. If you do that naively, the product feels broken even when the answer is correct.

So a lot of the engineering becomes unglamorous things:

cache query embeddings
cache query rewrites
keep retrieval candidate pools small
cap how many chunks one document can dominate
avoid sending too much text to the model
use metadata filters before expensive ranking
make repeated common questions cheap

This is maybe the least flashy part of AI apps, but probably one of the most important. A legal assistant that takes forever is not good software. It is just a slow demo.

Citations Change The Whole Design

The answer is not the product by itself. The citation is part of the product.

When Neni answers, it needs to show where the answer came from. Which law. Which article. Which source. Ideally with the exact passage that supports the answer.

That requirement changes the architecture. You cannot just throw documents into a vector DB and hope. You need stable document records, version records, section records, chunk records, and enough metadata to trace every answer back to source.

This is also why I like building this as a legal platform, not only one Kosovo chatbot. The pattern should work for more countries later:

official sources first
version the law
index article-level chunks
retrieve with filters
answer only from cited evidence
say “I do not have enough source text” when retrieval is weak

Simple principle, but a lot of engineering underneath.

What I Learned

The funny thing about building AI products now is that the model is not always the hard part.

The hard part is often everything around it: ingestion, data shape, retrieval quality, latency, trust, citations, evals, and all the boring infrastructure that makes the model useful.

Neni is still early, but this project made that very clear for me.

You can build a legal RAG demo in a day.

Building one that respects the structure of law, keeps sources traceable, handles messy language, stays fast, and knows when not to answer is a very different thing.

That is the part I find interesting.

2026 is going to be the year of open source, at least for software builders. Not because everyone suddenly became more kind, but because the market is changing fast and a lot of the easy software is not worth hiding anymore.

Coding is becoming a commodity. I don’t mean good engineering is a commodity, that is still hard and you can see it every time some generated app looks fine but breaks as soon as you try to use it for something real. But a lot of software that people were selling before is now much easier to create. A small app, an internal tool, an admin dashboard, a simple RAG system, a browser extension, a wrapper around an API, some automation between two systems, a small agent that does one thing good enough.

Most of those things can be built with one good prompt if it is simple enough, or maybe with one week of agentic engineering if it has some moving pieces. That changes everything.

easy software is getting hard to sell

for the last years a lot of software was sold just because it was annoying to build. You had to setup auth, billing, database, email, deployment, some UI, docs, maybe permissions, maybe a few integrations, and suddenly even a simple app became a project. Now you can describe most of that to an agent and it will get you very far. Not perfect, but far enough.

And that is the important part. The market does not need perfect for every category. It needs useful, cheap, fast, and good enough to solve the problem. So if your whole product is basically “LLM + prompt + UI”, good luck keeping that closed and pretending it is some big moat. Someone will recreate it. Maybe worse, maybe better, but close enough for many users.

This is why small apps can be done within a day or two nowadays, and bigger things that used to take months can be pushed in weeks if you know what you are doing. It is still very easy to create slop. Actually it is easier than ever. But that also means the value is moving away from just writing code.

the value is not only the code anymore

The code is becoming cheaper. The context is not.

Knowing what to build is not cheap. Knowing the domain is not cheap. Knowing why a workflow is broken is not cheap. Knowing how users actually talk, what they expect, what data matters, what should be automated and what should stay manual, that is still the real work.

I see this all the time. When I built a small RAG system over Kosovo’s laws, the important part was not only embeddings and citations. Everyone can make a demo with that now. The important part was that people ask in everyday language, in Albanian, Gheg, English, no diacritics, slang, abbreviations, and they still expect the right article back. That is the product.

Same with AI over business data. “Chat with your database” is not enough anymore, everyone can do that badly. The hard part is schema-aware prompts, glossary builder, business vocabulary, permissions, joins, aggregations, and making the AI understand the way the company actually thinks about its own data. That is where the value is. The code helps, but the code alone is not the moat.

open source makes more sense now

If the code alone is not the moat, why keep everything closed? This is where I am shifting more and more. I want to open source more things, especially the tools, agents, libraries, scripts, workflows, and small platforms where more people can benefit from seeing how it works.

Not everything should be open source. Customer data should not. Some business logic should not. Security sensitive things should not. Some enterprise features or hosted operations can stay closed. There are still businesses that should sell closed software, no doubt about that.

But a lot of things we build are not in that category. They are useful because they show a pattern. They help someone move faster. They give someone a starting point. They connect two things that were annoying to connect. They make agents work better with real systems.

For those things, open source is probably the better default. People can inspect it, run it, fork it, fix it, and learn from it. It also forces the work to be more honest, because if the code is bad people will see it. In a world full of generated demos, that matters a lot.

open models are putting pressure everywhere

Open source models for coding are already making it harder for Anthropic, OpenAI and everyone else to keep coding as a huge profit center. Closed models are still very good. I still use them. Infrastructure matters. Reliability matters. Tool calls matter. Speed matters. Trust matters.

This is where people get too excited with benchmarks sometimes. Yes, a model can be cheap and score well, but have you actually used it for everyday complex work? If the API is unstable, slow, looping, bad with tools, or hosted somewhere you don’t trust with sensitive data, then the benchmark does not help much.

But the direction is clear. Open-weight models are getting better. Local and hosted options are getting better. Agent scaffolds are getting better. The gap is not what it was before. This means more builders will try open models first for the everyday work, and only use the expensive closed frontier models where they actually need them. That is healthy. It pushes everyone to get better.

agents change the shape of apps

I also think people still underestimate how much agents will change apps. You don’t need a new OS anymore, you need a good agent.

The whole idea is to create apps and platforms that require no or minimal UI to do the things they do. Before you bloat 100 other pages, think one more time if that action should just be available to an agent. Your app is going to need AI integration eventually. Not a chatbot pasted on top.

Real access. Check billing, update users, pull reports, create invoices, search documents, route expenses, talk to your ERP, ask legal questions, whatever the system actually does. That is why I think the apps that survive are the ones that bridge this agentic way of communicating.

And a lot of that bridge should be open, because we all need better patterns for how agents talk to systems. MCPs are token hungry and not perfect, but they are a solid foundation for the future of communication between agents and systems. Same thing with open agents, memory systems, tool protocols, testing loops, browser control, CLI workflows. These things should be shared more.

what you can still sell

Some people hear open source and think it means no business. That is not true.

You can still sell hosting. You can sell support. You can sell setup. You can sell enterprise controls. You can sell integrations. You can sell better reliability. You can sell managed infrastructure. You can sell the boring operational stuff that nobody wants to run themselves. You can sell the part where it actually works.

That is very different from selling a small hidden codebase and hoping nobody can rebuild it. In 2026, if something can be recreated by a one shot prompt or a short agentic coding session, maybe the code should not be the thing you protect. Maybe the code is the thing you give away, and the value is everything around it.

this is the shift

everything is different now. Small apps are cheaper to build. Agents are improving fast. Open models are getting good enough for more real work. Users do not want 100 apps and 100 subscriptions for every small thing. Companies will need bridges between their systems and agents. Developers will want to inspect and trust what they run.

So for me, 2026 is the year to shift more towards open source. Not as charity, and not as some ideology. Just because it makes sense.

If the project is useful as a pattern, open it. If people can benefit from it, open it. If the real value is context, reliability, hosting, data, or domain knowledge, then open source will probably make the project stronger, not weaker.

The code is no longer always the thing to protect. Sometimes it is the thing that gets people to trust you.

Blogging isn’t dying in the age of artificial intelligence it’s transforming into something more powerful and personal than ever before. While 80% of bloggers now use AI tools in 2024 (up from nearly zero in 2022), the most successful content creators are discovering that AI’s greatest value lies not in replacing human creativity, but in amplifying it. The future belongs to bloggers who can harness AI’s efficiency while doubling down on the uniquely human elements that no algorithm can replicate: authentic experience, emotional depth, and genuine connection.

This shift represents the most significant evolution in content creation since the internet’s birth. With over 600 million active blogs competing for attention from 4.4 billion readers worldwide, and search engines processing content through increasingly sophisticated AI systems, bloggers face both unprecedented opportunities and existential questions about their craft’s future.

The current blogging landscape reveals surprising resilience

Despite predictions of AI-driven obsolescence, blogging remains remarkably robust. 83% of internet users read blogs regularly, generating 7.5 million new posts daily and 3 billion annually. The average blog post now spans 1,400 words and takes 3.8 hours to create a 77% increase in length from a decade ago, suggesting readers still crave substantial, thoughtful content.

However, the landscape is undeniably challenging. Only 20% of bloggers report strong results today, down from 30% five years ago. The culprit isn’t AI competition alone it’s the collision of multiple forces: algorithm changes, content saturation, and evolving reader expectations. Google’s March 2024 core update alone reduced low-quality content by 45%, while 53% of bloggers report increased difficulty attracting search traffic.

Yet successful bloggers are thriving. Those earning $50,000+ annually increasingly focus on selling their own products and services rather than relying solely on advertising, with food bloggers averaging $9,169 monthly and established bloggers (10+ years) earning $5,625 monthly on average. The winners aren’t just surviving the AI revolution they’re leveraging it.

AI transforms workflow efficiency while exposing creativity gaps

The numbers tell a compelling story of rapid AI adoption. From virtually zero usage in 2022, AI tools now assist 80% of bloggers with everything from brainstorming to final editing. ChatGPT leads adoption among content creators, followed by Claude for technical writing and Jasper for marketing copy. The productivity gains are substantial: 30% reduction in content creation time and 50% increase in output volume.

But AI’s limitations quickly become apparent to serious bloggers. Current tools excel at pattern recognition and template-based content but struggle with emotional intelligence, cultural nuance, and genuine creativity. They’re prone to hallucinations, repetitive phrasing, and the kind of generic insights that make readers’ eyes glaze over. As one successful blogger noted, “I delete 20-60% of AI-generated content as fluff, then rewrite the introduction entirely to add real expertise.”

The most effective approach emerging is strategic collaboration: AI handles research, initial drafts, and routine optimization, while humans provide the insights, personality, and expertise that create genuine value. This hybrid model allows bloggers to maintain their authentic voice while dramatically improving efficiency.

The authenticity question becomes more urgent, not less

Contrary to expectations, the rise of AI content has made human authenticity more valuable, not less. Industry experts consistently emphasize that emotional connection remains crucial as the market floods with “lifeless, AI creations.” AJ Wilcox, founder of B2Linked.com, argues that “making an emotional connection is going to be more important than ever.”

This creates a paradox: while AI makes content creation more efficient, it simultaneously raises the bar for human creativity. Readers can increasingly distinguish between genuine insight and algorithmic output. The most successful bloggers are responding by leaning into their humanity sharing personal experiences, offering contrarian viewpoints, and providing the kind of cultural context and emotional depth that AI cannot replicate.

Trust metrics reflect this shift. Only 4% of B2B marketers have high trust in AI outputs, while 67% maintain medium trust levels. This suggests that while AI serves as a valuable tool, human oversight and creativity remain essential for building reader confidence and engagement.

Search engines reward quality over creation method

Google’s official stance provides clarity amidst the confusion: AI content isn’t inherently penalized if it demonstrates quality, expertise, and user value. The search giant’s E-E-A-T guidelines (Experience, Expertise, Authoritativeness, Trustworthiness) apply regardless of creation method, focusing on content quality rather than its origins.

However, the reality is more nuanced. Research analyzing 487 search results found that 83% of top Google results are not AI-generated. Google’s updated Quality Rater Guidelines specifically instruct reviewers to give “Lowest” ratings to content that is “all or almost all” AI-generated with little human effort or added value.

The March 2024 algorithm update targeted “scaled content abuse” essentially, mass-produced AI content created primarily for search manipulation. Meanwhile, AI Overviews now appear in 12.47% of searches, potentially reducing click-through rates by 34.5% for traditional results. This suggests that while quality AI content can succeed, the bar for success is rising rapidly.

Successful bloggers are pioneering hybrid strategies

Real-world success stories illuminate the path forward. One blogger launched a new site in January 2023 and reached $15,000+ monthly revenue by October using 90%+ AI-generated content but with extensive human editing, completely rewritten introductions, and significant content reduction to eliminate “fluff.”

The most successful approaches share common elements: AI for efficiency, humans for authenticity. Successful bloggers use AI for research, initial drafts, and optimization, then apply human expertise for voice, tone, fact-checking, and strategic direction. They’re building what experts call “collaborative AI workspaces” that maintain editorial standards while scaling production.

Platform policies support this hybrid approach. Rather than banning AI content, major platforms require transparency and quality control. YouTube mandates labeling for realistic AI-generated content, while WordPress offers extensive AI plugin ecosystems. The message is clear: AI assistance is acceptable, but human oversight and disclosure are essential.

The future points toward collaboration, not replacement

Looking ahead, industry experts predict that AI will become a baseline expectation rather than a competitive advantage by 2025. Andy Crestodina of Orbit Media anticipates that “content marketers will start optimizing their content to appear in AI responses,” similar to how brands adapted to search engine optimization in the late 1990s.

This shift suggests a fundamental change in how content discovery works. With Google’s search market share declining and AI-native search engines like Perplexity and SearchGPT gaining traction, bloggers must prepare for a multi-platform content strategy that optimizes for both traditional search and conversational AI interfaces.

The brands winning this transition will be those who, as one expert put it, “never forget that tech is the tool, but people are the point.” They’ll use AI to enhance human creativity rather than replace it, focusing on building genuine community connections and providing unique value that algorithms cannot replicate.

Practical strategies for the AI-enhanced blogging future

For current and aspiring bloggers, the path forward requires strategic adaptation rather than wholesale change. Start with quality over quantity use AI to improve efficiency, but maintain rigorous editorial standards and human oversight. Focus on developing your unique voice and expertise in specific niches where personal experience and insights create genuine value.

Embrace the hybrid workflow: Use AI for research, initial drafts, and routine optimization, but ensure every published piece reflects your authentic perspective and expertise. Invest time in fact-checking AI outputs and adding the personal touches that create emotional connection with readers.

Diversify your platform strategy beyond traditional search. Build email lists, engage on social media, and consider platforms like Substack or Medium that prioritize direct reader relationships. As search continues evolving, direct audience connections become increasingly valuable.

Stay informed about AI detection and quality standards. Search engines are becoming more sophisticated at identifying and potentially penalizing low-quality automated content. Focus on creating content that would be valuable to readers regardless of how it was created.

The human element remains irreplaceable

The future of blogging in the LLM era isn’t about choosing between human creativity and AI efficiency it’s about combining them strategically. While AI can handle routine tasks and provide research assistance, the elements that make content truly compelling authentic experience, emotional resonance, unique insights, and genuine expertise remain distinctly human.

The bloggers who thrive will be those who view AI as a powerful assistant rather than a replacement, using it to amplify their human capabilities while maintaining the authentic voice and genuine expertise that readers seek. In an increasingly automated world, the human touch doesn’t become less valuable it becomes precious.

The blogging industry’s resilience through this transformation suggests that while the tools and techniques may evolve, the fundamental human need for authentic connection, genuine expertise, and compelling storytelling remains constant. The future belongs to those who can harness AI’s efficiency while preserving the irreplaceable elements that make content truly human.

Dynamics NAV, also known as Navision, is a robust ERP (Enterprise Resource Planning) software backed by Microsoft. Ur&Penn had been using Dynamics NAV for 14 years, where it became deeply ingrained in their daily operations, from Product and WMS to customer interactions via different channels like POS, E-Commerce, Self-Checkout, and more. Ur&Penn is one of the largest retailers in the Nordics, particularly in Sweden, exemplifying innovation and success in applying technology to solve problems and improve employee efficiency.

Building your own ERP is rarely discussed (initially, people called our plans “ambitious” 🤓) due to the complexity and risks involved. However, Ur&Penn boldly ventured into this territory because of the limitations inherent in large-scale commercial software. Specifically, NAV is a generic system that doesn’t easily adapt to the unique needs of each business. While it’s certainly impressive (there’s a reason it’s the most widely used ERP system globally, though its database architecture leaves much to be desired 😬), it makes workflows unnecessarily complex and difficult.

Implementing changes or adding functionality typically takes weeks or months, requiring navigation through multiple channels of resellers or authorized NAV providers. The costs are substantial, which would be acceptable if the software offered comprehensive functionality, but it doesn’t. The POS system must be built or purchased separately, as must human resources modules, finance modules for EU companies, and numerous external integrations that are cumbersome to implement. Due to the high costs, developmental challenges, and endless maintenance requirements for the IT department, the decision to build a custom ERP was set in motion.

As the lead software engineer for this migration project, I was responsible for designing the architecture of our ERP solution, development, and orchestrating the complex data migration from Dynamics NAV. My role involved not only writing code but also mapping business processes, collaborating with department heads to understand their specific needs, and ensuring that historical data remained intact and accessible in the new system while implementing new features. With over 10 years of experience in enterprise software development, I approached this project by first understanding the limitations of our existing NAV implementation, then creating a migration roadmap that minimized business disruption while maximizing the benefits of our tailored solution.

Due to the transactional nature of ERPs, I couldn’t adopt a pure microservice-based architecture. Instead, I implemented a monolithic structure with microservice elements, keeping the core ERP functionality clean and robust for all other modules through what I call “Pipelines”. For example, a sales pipeline that applies consistent logic regardless of the sales channel, based on various parameters. We maintained separate APIs for POS (already developed by Ur&Penn’s excellent team), Self-checkout, E-commerce, HR, Finance, Brand Management, Supplier Relations, Customer Service, and many other integrations.

In this blog post, I’ll share my experience and the challenges we faced while successfully migrating such a complex system, which might prove useful for other technical professionals considering a similar path.

Technical Architecture & Design Decisions

I selected a monolithic architecture because ERP systems are highly transactional and must maintain atomicity. With our available resources (both for development and time constraints), I couldn’t justify experimenting with newer architectural patterns. The monolithic approach allowed us to build core ERP functionality for Inventory (including Purchasing), Sales, WMS, Finance, Ledgers, and other essential functions within a single core engine. Meanwhile, Ur&Penn specific requirements were developed in external APIs, keeping the core more generic and giving us flexibility for necessary integrations without compromising the system’s integrity. This approach enabled us to build an MVP that we successfully launched, with plans for post-implementation improvements, a decision that proved advantageous.

My “Pipelines” concept became one of the most intelligent aspects of the ERP design. These pipelines incorporate one-time validations and logical decision points that handle complex chains of processes affecting multiple components simultaneously, determining whether steps should involve postings, orders, or other actions based on various parameters. This approach saved considerable time when integrating systems like POS with different logical scenarios but identical posting requirements, as we could reuse logic without additional development. The pipelines are sophisticated enough to selectively use transactions based on parameters, making them versatile for chained operations from other pipelines or standalone use (directly from endpoints/mutations).

I prioritized open-source software to avoid licensing complications, selecting PostgreSQL as our primary database, Redis for NoSQL requirements, and Meilisearch as our search engine (sorry, Elasticsearch). For the backend, we implemented JavaScript with NestJS as our core framework. The main API uses GraphQL for 99% of operations, significantly enhancing performance and reducing maintenance needs. We also utilize Python extensively, building supplementary APIs in Python (including ML inference APIs), PHP for POS and existing integrations, and ReactJS for the frontend.

The entire system was designed for serverless deployment from the ground up, allowing easy migration between cloud providers. I initially planned for Kubernetes deployment, but given Ur&Penn’s deep integration with Google Cloud services, we leveraged Google’s serverless offerings. Everything connects to version control with automatic deployment to different environments based on branch via CI/CD. Pre-publication checks ensure zero downtime, complemented by load balancing and automatic scaling.

While I acknowledge NAV’s strengths in reliability and stability once configured, its flaws became most apparent during data migration. The unusual database table structure, lacking defined constraints between table key connections, offers flexibility for adding records but creates challenges for maintaining state and relationships during data insertion. The absence of foreign key constraints caused numerous issues as we encountered deleted data referenced in other tables. After 14 years of data accumulation, Ur&Penn had adapted to this approach, but we couldn’t import records where foreign key connections were missing. This represents one of NAV’s most significant limitations, though it may seem inconsequential to non-technical users once initially configured (despite occasionally affecting business operations).

Migration Strategy & Implementation

Data migration emerged as our primary challenge, delaying our go-live date multiple times due to various complexities. We needed to ensure minimal downtime since Ur&Penn couldn’t close stores during the migration process, requiring creative solutions to transition without operational interruption, which we successfully achieved.

NAV’s lack of key constraints between tables necessitated building a specialized API for data migration. This API mapped all necessary fields from NAV to our ERP, verifying each field’s existence before posting. This process was exceptionally time-consuming due to missing data and fundamental differences in how our ERP handles organizational structures compared to NAV, which doesn’t support multi-company profiles effectively. The approach was necessary given our time constraints and NAV’s SQL implementation without auto-generated keys. Since Ur&Penn operates multiple companies across the Nordic region, we developed logic to consolidate everything into a unified system with hierarchical data structures for master data, organizational entities, locations, warehouses, stores, and other dimensional data.

Testing and validation were conducted manually due to the associated risks and lack of direct comparison methods between systems. Team members, including Purchasers and Inventory Managers, inspected segments of the new system to verify data accuracy (a process that significantly improved our migration procedures, though it required multiple iterations). We performed comprehensive checks across inventory, ledgers, purchases, sales, transfers, items, and other critical areas.

Since we couldn’t simply deactivate one system while activating the other, particularly with e-commerce orders flowing continuously worldwide, we developed a superior approach, albeit one requiring additional effort. We maintained both systems concurrently, establishing a cutoff date after which all integrations would transmit data to both platforms. This strategy enabled us to keep NAV operational as a contingency while validating data and identifying discrepancies in the new system through comparative analysis. This insightful decision from Ur&Penn’s IT department head proved invaluable. We migrated all data preceding the cutoff date and ensured proper connections between pre- and post-cutoff information. For ongoing open orders, we conducted manual data migration cleanup over a sleepless 48-hour weekend. This manual intervention was necessary because NAV structures Sales, Transfers, and Purchases differently across multiple tables, and we determined that developing a comprehensive automated solution for relatively few open orders (with missing foreign key constraints) wasn’t worth the additional development effort.

Challenges & Lessons Learned

Throughout the migration, we encountered numerous challenges. While logical issues were quickly resolved, data problems repeatedly delayed our launch. I learned several valuable lessons through difficult experiences, particularly regarding the importance of thorough initial data analysis. In retrospect, implementing a direct one-time connection migration from NAV to our ERP database, rather than the continuous line-by-line posting approach I chose, would have saved considerable time and reduced complications.

Integration with external systems presented another significant challenge. We maintain numerous integrations with platforms including gift card systems, our custom-built price and promotion engine, HR systems, robotic WMS lifts, AI-powered order forecasting and creation, self-checkout solutions, POS, and many others. I initially estimated completing these integrations within 1-2 months, but they required substantially more time due to dependencies on external validation, coordination meetings, and procedural constraints. This area offers opportunities for improvement by developing more efficient migration methodologies.

Resource limitations also affected our progress. Despite initially having numerous developers available, we encountered difficulties because ERPs represent complex logical systems, and developers struggled to implement logic according to requirements. This created a dilemma: either invest 3-6 months teaching developers ERP process flows or review and revise their work afterward (which proved time-consuming and stressful). While acknowledging potential bias, I believe distributing work across more developers often generates additional meetings, reviews, and coordination overhead, potentially slowing integration, particularly for comprehensive system migrations rather than maintenance or feature development.

Today, Ur&Penn operates with unprecedented time and cost efficiency, and this represents just the beginning since the ERP forms the core and intelligence driving the business forward. Our platforms are intuitive and straightforward, even in MVP form, with plans to implement additional features and functionality that enable employees to focus on objectives rather than processes.

The platform is sophisticated yet architected to facilitate easy feature additions and extensions, both from development and user perspectives. This design reflects 14 years of Ur&Penn’s operational experience and my decade of translating business requirements into functional code.

Conclusion

The journey of migrating from Dynamics NAV to our custom ERP solution has been challenging but immensely rewarding. What started as an “ambitious” plan has transformed into a tailored system that truly fits Ur&Penn’s unique retail operations across the Nordics. By embracing the challenge of building our own solution, we’ve eliminated the limitations, high costs, and endless maintenance cycles that came with our 14-year NAV implementation.

The custom ERP we’ve built provides Ur&Penn with complete control over their technology stack, faster implementation of new features, and significantly reduced operational costs. Our hybrid architecture approach with a monolithic core and specialized external APIs has proven to be the right choice for balancing transactional integrity with business flexibility.

For those considering a similar path, I’d emphasize that building a custom ERP isn’t for everyone. It requires deep technical expertise, business domain knowledge, and leadership support. But for organizations with unique processes and a commitment to long-term technological independence, it can be transformative.

Looking ahead, we’re continuing to refine our system, adding new capabilities and optimizations that simply wouldn’t have been possible or would have been prohibitively expensive with our previous setup. What we’ve created isn’t just a replacement for NAV. It’s a foundation for Ur&Penn’s future innovation and growth.

If you’re considering a similar migration or have questions about our approach, I’d be happy to connect and share more detailed insights from our experience.