Building AI Mastery Hub with Leo

One project was getting the AI Mastery Hub website focused on a service someone could understand and buy. The homepage now leads with a $500 One-Workflow Review. It also gives people a way to ask about a Business Assistant Setup Pilot.

The work included the offer, the wording, and the actual website changes. We used a fictional real-estate example to make the review more concrete. That matters: an example can help explain a service, but it shouldn’t read like a result from a client who doesn’t exist.

The revised website was published and checked on desktop and mobile. That gave us a clearer place to send people. It didn’t answer whether the offer would sell. We still have to earn that evidence through real conversations and, eventually, real customer results.

We also worked on an Android voice widget inspired by Inkwell. The idea was straightforward: make it easier to dictate and insert text without a cumbersome interaction every time.

The first direction didn’t fit the way I wanted to use it. We moved through feedback on the floating control, its size and placement, and the stop and insert behavior. We eventually arrived at a smaller edge-tab design. Version six was the one I tested on my phone and accepted as working.

That’s a good example of the work involved. A technically plausible approach still has to fit the person using it. I could look at the phone, explain what was getting in the way, and have the next version address that specific problem.

It’s a local Android tool that worked in my test. Broader device compatibility is a separate question. If I show it in this series, the useful demonstration will be the interaction before and after the changes.

The avatar work went through its own review cycle in HeyGen. We looked at the shirt, lighting, background, framing, hands, and blinking. Small visual problems become very noticeable when the presenter is supposed to represent you.

We tried changes, reviewed the output, and kept working toward a usable result. The approach was practical: give it a fair test, and keep a plan B if it didn’t work.

We got a successful Avatar III test, then produced a branded 43-second video about working with my dot. That video is scheduled across five social channels for October 3.

There are separate checkpoints here. An accepted short avatar test, a finished branded video, and a scheduled post each establish something different. Publication still needs to be checked when the scheduled time arrives. Audience response comes after that.

On October 2, we sent three individual branded outreach emails from Leo through GoHighLevel. The outreach was tied to the service offer and kept organized with source and batch tags.

We also configured two follow-ups, for October 8 and October 15, and enrolled the three contacts. The workflow includes stop conditions intended to prevent inappropriate follow-ups. Those conditions have been configured, but we haven’t yet verified them through live events. That remains a test to complete.

That level of detail belongs in the story. Sending an email is one step. Knowing what follows it, what should stop it, and what has actually been tested is part of running the process responsibly.

Three emails sent is the result we can report. It doesn’t establish that someone read them, wants the service, or will become a customer. There are no client wins or revenue claims to attach to this work yet.

The website form showed why checking the visible page is only part of the job. A controlled Gmail test passed, but the investigation also showed that the existing inquiry path was email-only. It wasn’t the native GoHighLevel form connection we wanted.

We deployed a native GoHighLevel form. Bot protection blocked the next test attempt. The new route is deployed, but its end-to-end acceptance test is still pending.

So the accurate status today is specific: the earlier email route passed its test, the native form is deployed, and the new route still needs its full test. I can’t combine those into a claim that the entire new inquiry workflow has been verified.

This is one of the details I’d want someone to show me in a practical series. When a website says the right thing, you still need to check where the inquiry goes and whether the intended system receives it. A good-looking page can leave that question unanswered.

We’ve also built a daily work log in my business OS. It records the goal, what we did, the result, and the limits of what we know. That makes it easier to revisit a project and see what still needs attention.

The log doesn’t turn every action into hours or dollars saved. We haven’t measured those things. It also helps distinguish a file being created from a workflow being tested, accepted, or published.

Alongside the project work, we’ve been getting clearer about how I want to work: practical instructions, reviewable outputs, and a way to correct something that doesn’t fit. Keeping account contexts separate is part of that discipline. Personal preferences can help shape the work without pulling unrelated information into it.

The series can take one project at a time and show the starting problem, the actual output, the feedback, and the remaining checks. Readers should be able to take away something they can use: a brief, a review checklist, a test plan, or a simple work-log format.

Leo has been useful across the work, with other tools doing their own parts. I still decide what I want, review how it looks and behaves, and give approval where it’s needed. When an approach runs into a limitation, we have to make a real decision about the next step.

That’s the story worth documenting: a clearer service website, a phone tool I can use, an avatar video ready for its scheduled run, and a small outreach process with follow-ups configured. There are also open tests. Showing both makes the work easier to understand and gives us a better place to start the next round.