How we started

Makkro was built by people who were losing good projects for bad reasons.

This page is long on purpose. If you're evaluating Makkro, what matters isn't the feature list — it's where each feature came from and which problem it solved before it became a screen. Nothing here was designed in a workshop. Everything showed up because it hurt first.

2019

An agency good at delivering, bad at showing it.

Makkro started inside Razzo, a software agency that opened its doors the way most do: people who know how to build, solving client problems. The technical side was never the bottleneck.

The problem was everything happening around the delivery. The brief died in the kickoff PDF. The rule agreed on a call became oral folklore — three people remembered three versions, and the divergence only surfaced at sign-off, when it was already expensive.

Project status lived in four places at once, none of them current. And the client, with no information, did the only thing left to do: chase.

We tried what everyone tries.

Before building anything, we took the obvious path: an off-the-shelf tool, a shared board, the client invited in. The promise was good — total transparency, everyone in the same place.

The result was the opposite of the plan. With access to the team's board, the client started acting like part of the team. Talking straight to the developer. Re-prioritizing tasks in comments. Asking for “just a tiny tweak” from someone with no authority to say no. The plan built on Monday didn't survive to Thursday.

So we swung to the other extreme: closed board, weekly report written by hand. Back to square one, now with extra work.

The problem wasn't how much the client saw. It was where they were.

The diagnosis: three roles, not three permission levels.

None of the tools we used treated following and executing as structurally distinct things. They all treated them as permission layers over the same board. A subtle difference on paper, an enormous one in practice.

Stakeholder

Needs to know what was delivered, what comes next and where to ask for a change. Doesn't need to see the internal queue or debate implementation with whoever implements it.

Member

Needs to know what to do today, with enough context to do it well. Shouldn't be receiving work through three different channels.

Manager

Needs to be the crossing point between the two — not out of bureaucracy, but because they're the only one who sees capacity, deadline and contract at the same time.

Before the software came the method.

We didn't start by writing code. We started by defining how every project would run from then on, no exceptions. Six rules — the ones you now recognize as the platform's modules.

Every project has a living brief.Today it's the Overview module.
Every business rule is documented as a tree.Today it's the Topics module.
Every demand comes in through a single channel.Today it's the Requests module.
Every deliverable is recorded, and each one has an audience.Today it's the Deliverables module, with the internal/external split.
Every project is reviewed on a cycle.Today it's Continuous review.
All planning happens in one place.Today it's Planning, with a unified backlog.

Those were uncomfortable weeks. A new method is always slower before it's faster.

The method worked. The tools were what couldn't keep up.

The six rules ran for months on top of whatever existed: a task board for one part, a document for another, a spreadsheet for the third, a manual report to close the month. It worked — but the cost of keeping everything in sync was high, and the method only survived while somebody kept pushing.

Makkro was born to take the pushing out of the equation.

Planning with a unified backlog first, because it was the most expensive pain. Then deliverables with the internal/external split. Then tree documentation, requests, the client portal, the monitor, continuous review, automations.

Each module arrived in the order the pain did. That's why there's nothing spare in the platform: we never built a screen to fill space on a pricing page.

What changed, measured.

+35%delivery capacityPeriod and baseline

−90%reworkPeriod and baseline

−20%cost per deliverableTime tracking

+50 ptsclient NPSResponse sample

Delivery capacity

Same team, more projects moving in the same period. Most of the gain didn't come from people working faster — it came from people no longer working on the wrong thing, waiting for answers and redoing alignment.

Rework

The number that surprised us most and the easiest to explain: when the rule is documented at the right level and sign-off happens against the document, it doesn't come back different. Almost all rework came from a mismatch in understanding, not from technical error.

Cost per deliverable

Measured through time tracking: how many team hours an equivalent deliverable consumed before and after. Less rework, fewer alignment meetings, fewer reports assembled by hand.

Client NPS

The client stopped needing to ask. That changes the relationship in a way no status meeting can — perception stopped depending on the last conversation and started depending on the visible history.

The effect nobody had predicted.

The expectation was to improve the relationship with clients. What wasn't in the plan was how much would change in-house.

With deliverables recorded and reviews on a cycle, the conversation about performance stopped being impressions. It's no longer “I think this project is heavy” — it's the history on screen. The team started seeing its own pace, and load started being distributed by looking at data instead of at whoever complained last.

Today the deliverables and reviews recorded on the platform are the basis for performance evaluation in the operation that uses it. There is no parallel spreadsheet.

Why it became a separate company

The description of the problem repeated itself in every conversation with another agency owner: we deliver well, but we spend half our time proving we delivered — and when we give the client access, we lose control of execution.

That's structural to the agency model, not anyone's particular quirk. And a tool that solves a problem for an entire market couldn't stay the internal department of a single agency.

Makkro became its own company, with its own team and roadmap, because whoever uses it needs to know the product answers to them — not to someone else's portfolio.

Three decisions that aren't up for negotiation.

Stakeholders don't pay

Transparency can't carry a marginal cost. If inviting one more person from the client costs money, the agency invites fewer people — and the problem comes back through the side door.

Stakeholders don't enter execution

It isn't a configurable permission. They're distinct environments, by architecture. It's the only way to guarantee the manager's plan survives the week.

Automation with no black box

Every automatic run is recorded: what fired it, when, which rule, what changed. A tool that does things you can't audit isn't a management tool.

The tool built so you stop losing projects for silly reasons.

15 days with everything unlocked. Set up a real project, invite a real client — they pay nothing — and see whether the effect repeats in your operation.

Start my 15 days

No card. No onboarding project. Nothing locked.