I build the systems that make marketing and sales work as one.
For founders and the people in charge of revenue who want more out of the business they already have.
Why subscribe.
- Cheat sheets built from real engagements. Not templates. Every one is a system that was actually broken, drawn while the work was still open.
- A new framework every Sunday. High-quality systems on a schedule, not whenever something occurs to me.
- The build on screen. Screenshots of the real configuration, taken inside the system rather than drawn afterwards.
The Sunday Teardown
Business systems, taken apart. Every Sunday.Join the people who get the whole build.
Free, no upsell, and it stays yours if you leave.
Built and taken apart in the systems I work in.
Who is this for?
-
Founders who want to scale profitably
-
Founders unhappy with how sales runs
-
Reps who know they can close more
-
Whoever owns the CRM and the automations
About me.
I help companies with revenue operations and go-to-market execution. In plain terms: getting customers in the door at a cost that works, and converting more of the ones already in front of you.
Most of the companies I work with sit somewhere between seven and eight figures, and what looks like a sales problem is almost always a structure problem. I built Salestruct on that, and I built it alone, down to the internal system it runs on. One structure, fully in sync, and the same kind I put into client companies.
Before you go looking for something new to add, get more out of what you already own. It is cheaper, it is easier, and it is where anyone scaling should start.
I am from the Dalmatian coast and I live in Zagreb with my wife. I snowboard in the Alps in winter and travel the rest of the year, I train most days, and I have rewatched The Office more times than I will defend. That is genuinely all you need to know about me.
I help B2B companies scale by fixing the systems the business runs on.
Five areas. What I find inside them is what the newsletter is made of.
- Outbound operations
- Choosing who to contact, building the list, and running the sequences that reach them.
- Sales management
- Pipeline stages, who picks a deal up at each one, and the reporting a manager uses to forecast.
- Internal systems
- The CRM itself, the automations wired into it, and the AI steps that run inside those.
- Software implementation
- Setting up the tools a company already pays for so they do the job they were bought to do.
- Project management
- Sequencing the work, deciding who owns each part, and getting it delivered.
Some of the systems I use to scale companies.
n8n
Make
Zapier
HubSpot
Salesforce
Pipedrive
GoHighLevel
Odoo
Zoho
ClickUp
Notion
Airtable
Linear
monday.com
OpenRouter
Claude
OpenAI
Perplexity
Antigravity
OpenClaw
HeyReach
Smartlead
Instantly
lemlist
Slack
Telegram
WhatsApp
Discord
Gmail
Google Sheets
Google Drive
Google Calendar
Analytics
GitHub
Figma
Canva
Stripe
Shopify
WordPress
Calendly
Zoom
Mailchimp
LinkedIn- …and the rest of the stack
FAQ
Grouped, so you can open the one you came for. Several of these get a full teardown in the newsletter.
RevOps and automation
What the term actually means, how the tools bill, and why the
numbers in the CRM stop being believed.
What is RevOps?
RevOps is one operating model across marketing, sales and customer success, instead of three departments each keeping their own data, tools and definitions. It is not a software category and not a job title. The quickest test of whether a business has it: ask two teams what a qualified lead is and see whether the answers match.
What is the difference between RevOps and sales ops?
Sales ops asks how the sales team closes more deals. RevOps asks where revenue leaks across the whole journey, from first touch to renewal, which usually puts the answer outside sales. The expensive version of this question is renaming sales ops to RevOps and changing nothing underneath, which leaves every handoff exactly where it was.
Why does nobody trust the numbers in the CRM?
Because the CRM holds what people remembered to type, and the forecast is built on the gaps. The cause is usually not discipline. It is pipeline stages that describe internal activity rather than buyer behaviour, so two people reading the same deal disagree on where it sits. Define the stages first and data quality follows.
What should a business automate first?
The step done by hand most often that has one obviously correct outcome. Frequency gives you the payback, and a single correct outcome makes it safe to run unattended. Steps that need judgement go last, after the judgement itself has been written down. Programmes stall when they open with the most interesting process instead of the most repeated one.
Which workflow automation tool should a business use: n8n, Make or Zapier?
Compare how each one bills before comparing what each one does. Zapier counts a task for every action a Zap completes successfully, Make charges a credit per module action, and n8n bills one execution per workflow run regardless of how many steps are inside it. The same 20-step process is roughly 20 billable units on two of them and 1 on the third. Model it at 5 times today’s volume before you pick.
Who should own an automation after it is built?
One named person inside the business, holding documentation good enough to change it. An unowned automation degrades quietly: an API version moves, a field gets renamed, and the workflow keeps reporting success while doing nothing useful. Ownership is the difference between infrastructure a company holds and an arrangement with whoever built it.
AI agents and AI workflows
Where an AI step belongs, how an agent differs from a workflow,
and why these projects stall.
What is the difference between an AI workflow and an AI agent?
A workflow runs a path someone decided in advance and calls a model at fixed points inside it. An agent decides the path itself, choosing which tools to call and in what order. That trades predictability for flexibility, and most business processes want predictability. An agent earns its place when the path genuinely cannot be written down ahead of time.
Where does AI actually belong in a business process?
On the steps that read, draft, classify or route, each with a defined input, a defined output, and a person reviewing where the cost of being wrong is real. Point it at an undefined process and it returns confident output nobody can check. Decide the scope of the AI step before deciding the model. The model is the easy half.
How do you stop an AI step from shipping something nobody checks?
Constrain the output shape, then validate it before it moves on. A step that returns free text can only be checked by a person reading it. A step that returns a fixed set of fields can be tested against rules the business already has, and anything failing that test gets routed to a human instead of onward. The risk is not a wrong answer. It is a wrong answer that looks finished.
Why do most AI automation projects fail?
Because the process underneath was never stable. Automation copies whatever it is given, so an unclear workflow comes back as a faster unclear workflow. The other repeat cause is silent failure: the automation stops, nothing alerts anyone, and the business finds out from a customer. Both are process faults, and neither is fixed by switching platform.
About me and the newsletter
What I work on, which countries it came from, and what arrives on
a Sunday.
What do you actually work on?
The machinery underneath revenue. CRM structure and the rules that keep it honest, the routing between marketing and sales, the automations carrying work between systems, and the AI steps sitting inside them. Underneath all of that, the process layer: the SOPs, the project structure and the team setup that decide whether any of it survives once I stop looking at it.
What kind of business is this written for?
B2B companies where the revenue problem turns out to be an organisation problem. Usually founder-led, past the point where sales can run on memory, with a CRM nobody enforces and work moving between systems by hand.
What is The Sunday Teardown?
One business system taken apart in writing, every Sunday. What it was built to do, where it actually broke, and the structure that held afterwards. Some issues are a diagram of a stack that works, some are the argument for why one does not. The full version goes out with the workflow file behind it.
Do you write about tools or about systems?
Systems, with the tools named. A stack is a decision about how work moves, and the tool is the last part of that decision rather than the first. Naming it still matters, because the economics differ enough to change the design. What does not change is the fault underneath: it survives a migration intact if the process was never fixed.