Martijn Verbove

I co-founded Doczen with Daniel Volkenstein. We help enterprises find knowledge buried across people, documents and processes, then turn it into working tools, agents and workflows.

I built Gymlab to rethink how my fitness plan gets built. It is an ongoing experiment: building, testing and improving the experience with early users.

Handle reads an X account, organizes its ideas into chapters, and links the writing back to the original posts. Creators can edit and publish an edition that readers can buy.

Equimi groups videos into horse collections, suggests matches for review, and turns selected clips into a link that opens in a browser. The user confirms which horse belongs to each video.

After moving to Portugal, I joined BnBerry as CIO and later became CEO. The work brought hotel systems, distribution and guest messaging together.

We rebuilt History Search as Webscape and integrated OpenAI so people could ask questions about their documents. The company ended after the 2022 invasion of Ukraine disrupted the team.

History Search began as a Chrome extension that saved browsing history in full text. Its limitations led to years of rebuilding—and eventually to Webscape.

I founded and led Pyrean, a development studio. Our work ranged from websites and software to FPGA computing and immersion cooling.

MaterialVV — a piece of my project archive.

Everyone is talking about the autonomous enterprise. Almost nobody is building one, because they’re trying to jump straight to “AI employees” instead of treating the company like software. The practical path is simpler: An autonomous enterprise is a set of business processes that run as loops — and refactor themselves after every run. Just like programming. Vision, viability, and early proof It starts with things AI cannot own: Vision – what kind of company you’re building, who you serve, what “great” looks like in 3–5 years. Taste – how you want the product, brand, and customer experience to feel. But vision alone doesn’t give your company the right to exist. You need numbers that let you keep working on that vision and prove that reality is, at least in a small way, starting to agree with you: Enough revenue and margin to keep going (or enough fundraising, if that’s explicitly the strategy). Retention and engagement that show people actually care about what you’ve built. Growth rate that suggests the system isn’t flatlining. CAC, LTV, and payback that show you’re not just burning optionality. These aren’t about maximizing everything right now. They’re about hitting viability thresholds so the company continues to have a right to exist. In that sense: Revenue, retention, engagement, and growth are signals that your vision is pointed at something real, even if you’re only serving a tiny early segment today. If those signals are improving, you’re earning the right to keep iterating. If they’re not, the system needs to change — because without a viable engine, there is no platform for your vision. Even if you’re building something huge and long‑term, you still have to find an early customer segment: That segment gives you market feedback and real‑world edge cases. Their behavior becomes the raw material your loops work on and learn from. The rest of this article is about how to turn that combination — vision + viability metrics + early segment feedback — into a set of loops that make the organization autonomous. Core idea: processes become source code In a normal company, process lives in: People’s heads Meetings and Slack threads A manager’s personal system In an autonomous company, process lives in artifacts: A written Spec of each workflow A Runner that executes it Logs and metrics that show what happened A Refactorer that proposes upgrades after each run If you want autonomy, your first job is to make work legible. No legibility → no loops No loops → no autonomy 1. The Spec (the “source code”) The Spec defines, in plain language: Objective – what we’re trying to achieve Truth signal – the metric that decides if it worked Steps – inputs → actions → outputs Artifacts – what gets saved so the loop compounds Guardrails – when a human must approve or intervene Cadence – when it runs (daily/weekly) and what triggers it You want to get this mostly right once, then keep improving it. Example: Spec for a “daily ads loop” Objective: Increase qualified booked calls at or below a target CAC. Truth signal: Cost per booked call, not just CTR or impressions. Steps: Pull the last 7–14 days of performance for all active ads. Identify winners and laggards using down‑funnel metrics (booked calls, pipeline, revenue). Propose small variants for winners; propose replacements or pauses for clear losers. Launch micro‑tests with limited budgets and mark which changes were shipped. Artifacts Performance snapshots per run. A list of best hooks, angles, and objections handled. A change log: what was tested, where, and when. Guardrails Human approval on messaging and claims. Human approval on budget changes above a threshold. Hard constraints on segments or geos you will not target. Cadence Runs every weekday at 16:00. Also runs when certain events fire (e.g. a big spend spike, a winning ad’s performance collapses). That Spec is the “source code” of how ads are managed in your enterprise. You can write equally clear Specs for outbound, content, onboarding, retention, support, and internal operations. 2. The Runner (the runtime) The Runner is the engine that follows the Spec. It: Reads the Spec Fetches inputs via APIs (ads, analytics, CRM, support, social, billing) Executes steps (generate creatives, ship campaigns, send emails, adjust budgets, update records) Produces outputs (ads, outreach, tickets, flags, product changes) Writes a RunLog Updates the scoreboard (truth signals and supporting metrics) The Runner should be: Predictable Auditable Repeatable Autonomy is not “freeform creativity.” It’s reliable repetition with clear observability. In the ads loop: The Runner pulls performance data on schedule. Uses AI to generate, for example, 10 variants on the top performer. Prepares candidate changes aligned with the Spec. Sends them for human approval where guardrails require it. Launches approved variants and logs exactly what changed. The same pattern applies to: Outbound loops → fresh lists, drafted messages, sent sequences, logged replies. Onboarding loops → identify drop‑offs, trigger interventions, log outcomes. Retention loops → detect churn risk, propose save actions, execute approved flows. The key: the Runner does not improvise the process; it reads the Spec and executes it, so behavior is consistent. 3. The Refactorer (the learning loop) After each run, the Refactorer asks: What happened? What worked? What failed? What was surprising? What changed in the environment? (trends, competitors, platform, customers) Then it suggests a process upgrade. Not silently. Not automatically. It creates a process change proposal (think “process PR”): A short summary of recent runs and outcomes. Concrete patterns (“Hook A drives cheap clicks but low call quality; Hook B drives fewer but high‑quality calls”). Suggested edits to the Spec (e.g. “add pre‑qualification to our default templates”, “tighten pause thresholds”, “log this edge case separately”). Evidence: metrics, examples, screenshots. A human reviews this, bringing: Focus – is this the most important place to spend attention right now? Context – is the observed pattern real, or explained by something we know (seasonality, launches, outages)? Taste – does the proposed behavior fit the brand and long‑term vision? They then: Review the proposal. Accept, reject, or provide input. AI executes Verify changes Once merged, the Spec is updated. Next run behaves differently. The loop has learned. That’s the compounding engine: every run produces nuance, and nuance is folded back into the main system instead of living in someone’s head. The company as a worktree You can think of the organization as a worktree: The main branch is your current operating system — the set of Specs that are running. Every issue or opportunity (bug, customer feedback, new idea, metric swing, market development) is like a node on that tree. When something matters, you create a branch to work on it. On a branch: AI assembles context into a decision packet: What changed. Where it shows up in the metrics. Three options for how to respond. Evidence and a recommended option. Humans bring vision, context, and taste: Decide whether this really deserves attention now. Adjust the options to fit brand and strategy. Choose A/B/C or define a better option. Then AI and automation help with execution: Ship the experiment or fix. Track its impact on the truth signal. Record what happened in the branch’s RunLogs. If it works: You merge it back into main — update the Spec, document the edge case, log the decision. If it doesn’t: You close the branch, but keep the history for context. Over time, the main branch becomes a living codebase of the organization: How it behaves by default. How it handles edge cases. What has been tried, what worked, and what didn’t. That codebase is the real structure of an autonomous enterprise. Reactive loops: when reality demands attention Reactive loops handle everything that reality throws at you: A metric drifts out of its normal band (up or down). A campaign suddenly overperforms. A channel stops working. Feedback changes tone. A new platform rule, competitor launch, or macro shock hits your space. Reactive workflows are event‑driven. A typical reactive loop: An anomaly is detected A metric crosses an alert threshold. A pattern shows up in comments, support, or engagement. A significant external event is ingested via news/social monitoring. A focused issue is created It is attached to the relevant Spec and recent RunLogs. AI brings all context into one place. A decision packet is created: 2–3 options, evidence, recommendation. People and AI solve it together A human reviews the packet. They decide whether to act, and if so, how far to go. A branch is created with a small Spec for the response. The branch runs and is either merged or closed AI and automation execute the fix/experiment within guardrails. Metrics and qualitative signals are tracked. The Refactorer suggests Spec updates and edge‑case documentation. If successful, the behavior is merged into main; if not, the branch is closed with learnings saved. The key: reactive events never live as random Slack messages or “urgent asks.” They always land inside a known loop, with a Spec, a RunLog, and a path to being merged back into the system. Proactive loops: hypotheses and creativity Proactive loops handle everything you choose to explore: New ICPs or verticals. New channels or formats (TikTok, Shorts, newsletters, communities). New offers or pricing models. New onboarding flows or retention strategies. Proactive workflows are time‑driven and idea‑driven. A typical proactive loop: Start with a hypothesis “If we position this product for med spas on channel X, we can reach Y in new MRR.” “If we add a pre‑qualification step, lead quality will improve enough to justify fewer leads.” Write a Spec for the experiment Objective, truth signal, steps, artifacts, guardrails, cadence. This is the “source code” of the bet. Run the loop AI and tools generate creatives and flows, ship them, and measure results. Humans refine messaging, visuals, and scope to align with vision and taste. Decide what graduates to main If the experiment meets its truth signal while respecting constraints, merge it into the main Spec. If not, keep the logs and insights, and move on. Proactive loops are how you explore new territory without blowing up the core system. Humans + AI on clearly focused issues Across both reactive and proactive loops, the collaboration pattern is simple: The system narrows the problem or opportunity. AI assembles context and proposes concrete options. People apply focus, context, and taste to choose or reshape a path. AI executes the mechanical work, logs the outcome, and suggests how to update the Spec. In other words: People review, then work with AI to solve a clearly focused issue together. They don’t sit in dashboards all day; they’re pulled into specific decisions with good context and real options. What an autonomous enterprise actually is It is not a single “super agent” doing random tasks. It is: Vision and taste held by humans. Vision translated into viability metrics that define the right to keep going. Workflows written as Specs — the source code of how the company behaves. Runners that execute those Specs reliably, on schedule or on trigger. Refactorers that analyze runs and propose upgrades. A worktree of issues and branches where humans and AI collaborate on specific problems. A main branch that keeps getting smarter as decisions and edge cases are merged back in. Reactive loops handle what reality throws at you. Proactive loops explore your hypotheses and creativity. The enterprise is autonomous because: Loops run without you remembering. Issues and opportunities surface with context and options. Decisions and edge cases are logged and folded back into the system. And it stays human because: Focus, context, and taste remain firmly in human hands — where they belong. If this sparked ideas for how you could run your own company as a set of learning loops, share it with someone who’d find it useful and drop your thoughts or questions in the comments — the more real examples we collect, the better these systems get.

Most "AI agents" are just prompts with extra steps. That's not a dunk. That's the whole point. A Managed Agent is three things: → A prompt. The instructions you'd type into ChatGPT anyway. → Tools. Connectors to Slack, Jira, Intercom, Confluence — so it can fetch its own context. → Skills. Reusable playbooks for how the work gets done. That's it. No magic. The hard part isn't building the agent. It's knowing where to point it. And here's where most teams get it wrong: they point it at reports. Daily summaries. Weekly digests. Dashboards nobody reads. It feels productive. It's mostly noise. The real wins are upstream — at the moments where someone is spending an hour collecting context to do five minutes of work. Five places agents actually earn their keep: • Audit your docs against what support actually told customers this week • Auto-build the internal FAQ from repeated Slack questions • Enrich existing Jira tickets with org-wide context — don't open new ones • Sweep Slack + Intercom + Confluence for stale documentation • Draft the customer follow-up while you're still in the room Notice the pattern? None of them are reports. All of them close a loop a human is currently closing by hand. The architecture (managed in Claude vs. self-hosted with the SDK) matters less than where you point it. Swipe through ↓ for the full breakdown.

This post is a bit more personal. It is about Daniel and me, and how we got to building Doczen. We did not come together around a trend. We came together around a problem that had been very real in both of our worlds for a long time. Before Doczen, Daniel Volkenstein had spent years close to large organizations and the consultants working around them. He saw how much time and effort went into understanding how companies actually worked beneath the surface. Not the polished version. The real version. The one spread across teams, functions, and people who each hold a different part of the picture. On my side, I had lived that from a different angle. I had worked in consulting myself, where a big part of the job was gathering input from stakeholders, pulling signal out of a lot of noise, and trying to understand what was really going on inside an organization. Later, while building startups, I felt the same thing again internally. When you are gathering intel across a team of almost 100 people, you realize very quickly how much important context lives in conversations, habits, workarounds, and unwritten knowledge. That stuck with both of us. Again and again, we saw that some of the most valuable information in a company does not live neatly inside a system. It lives in people. In fragmented notes. In back-and-forth conversations. In observations that only come out when you ask the right person the right question at the right moment. And that is where things start to get hard. Because once you begin collecting all of that input, the challenge is no longer getting information. The challenge is making sense of it. Seeing patterns. Spotting what is broken. Understanding what matters. Turning a messy discovery process into something clear enough to act on. That is a big part of what led us to Doczen. Not a grand plan from day one. Not an abstract market thesis. Just years of seeing the same pain from different sides and knowing this part of the work was still far too manual, far too fragmented, and far too dependent on information staying trapped in people’s heads. Doczen came out of that experience. Out of sitting close to the problem. Out of seeing how hard it is to analyze what teams, clients, and stakeholders are really telling you. Out of believing that if you can structure that layer properly, you can help companies move with a lot more clarity and confidence. So this is not just a company we are building. It is a problem we both know personally. And in many ways, that is exactly why we care so much about solving it.

Stop trying to predict which AI skills will matter in 3 years. Nobody knows. The space is moving too fast to plan that far ahead. What you actually need is the ability to pick up any tool and get productive with it fast. That only happens by building real things. Your own agent. Your own workflow. Your own product: - I built to Gymlab to rethink how my fitness plan gets built. - We built Doczen around issues we encountered ourselves. Then put it in front of people. Does it solve a real problem or not? That pressure forces you to learn what matters. Everything connects to something real, which means you stop depending on a single platform, a single skill, or a single employer who will cut you the moment something cheaper ships.

I've been building something for myself called Memex. It's a native macOS app that basically replaces Finder for my personal knowledge base, with an AI agent doing the librarian work. The idea is stolen from Karpathy's LLM-wiki pattern. You don't organize your notes yourself. You just dump raw stuff in a vault: PDFs, screenshots, web captures, whole conversations, entire folders. An LLM maintains the wiki for you. It writes the topic pages, links things together, merges duplicates, and cites every claim back to its source. Under the hood it's deliberately boring. The vault is just markdown on disk. Raw sources never change, and the wiki on top is plain files with wikilinks. No database, no lock-in. The agent is Claude Code running headless inside the vault. Ask it a question and you get an answer with citations. Give it a command and it creates and reorganizes pages while you watch it work in the chat rail. The best part: feeding it is automatic. Memex runs a local interceptor on your Mac that catches your AI conversations. Every Claude Code session gets forwarded the moment it ends, and Claude and ChatGPT chats flow in through the same endpoint. Talk to an AI about something and it's in your wiki minutes later. It also pulls data in through MCPs on a schedule. Gmail, meeting transcripts, whatever has an MCP server. You set the cadence, the agent syncs it in and works it into the wiki. Every source gets a number when it comes in. Every wiki page ends with a table of its sources, and every claim has a citation you can click through to the original file. So the wiki keeps evolving but you never lose track of where anything came from. If anyone wants to try it, comment or DM me.

I’m converting every MCP in my stack into a CLI. Not because MCP is useless, but because it’s the wrong abstraction for day to day agent execution. Agents are processes. Processes already have the best interface we’ve ever invented: the command line. So instead of loading huge JSON specs and tool schemas, I’m wrapping MCP servers behind small, composable commands. This project nails the idea: github >steipete/mcporter Why CLI wins in practice: • tiny surface area (help text vs massive specs) • composable (pipe, chain, script) • debuggable (exit codes, logs, retries) • versioned (your repo owns the interface) • works with any model, any agent runtime My approach now: keep “skills” as the thin reasoning layer, and use CLIs for execution. If you’re building agent systems, I’d seriously consider: MCP -> CLI wrappers -> skills on top.

I’m turning my bookmark bar into a personal toolbox. Bookmarklets are just JavaScript you save as a bookmark. Click one and it runs locally on the page you’re on. No installs, no server, no data leaving your machine. Paradigm shift: your browser isn’t a viewer. It’s a programmable runtime. First two I built: • Remove spam followers on X • 1-click bulk delete LinkedIn invites from recruiter/agency spam Build yours: 1. Open the page you want to automate 2. Tell Claude what you want to automate 3. Discuss the UI you want (buttons/filters/inputs) 4. Ask Claude to inject that UI into the page 5. Drag the “Save to bookmarks” link/button from that UI to your toolbar (now it’s a 1-click tool) Bookmark bar = workflow layer.

When you start building something new, beware that you don't only focus on the size of a problem. Ask yourself: "Are people prepared to pay for a solution?" You'll be surprised how many major problems people aren't prepared to pay to solve.

Don’t optimize pricing for conversion To uncover the optimal pricing strategy: 1) We need to find the highest price point for people who understand the product’s value 2) Then we need to find more of those people and help them grasp it

Those who succeed at building software, aren't a lucky few who envisioned everything correctly But… those who manage to leverage its enormous flexibility to their advantage Always be prepared to Investigate. Iterate. Repeat.

When pitching your product, don't try to anticipate questions and preemptively answer them — it mostly causes confusion. Instead, try to let your story unfold in a way that stimulates questions — and answers them as they arise.

An essential part of listening "well" is letting what is being said have an effect on you - and paying attention to those effects. Dive into logic headfirst, and you'll leave the other person feeling unheard—even if what you say is 100% applicable.

Next time you struggle to focus on something, don’t try to eliminate distractive thoughts. Our minds only know addition, so trying to remove something is actually amplifying that thought. Instead broaden your focus by paying more attention to detail of the task at hand.

Our number 1 priority should be to become the most pleasant human being. First towards yourself, then towards others. This doesn't mean going along with everything, instead, respond to the best of your capabilities. Do this, and the rest will fall into place.

It all started with a simple Chrome extension that saved your browsing history in full-text. Problem: 5MB storage limit = couple thousand pages max. Classic early builder problem: great in concept, wrong infrastructure.

Broke and determined, I started a devshop with classmates in Rotterdam. We built websites during the day while secretly developing the real History Search vision at night. Bootstrap or die.

Then my childhood friend called: "I have a huge project, you're perfect for it." An equestrian search engine. Why would anyone hire us? Tiny company, limited experience. But I grew up around horses. Knew the industry inside-out. Sometimes your weirdest background becomes your biggest advantage.

I was obsessed with privacy: everything had to be stored offline. Attempted building a local server, but setups linking browser extensions to it was prohibitively complex for users. Months of development making it work... then I made a 180-degree pivot. Rebuilt everything cloud-hosted.

But my vision was always bigger than just search: extract the information locked inside documents and make it available exactly when you need it. We rebuilt everything from the ground up and renamed it Webscape. Integrated OpenAI so people could ask questions about their documents instead of just searching through them.

Then Russia-Ukraine war erupted. My entire team was suddenly in a warzone. Investors got spooked. The AI frenzy hadn't kicked in yet. It took several months to become apparent but our company had died that day.

I moved to Portugal and randomly ran into someone I'd met years before in Kyiv. He'd built a company that connected hotels to Airbnb - growing fast but needed technical leadership to scale. Joined as CIO, became CEO.

Seedcamp’s investment announcement introduces Doczen, co-founders Daniel Volkenstein and Martijn Verbove, and the operational problems the company set out to solve in physical commodities. It describes the opportunity to connect knowledge and workflows across operations, compliance, legal, and finance. Read the original announcement for Seedcamp’s perspective on the team and investment.

Sarah Wright interviews Martijn about what the team learned from History Search users and how those discoveries shaped Webscape. The story follows the move from retrieving pages to navigating an entire workspace. It also covers the impact of the war in Ukraine on the team and the work of continuing to build through disruption.

Product Hunt’s official winners announcement lists History Search as Lifehack Product of the Year in the 2018 Golden Kitty Awards. The date shown here refers to the award year; this newsletter announced the results the following year.

I wrote this guide after launching History Search on Product Hunt. It walks through deciding when to launch, finding a clear story, preparing the listing, approaching journalists, and following up afterward. The focus is the lasting value of a launch: reaching people who need the product and turning early attention into a business.

This Entrepreneur Store product spotlight, published by News-Times, introduces History Search’s page-retrieval features. It is a commerce article rather than an independent product review.

Stephen Shankland covered History Search for CNET. This is the coverage I refer to in my Product Hunt launch guide, where I discuss sharing the product’s story with journalists. Read the original article on CNET.

A profile of Martijn and History Search in EW / Elsevier Weekblad’s ‘De mens achter’ series. The original article is in Dutch.

Meindert Schut interviews Martijn about the origins of History Search, the technical work behind it, and the business model. The article explores the idea of making someone’s own browsing history searchable by the information they remember. The original article is in Dutch.

Jordan Gonen includes History Search in a selection of ten upcoming Product Hunt pages, introducing its approach to searching bookmarks and previously visited pages.

I share what I am building and learning on X / Twitter. Explore the imported posts here or visit my profile for the latest.

My professional profile, with the work and experiences behind these projects.