I talked about part of this journey in Sextas Ímpares #147, a long conversation about seven years of entrepreneurship, with questions generated by AI and answers as direct as I could make them. I spoke about revenue, margin, team decisions, and the role AI has gradually taken on in how we work. Here are the lessons that still guide me.
Look at margin when you think about growth
It's easy to focus a conversation on sales volume, because it's a visible number that allows quick comparisons. But what really matters is what's left after you pay for everything needed to deliver what you sell, and that distinction isn't always comfortable to make.
In the episode, I explained that there were years when the priority wasn't profit but growth and market share. At one point we had a year where we practically took no profit out of the company, because all the energy went into growing and improving processes. That wasn't a mistake; it was a conscious choice for that phase.
Later, as AI started improving our internal processes, we managed to increase our working capacity without growing the team in the same proportion. That had a direct effect on margin, because the same work started costing less in hours and in people. This isn't a rule that applies to every online business, but it's a concrete example of what can happen when you review your operation with that goal in mind.
It's not enough to add up sales at the end of the month. Track time spent per project, the real costs of the tools you use, and the work that needs to be redone because it wasn't done right the first time. If a task eats up several hours every week, it's worth asking whether there's a process improvement to make there before you rush off to sell more.
Take the founder out of decisions that don't need them
When a company is small, the founder ends up involved in almost everything, and that's normal at that stage. The problem shows up when that way of working remains the only option even after the business has already grown, and one person's schedule ends up limiting the speed of the entire team.
I mentioned that, at one point in the services business, I took as long as seven days to respond to a lead, because I was the one handling the entire sales side and there was no room in my schedule. That cost us business, no doubt. Today the internal standard is much higher, but that's not a promise of a fast response to any request that comes in from outside; it's a reference to what changed within the operation.
A sales team needs to know who to contact, what information to gather, and at what point it makes sense to bring someone else in. If every step depends on the founder's approval, the speed of the business will always be limited by that person's availability, no matter how much goodwill exists.
A simple exercise is to look at the decisions that repeat every week and ask how many of them really need to reach you. Explain the criteria to the team, clearly define the exceptions that should be escalated to you, and let the rest run on its own. AI can help prepare summaries and organize information for those decisions, but who gets to hold responsibility remains a management choice, not something a tool decides.
Part of that organisation involves assigning responsibilities for sales follow-up.
Protect your team in client relationships
I also talked about the choice between keeping a misaligned client and protecting someone on the team. My position today is clear: I'd rather lose a client than lose a team member by letting them stay in a working relationship that wears them down or makes them unhappy.
In the early days of the agency we swallowed a lot of frogs, knowing the client wasn't aligned with our values or that they disrespected the team's work. That happened because, at that stage, we had no room to say no; losing a client could mean not being able to pay salaries the following month. With a bigger business and more active clients now, there's room today to make different decisions without putting everything at risk.
This requires clear criteria: what behavior you'll accept, how you handle a disagreement, what was actually contracted for. Not every conflict means the relationship should end, but constantly postponing hard conversations also has a cost, one that's often paid by the team rather than by the founder.
Anyone starting an online business feels more pressure to accept any project that comes along, and I recognize that pressure well because I've been there. The difference is that, with growth, I started giving more weight to the kind of work and relationships I want to keep inside the company, even if that means turning down money that would come in easily.
Give yourself time to apply what you learn
I often see people piling up courses and mentorships but leaving little room to apply what they've learned, because the next tool or the next course always seems more interesting than finishing the previous implementation. This isn't exclusive to people just starting out; I've seen it in experienced professionals too.
In the episode, I reflected on my own investment in events, masterminds, and mentorships over the years, including phases where we spent significant amounts on that kind of participation. Part of that investment brought useful relationships and lessons; another part served vanity more than it served results in the business. The value of any investment in learning always depends on what you do with it afterward, and that's something you only really understand with some distance.
If you're learning an AI tool for your online business, pick a concrete problem and work on it until you can evaluate the result with complete data, not just the feeling that "it went well." Record what improved, what failed, and what still depends on you despite the tool. That experience gives you the judgment to choose the next course or solution, instead of jumping into the next one just because it looks promising.
Review the service you deliver
Reviewing the service you deliver means regularly questioning how AI can change an agency's work rather than assuming the current model will last forever. I do this to understand where we still create real value, what we need to learn, and avoid repeating services the market no longer values equally.
Sharing knowledge publicly also had an effect inside the team. The commitment to teach others how to work with AI forced us to study more deeply and test tools before recommending them, and that had a direct impact on the quality of what we deliver to clients.
Today I try to connect that learning work to the day-to-day operation: improving processes, responding better to leads, and finding concrete applications of AI and automation that make sense for the size and moment of each business. Growth makes more sense when the company gains real capacity to keep up with it, instead of just piling on more volume over an already stretched operation.
If you want to work on the acquisition, sales, and processes of your online business, check out our services for online businesses and figure out where it's worth starting.
How to compare revenue, margin, and capacity using a hypothetical services example
Comparing revenue, margin, and capacity means looking at three numbers at once: how much comes in, how much is left after paying delivery costs, and how many projects the team can handle without burning anyone out. Without this combined view, growth can hide real problems.
Imagine a hypothetical agency billing 30,000 euros in a month across ten projects. On its own, that number looks good. But if each project requires fifteen hours of work from a small team, and tool and subcontracting costs eat up 40% of that revenue, the real margin is much thinner than the billing figure suggests.
The first step is to separate gross revenue from direct delivery costs. In this hypothetical example, that means adding up work hours, software licenses, and any outsourced work paid per project. Only after that calculation can you tell whether it's worth taking on two more similar projects next month.
The second step is to look at available capacity. If the team is already working near its limit, taking on more volume without changing processes tends to lower quality or increase response time. In this hypothetical example, if each person can sustainably handle three projects a month, ten projects with four people is already close to a reasonable ceiling.
A simple criterion for deciding whether growth is worth it is comparing the marginal margin of the next project against the cost of expanding the team. If taking on one more project means hiring someone, work out how long it takes for that new hire to become productive and how much that weighs on margin in the following months. Growing without doing this math usually just piles pressure onto the people already on the team.
Another thing to check is time spent on repeated tasks. In the hypothetical example, if three of the fifteen hours per project go into preparing manual reports or answering similar client questions, that's a sign it's worth improving the process rather than chasing more volume. A more efficient process increases margin without requiring more people.
It's also useful to compare projects against each other. If two of the ten hypothetical projects consume half the team's total time and represent only 20% of revenue, it's worth asking whether that type of work is worth continuing to accept. Not all revenue carries the same value once you factor in the time and wear it demands.
A practical way to organize this analysis is to keep a simple log per project: hours spent, direct costs, revenue, and a note on recurring problems. It doesn't need to be complex. The goal is having enough data to compare projects and decide where to invest improvement effort before chasing more clients.
When the numbers show tight margins and maxed-out capacity, the priority shouldn't be selling more. It should be reviewing processes, cutting repeated tasks, and only then thinking about growth again. This kind of discipline stops revenue growth from turning into more work without a proportional return.
How to remove repeated decisions from the founder's agenda without abandoning the team
Start with the decisions that repeat themselves and explain to the team the criteria you use. Also agree on which situations should be escalated to you. That way you can keep track of the work without approving every step, and the team knows how far it can go on its own.
The first step is looking back and listing the decisions you made over the past few weeks. You don't need a complicated system, just a notebook or a sheet where you write down: what question they asked you, what answer you gave, and whether that answer could have been given by someone else with the right information. After doing this for two or three weeks, a clear pattern starts to emerge.
Imagine, hypothetically, that at a marketing agency the founder is always consulted before accepting a shorter delivery deadline requested by a client. If this happens once a month, it might be worth handling case by case. If it happens three times a week, that's a sign there's a rule to define, not a decision to repeat.
Once you've identified the pattern, the next step is to write the criterion in simple language. You don't need an extensive manual, sometimes two or three sentences are enough to say what can be accepted without consultation, what needs a heads-up, and what really requires your final word. In the hypothetical example above, the criterion could be something like: deadline reductions of up to two days can be accepted if there's no impact on other projects; bigger reductions need confirmation.
Once written, the criterion has to be tested with the team, not just explained. Set up a short conversation where you present two or three real past situations and ask how the team would have decided, following the new criterion. This shows you whether the rule is clear or still has gray areas that will cause doubts later.
A common mistake is defining the criterion and never revisiting it. Criteria need review, especially in the first few months, because new situations will come up that the original criterion didn't anticipate. Set aside a fixed moment, for example once a month, to review with the team what worked and what had to escalate to you unnecessarily.
Some decisions still need you: an important price change, a commitment made to a client, or a situation nobody had anticipated. Separate those decisions from tasks that repeat themselves. It's worth reviewing the division with the team after trying it out in daily work.
AI tools can help at this stage, especially summarizing recurring requests or flagging when a situation is close to an already-known pattern. But the decision of which criterion to apply and where to draw the line remains yours, as manager, not something to delegate to the tool.
In the end, the real test is simple: if you go three days without answering messages, can the team keep handling recurring commercial requests without getting stuck waiting for you? If the answer is yes, you removed yourself from the right decisions. If it's no, there's still work to do before thinking about growing further.
How to spot that a client relationship is wearing out the team
Pay attention when the team starts avoiding meetings with a client or repeatedly reports difficulties on that account. Ask what's going on and look for concrete examples. These signs justify a conversation; on their own, they don't explain the cause or dictate what the decision should be.
Imagine an agency with a client who changes priorities every week and asks for responses outside the agreed hours. The person responsible starts falling behind on other accounts. Before drawing conclusions, review the workload, the requests received and the boundaries agreed with the client.
Before deciding anything, gather concrete facts. How many times has the scope changed without warning? How many out-of-hours messages were sent last month? How much extra time has the team spent on this account compared to similar ones? Without these numbers, any conversation about ending or renegotiating stays dependent on feelings, and feelings are easy to dismiss when there's revenue at stake.
Set criteria before you act, not after
A clear criterion stops you making decisions in the middle of a crisis, when emotional pressure distorts judgment. You need to know, ahead of time, what kind of behaviour is unacceptable and what kind of friction is just a normal part of working with different people.
For example, you might decide that scope changes without renegotiating deadline or price are a hard limit, while disagreements over creative direction or priorities are part of the normal process. This distinction stops every disagreement feeling like an emergency threatening the whole relationship.
A useful question to ask: is this happening with this client alone, or is it a pattern that repeats across several? If it's isolated, the problem might be in account management or in how expectations were set at the start. If it's a pattern, the problem might be in the type of client the company is accepting, and that calls for reviewing entry criteria, not just exit ones.
How to have the conversation without turning everything into a breakup
Before deciding to end the relationship, it's worth trying a direct conversation about what's happening, with concrete examples and no generic accusations. In a hypothetical situation, this might mean showing the client the out-of-scope requests logged over a defined period and proposing a new working framework.
If the client recognises the problem and agrees to adjust expectations, you've bought time to reassess without immediate costs. If the response is to deny the pattern or downplay the impact on the team, you've gained valuable information about what to expect going forward.
Not every difficult conversation needs to end in a breakup. But if the same conversation has already happened before, more than once, without any change in behaviour, repeating the warning only postpones the wear and tear.
Decide based on the real cost, not the fear of losing revenue
The final decision should compare the cost of keeping the client against the cost of losing the person absorbing that wear and tear. Replacing a client is almost always faster and cheaper than replacing an experienced team member who decides to leave from burnout.
Do the math, even roughly. How much time for recruiting, training and adapting would it take to replace the person under pressure? Compare that with how long it would take to replace that client's revenue with other work, even at a slower pace.
If you decide to end the relationship, explain the decision to the client and agree on how the work handover will be done. Keep the conversation professional and protect both parties' information. The team needs to know how to act next, without turning the disagreement into a public dispute.
This kind of decision connects directly to the work of organising processes and responsibilities within the team, a topic that involves reviewing operations with the support of AI and automation and structuring better how the company accepts and follows projects, within the broader work of online business and sales.
How to choose a process improvement and track it over a few weeks
Choose a process improvement based on its impact on time or quality of work, not on how new the tool is. Once chosen, set a short trial period with simple goals and an evaluation point marked on the calendar, so you know whether to keep it, adjust it, or drop it.
The first step is to write down a list of tasks that repeat every week and roughly how much time they take. You don't need a complex system, a simple document is enough. The goal is to see clearly where the waste is, because it's easy to feel busy without knowing exactly with what.
Imagine, hypothetically, that a small team spends about six hours a week preparing summaries of client meetings. On its own that number might seem small, but multiplied over several weeks it represents whole days of work. If there's a way to cut those six hours down to two, even if the solution requires adjustments at the start, the accumulated gain justifies the time spent testing it.
Once the task is defined, the next step is to choose a success criterion before you start. It can be time saved, number of errors avoided, or speed of response to the client. What matters is picking a criterion you can measure without much effort, because if the measurement itself is complicated, you'll end up abandoning the tracking halfway through.
Once the criterion is chosen, set aside two or three weeks for the trial. It's deliberately a short period, because you want to know quickly whether the change works before rolling it out to the whole team. During those weeks, note what worked, what needed corrections, and what still depended on manual session.
At the end of the period, hold a short review, even if it's just with yourself, to go over the numbers you collected. If the result is clearly positive, decide how to formalize the change: document the process, train whoever will use it, and define who's responsible for keeping it up to date. If the result is unclear, it's better to extend the trial by another two weeks than to decide in a hurry.
There are cases where the improvement fails for reasons that have nothing to do with the tool chosen. It might be the team lacking time to learn the new way of working, or resistance because the old process, even if slow, was familiar. In those cases, the problem isn't the technology, it's how the change was introduced, and it's worth going back and explaining better why the change is needed before trying again.
A simple rule that helps decide whether it's worth continuing to test an improvement is to compare the time spent implementing it against the time it has already saved. If after a month the balance is still negative, with no signs of improvement, that's a sign to stop and look for another approach. If the balance is positive, even a small one, it usually grows over time, because the team gains confidence and speed using the new way of working.
This kind of simple tracking, without big management systems, is what lets you tell whether a process improvement, including the use of AI and automation, is actually helping the operation or just creating one more layer of work with no clear return.