In Sextas Ímpares #134, I talked about the situation of someone starting a project with few resources, no clients and little money to invest. The core idea is to build a small operation that lets you talk to potential clients and learn from those conversations, without depending on a team.
Prepare an offer you can actually explain
Write, in a few lines, who the service is for, the problem you solve and what you deliver in return. If you still have doubts about how to phrase it, you can use AI to organize the questions and compare different ways of presenting the same idea.
After that, step out of the conversation with the tool and go look for answers outside it. Talk to people from the audience you want to serve and listen to the doubts they actually have, not the ones you imagined. A well-written description, no matter how polished, doesn't prove there's demand for what you're offering.
In the lecture, the example I used was hypothetical: someone who already has a defined skill, for example traffic management or social media management, but doesn't yet have clients or money to invest carelessly. In that scenario, a simple page helps present the offer and collect contacts. What matters is confirming the information is correct, the form works, and you know what to do the moment a request comes in, because that's often the part people forget.
Pick a task that keeps repeating
Choose a task that already repeats in your work and that you know well enough to judge whether the AI-generated result is correct. It could be preparing a first draft of a proposal, organizing meeting notes, or adapting one of your own texts into a different format.
In the lecture, I talked about assistants set up with context and methodology, the idea of giving the tool information about your work, concrete examples, and clear limits. This is different from simply asking for a text from scratch: the tool needs to know how you write, how you see your own business, and where the limits are on what it can say on your behalf. It shouldn't, for instance, invent commercial terms or deadlines you never discussed, just to complete a response that sounds coherent.
Use your own materials as a starting point and always review the first result carefully. When you find a mistake, try to figure out whether context was missing or whether the instruction you gave was ambiguous, because the fix is different in each case. It's worth keeping a record of these corrections, because they often prevent the same mistake from repeating the next time you run the same task.
If you are building an application, define its rules and permissions in the plan first.
To test demand, develop an offer explaining why someone would choose your service.
Organize your sales conversations
I dedicated part of the session to tracking sales conversations, because in a service business these conversations are what tell you whether the offer makes sense. Without that tracking, it's easy to lose sight of where the real difficulties are: attracting leads, the conversation itself, or the proposal.
Record the source of each request, the state of the conversation, and the expected next step. A simple spreadsheet can work perfectly well at the start, as long as access is set up properly and the information is kept up to date, because an abandoned spreadsheet is useless.
A scheduled meeting is not yet a sale, and it's important not to confuse the two. Track what happened afterward: did the meeting take place, was there a proposal, was there a decision? Also record why some opportunities didn't move forward, because that usually tells you more about the offer than any analysis done in a hurry.
Automate only after you understand the journey
When a step already repeats with some stability, and only then, consider automating it. It could be an internal reminder, organizing an incoming request, or preparing a summary, but you should have already done that task manually several times before handing it over to a tool.
Always keep a way to check for failures. If an integration stops working, you need to know where the work got stuck and how to pick it back up without losing what was already done, because automation can also fail silently.
Start with few tools and one concrete use for each, rather than trying to set everything up at once. As demand and the operation evolve, you'll have better judgment to decide what's worth adding and what's just unnecessary complexity.
If you want to go deeper into applying automation and AI to the daily running of a digital business, check out my training and mentoring in AI and online business.
How to prepare a conversation to validate demand without using AI as proof
Validating demand means talking to real people before assuming your offer works. AI can help prepare questions and organise answers, but it doesn't replace the conversation. Prepare a short script, choose who to contact, and treat each conversation as a source of information, not confirmation.
Define what you want to understand before scheduling the conversation. Ask how the person deals with that difficulty today, what they've already tried, and what would make them look for another solution. Leave room to hear answers that contradict your idea; those are the ones that help you understand what needs to change.
Write three to five open questions about the problem, not the solution. For example, imagine you're testing a financial organisation service for small businesses. Instead of asking "would you pay for something like this," ask "how do you currently handle keeping track of your accounts" and "what's missing from that process." The answers tell you far more than a polite yes.
Use AI only during preparation, to check whether the questions are clear and not leading. You can ask it to flag questions that already contain the answer you want, a common mistake when writing in a hurry. What AI can't do is tell you whether the person on the other end will actually pay for the service.
Schedule conversations with people outside your direct circle, ideally people who don't know you and have no reason to be polite out of courtesy. This is a hypothetical example step: if you contact ten people from the audience you defined and manage to schedule three conversations, you already have material to spot patterns. Fewer than that still doesn't give you a solid basis to decide anything.
During the conversation, record exact phrases, not optimistic summaries. If the person says "that would be useful" without committing to anything concrete, mark that as weak interest. If they ask about price, timeline, or how to get started, that's a stronger signal. The difference between curiosity and real demand lies in these details.
After each conversation, write down in a simple document what you heard, without over-interpreting in the moment. Only after you have four or five conversations recorded is it worth looking for patterns. A single case can be an exception, several similar cases are already a signal.
Avoid showing an AI-made prototype as if it were proof of validation. A well-written description or a nice mockup don't confirm that someone will pay. What confirms it is the person committing to some concrete step, like scheduling a second conversation, agreeing to test something real, or discussing payment terms.
If after several conversations you still see no clear signs of demand, that's valuable information too. Maybe the problem isn't as urgent for the audience you chose, or maybe the way you're describing it isn't yet aligned with people's language. This conversation process ties into what I describe about organising sales conversations, where recording what happens after the first meeting matters just as much.
How to organise your first week of work with an offer and few tools
The first week should be about testing the offer with real people, not about setting up perfect tools. Split it into three blocks: writing the offer, contacting potential clients and recording what you learn. Everything else can wait until you've had enough conversations to know what actually needs to exist.
Start day one by writing the offer on a short page, without worrying about how it looks. A hypothetical example: someone wants to offer support organising the finances of small businesses. In that case they'd write down who the client is, what problem it solves in the first few weeks, and what gets delivered by the end of a month. It doesn't need to be final, it needs to be clear enough to be tested in a conversation.
On day two, identify ten to fifteen people or businesses who might fit the profile you described. You don't need a sophisticated list, a simple document with name, contact and reason you thought of that person is enough. The goal is to have concrete contacts before you start thinking about ads or automation.
On the third and fourth day, book the first conversations. In those conversations, listen more than you talk. Ask how they currently solve the problem your offer aims to solve, and what would make them trust a new service. Write down the exact words they use, because they often help improve how you describe the offer.
At the end of each conversation, record three things: what the person said about the problem, whether they showed real interest, and what next step you agreed on. This record can be a simple sheet, one line per contact. Without this discipline, it's easy to lose track when five or six conversations happen in the same week.
On day five, review what you've gathered. If most people didn't recognise the problem as a priority, the offer may need adjusting before you move on to any tool or automation. If, on the other hand, there was consistent interest, start thinking about what needs to exist to respond to the first real request.
Only after this first round of conversations does it make sense to decide whether it's worth using AI to prepare proposals, meeting summaries or answers to frequent questions. Using the tool before you have clarity about the offer risks producing well-written materials about something you still don't know has demand.
A good way to decide where to invest time is to look at what repeats every day during that week. If every conversation requires explaining the same point, it might be worth preparing a support document. If every request is different, that's a sign you're still in discovery phase, not standardisation.
At the end of the week, count the conversations you had, organize the objections, and revise the offer based on what you heard. Also keep the questions you still can't answer. These are the ones that will guide the following week and help you choose your next test.