Start a one-person company in the age of AI

Chapter 1 of 12

Find a problem worth solving

One customer, one problem and a way to investigate it.

The first thing I'd want to know about your idea is who it's for. If you tell me 'everyone who wants to be more productive', I still can't picture the person or what you'd do for them. But if you tell me there's a gym owner recording coaching advice on their phone, and the videos keep sitting there because nobody edits them, now we have something to talk about. I'd ask what happened to the last recording and why it hasn't been posted.

Say you want to run a content agency. You could spend ages working on 'social media management for businesses', or you could speak to that gym owner and find out what they actually need. Maybe they already have somebody editing and the problem is getting footage from the coaches. Maybe the footage is fine and they hate writing the posts. Your offer changes depending on the answer. That conversation gives you a job to build the package around.

The same thinking works with a product. Imagine a commuter carrying a laptop, lunch and gym kit in a bag that doesn't fit the things they need. There's a reason to look at dimensions, compartments and how it feels to carry. A holiday bag solves a different problem. With SaaS, I'd look for a repeated job somebody's struggling through with spreadsheets, messages or an awkward tool. With a personal brand, listen to what people are trying to learn and where they keep getting stuck.

In the conversation, I'd keep asking about things that happened. What did they try last time, what went wrong, what did they pay for, and what have they just accepted as annoying? It's easy to get carried away when someone likes your idea. I get the excitement. But say the gym gets plenty of members through referrals and the owner doesn't care about posting. You can make excellent edits for them and still be offering something they don't want to buy.

I'd use AI here to organise the notes and suggest what I haven't asked. Give it the actual conversation or permitted review material, keep the original comments and links, and ask which parts of its interpretation came from those sources. Read the originals when something sounds doubtful, and check it with the person.

Do the work

1. List three groups you can reach. Name a specific problem for each, rather than a broad industry.
2. Choose one and investigate a recent example through a conversation, a product review or direct observation.
3. Write down the current workaround, why it falls short and what remains unverified.

Help me examine this business problem. Customer: [specific person and situation]. Problem: [task or frustration]. What I actually observed: [notes, dates and sources]. Current workaround: [details]. Separate observations from assumptions, suggest alternative explanations and prepare five questions about recent behaviour. Don't invent customers, quotes, budgets or demand. Finish with the most useful thing to check next.

Make the decision

Which problem can you actually investigate with the people you can reach? Start there, and write down what you still don't know.

Chapter 2 of 12

Choose your business model

A starting model that fits your customer and the work you can deliver.

I think people get attached to the identity of a business before understanding the work. 'I'm building a SaaS.' Okay, what does someone pay you for, and what do you have to do after they pay? That's how I'd compare the models. You can choose something you find exciting, obviously, but I'd want you to understand the actual exchange you're choosing.

With SaaS, somebody pays for access to software, usually through a subscription or usage-based payment. Say a studio uses your tool for client approvals. They can use it again on the next project. But now you have to help them get started, keep their information available and sort out problems. I'd be thinking about whether the tool helps enough that they want it again next month.

With ecom, you sell a physical product through a store or marketplace. You might keep stock, manufacture it or use a supplier for fulfilment. The decision is concrete: they order the bag, and a bag has to arrive. The page can't do the job for it. You need to understand sourcing, quality, delivery and returns before putting money into inventory, because all of those are part of what you sold.

An agency gets paid to do work for someone. Content could mean turning an interview into articles or videos. Marketing could mean improving a page or running a specific campaign. An AI agency might connect systems, build a workflow or maintain an automation. If I were buying from you, 'we do AI' wouldn't explain much. I'd want to know what your work would change in my business, what I'd have to give you and what I'd get back. Start with a job you can learn to do and explain clearly.

A productised service is that work given a repeatable shape: these inputs, these deliverables, this turnaround, these limits. Four edited videos from supplied footage is easy to understand. You can start by doing customised work and notice that customers keep asking for similar things. That's a useful reason to package it. I wouldn't spend too long designing tiers before finding out what the jobs are actually like.

A personal brand is how people come to recognise you, your interests and your work. It can help someone trust you enough to buy, but you still need an offer. If you teach product videos, maybe you also sell production work or a practical resource. You could sell software, products or sponsorships through a brand too. Ask what the audience would buy from you and why. A follower count by itself doesn't answer that.

Give AI two models you're considering, your current skills, real ways you can reach buyers and your budget. Ask it to compare what you'd sell, how you'd test demand and what you'd have to deliver. Read the recommendation as something to argue with. If it says SaaS is scalable, ask why anybody would adopt this particular tool. Choose a model you have a way to try, and let the first attempts teach you whether you want to keep going with it.

Do the work

1. Describe what the customer would buy under two plausible models for your problem.
2. List what each needs: skills, customer access, tools, delivery, support and upfront spending.
3. Choose one starting model and write the evidence that would make you reconsider it.

Compare [two business models] for this customer and problem: [details]. My current skills: [skills]. Buyer access: [real routes]. Budget: [amount]. Evidence so far: [notes]. Explain what the customer buys, how I'd test demand, what I must learn and what I'd have to deliver after a sale. Flag unknowns. Don't invent prices or choose a model just because it sounds scalable. Recommend the next test, with a reason.

Make the decision

Choose one starting model and the first test you'd run. Keep the reason with it, so you can revisit the choice after you have a result.

Chapter 3 of 12

Start without pretending you're experienced

A useful sample and a small promise you can keep.

I had an engineering background and I'd worked in consulting, and I still tried to scale businesses I hadn't properly validated. So I wouldn't treat credentials as an answer to whether you can make this business work. If you're inexperienced, name the part you don't know how to do yet. Editing sound, making a checkout work, explaining a service to a buyer: those are things you can practise. Choose the skills your first offer needs and make something small enough to finish and judge.

Say you're offering short videos to local businesses. Make a few videos from footage you own or have permission to use. Can I hear the speaker, read the captions and understand the point before I lose interest? If the sound is rough or a caption is wrong, there's your next improvement. Compare the attempt with its brief and get someone else to watch it too. You need to see where the work falls short while there's still nobody waiting on a paid delivery.

AI is useful for this because you can keep asking about the part you don't understand. Give it the task and where you're stuck; ask for an explanation, a practice brief or a critique of your attempt. If it makes something for you, ask how it works and how you'd check it. Then do that check. I want you to come away knowing a bit more about the work, because when a customer asks for a change, somebody has to understand what needs changing.

You can show the sample without dressing it up as a client project. 'I made this to show how I'd approach your footage' is enough. If it's a redesign of a public page, describe it as your independent concept. Don't put a company's name beside it as though they hired you, and don't add a testimonial they never gave. Let the buyer look at the work and understand what you can do.

Your first promise can cover a few deliverables, one workflow or one narrow software use case. Agree what the customer needs and what a good result looks like, then offer a paid pilot when you can actually deliver it. If the sample shows you can't do it yet, practise or make the offer narrower. That gives you an offer you understand, rather than a huge promise you still have to figure out how to fulfil.

There are also things where an AI explanation won't make you competent to judge the result. Security, sensitive data, product safety, specialist advice. I'd get qualified help or keep the work within what I can assess, rather than pretending a confident answer solved it. Be clear about the parts you can assess and take responsibility for.

Do the work

1. List the skills required for your first offer and identify which you can already demonstrate.
2. Practise the weakest essential skill on a small task with a clear completion check.
3. Create one relevant sample and describe honestly what it proves and what it doesn't.

Act as a practical tutor for [specific skill]. I'm trying to deliver [small offer] for [customer]. My current ability is [details]. Create one practice task using public or made-up inputs, explain the essentials and give me a checklist to judge my attempt. After I share the attempt, identify specific errors and the next improvement. Don't write a fake portfolio, testimonial or claim of client experience.

Make the decision

Does the sample show you can deliver the offer? If it does, show it to a prospect. If it doesn't, name the part you need to practise or narrow.

Chapter 4 of 12

Validate the idea

A demand test with a specific offer and an observable result.

When I say validate the idea, I mean find out the thing you currently don't know. Maybe you've spotted an annoying job but haven't established whether people care enough to change it. Maybe they care, but you haven't shown that your solution works for them. Or you've had plenty of good conversations and still haven't put a price in front of anyone. Those need different tests. Start with whichever answer could change what you do next.

For the studio approval tool, I'd make the smallest working journey I could show: upload an item, ask for a decision, record the response. Then let somebody who actually handles approvals try it. Watch what they do before explaining every click. Do they know which version they're seeing? Would this fit a real project? If another tool already handles the job easily, get them to show you. You may change the idea quite a lot after seeing their process.

For an agency, I'd show the sample, explain the paid pilot, list the inputs and deliverables, and give the price. Then ask whether they'd like to go ahead. With ecom, get a sample people can see alongside the real price and realistic delivery information. A waitlist lets you find interested people, but I'd still want to know if they'd buy under those terms. Only take paid orders when you're prepared and legally able to fulfil them; an unpaid reservation can help you test interest earlier.

For a personal brand, make something useful for the audience you want and give them a relevant way to act. Maybe they download a resource, ask a question about their own work or book a conversation about your service. Look at who responds. Getting a lot of views can be exciting, but if they're from people who have no use for your offer, you haven't learned much about the business yet.

Keep a record of the response without making it more impressive than it was. Someone said they liked it. Someone gave you their inputs. Someone paid. Someone used it. They're different things. Keep the original responses; it's easy to remember the bit you wanted to hear. A first payment is meaningful, and then you need to learn whether the work helps, whether they use it and whether they want it again.

Before the test, write down what would make you continue, change something or stop. A handful of relevant conversations can reveal a repeated problem and get you to a next commitment; it won't establish some universal conversion rate. If people aren't responding, go back to the customer, offer and solution. Change something you have a reason to change and try again. One attempt gives you feedback about that offer, which you can use in the next attempt.

Do the work

1. Name the most important thing you haven't proved: problem, solution, willingness to pay or continued use.
2. Choose the smallest test that exposes that uncertainty to real customers.
3. Record exactly what people did, then decide what to keep, change or test next.

Review my validation attempt. Customer: [details]. Offer and price: [details]. What I tested: [test]. Actual responses and actions: [sanitised notes]. Separate interest, problem evidence, commitments, payment and usage. Identify contradictions and alternative explanations. Tell me what I can reasonably conclude, what I can't conclude and one next test. Don't turn compliments or AI predictions into demand evidence.

Make the decision

Use the response to choose what happens next: keep the offer, change it or investigate a different problem. Be specific about what led you there.

Chapter 5 of 12

Make a clear offer

A scoped offer you can show to a real buyer.

If I'm the customer, I'm trying to understand what happens after I pay you. That's where vague offers fall apart. You might know exactly what 'AI solutions' means in your head, but I don't. Tell me the job you can help with, what I'll receive, what you need from me and what it costs. Your excitement about the technology can come through, but I still need to see how it serves me.

For the gym owner, you could say: 'I'll turn one recorded coaching session into four edited short videos, with captions and draft post copy. You provide the footage and approve the edits. The pilot includes one revision round.' Show the sample, discuss their footage and give the price. Notice that the promise is about the work you can deliver. You haven't told them four videos will definitely bring in new members.

An AI agency could offer a workflow that drafts replies to common enquiries using approved information. I'd explain where the answers come from, what happens when information is missing and who reviews the replies before sending. A marketing agency might improve one page and measure an agreed conversion event. Commit to the work and measurement, and explain what else affects the result: traffic, the offer, customer behaviour. Only promise the result you can control.

With SaaS, tell someone the main job the tool does, who the first version fits and what its limits are, including how to get help. With ecom, make the product, total price, delivery and returns easy to find. For a personal brand, turn what you know into a service or resource that helps with a specific task. 'Everything about business' is hard to buy because I can't picture what I'd be able to do with it afterwards.

I'd also have the scope conversation early. What footage does the customer need to provide, what does a revision include, and what needs a new quote? Correcting a caption is different from being given unusable footage or asked to change the whole campaign. Write it in ordinary language and get appropriate help with the terms. Check that any template matches what you've agreed.

Then check what it costs you to deliver. Tools, suppliers, fulfilment, payment fees, relevant refunds and any help you pay for all come out of the price. Allow for your own work and support too. Say a product sells for $50 and you assume product, packaging, shipping, payment and acquisition costs total $38. That leaves $12 before other expenses and tax. Include returns and support, and replace those assumptions with actual quotes and results.

Do the work

1. Write the customer, benefit, deliverables, inputs, limits, price and next step on one page.
2. Check delivery costs and identify which figures are known and which are estimates.
3. Show the offer to someone unfamiliar with it and ask them to explain what they would be buying.

Turn these notes into a clear first offer: [notes]. Include who it's for, the problem, deliverables, inputs, limits, acceptance checks, proposed price and the next step. Flag missing decisions and costs. Remove unsupported performance claims. Then critique it from the buyer's perspective: what feels vague, risky or hard to understand? Don't invent proof or write legal advice.

Make the decision

Check that the buyer can understand the work, price and next step, and that you can fulfil the agreement. Then make the offer.

Chapter 6 of 12

Build properly with AI

A clear build brief and a small working version with checks.

This is where I think the opportunity gets really exciting. You can describe something you'd like to make and work through it with an assistant: the plan, the code, the errors, the bits you need explained. You can attempt work that would have been much harder to approach alone. But I'd keep asking what the thing is supposed to do for somebody. Otherwise it's very easy to end up with a lovely interface around a job you haven't understood.

Let's take the design studio that needs client approvals. They need to know which version was approved and what still needs changing. Give AI that situation, the current process, the user and what a successful result looks like. If you only ask for an amazing SaaS dashboard, you're making it guess the product. Tell it what the studio actually needs to get done, and you have something to build towards.

Keep the brief in a document you can update: customer, problem, scope, example inputs, expected output and rules. For the first version, I'd include creating a project, uploading an item, sharing it with an authorised reviewer and recording the decision. Invoicing, chat and reporting can wait. Get that job working before adding more around it.

Walk through the screen in the customer's order. The studio creates a project and adds an item. The reviewer sees the permitted item and the right version, then makes a decision. The studio can see the response. Ask AI to sketch that journey, and try it with an empty project, a long filename and a wrong link. Check whether someone can work out what to do and tell whether it succeeded or failed.

Then ask what information sits behind it. A project has an owner, an item belongs to a project, and a decision belongs to a version and reviewer. Get the assistant to explain those relationships in plain language and walk through a sample with you. An 'approved' label needs to refer to the correct version. Those relationships affect what you can show the studio later.

Access needs its own check. Somebody logging in doesn't give them permission to see every project. Hiding a button won't stop them opening a link or asking for data directly. The app has to check permission where information is read or changed. Make two test accounts with separate projects, then try opening the other account's item and submitting a decision you aren't allowed to make. Get competent technical review before putting sensitive customer information into it. I wouldn't judge this by how convincing the login screen looks.

Build one piece, get it working with made-up test data, connect the store, add the access rules and test the full journey. Ask which files changed and how to run the checks. Save the working version before the next change, through version control or the builder's supported history. If the next feature breaks something, you want a version you can return to while you figure it out.

When something breaks, describe what you expected, what you did and what happened instead. Share the relevant error with private information removed. Ask AI to reproduce the problem, explain the likely cause and make a repair you can check. Then repeat the original action. Did it work, and does the rest still work? An explanation and a repeated check let you understand what the repair changed.

Keep a few tests you can run again: create a project, upload an allowed file, reject an invalid one, approve the current version, request a change, block an unauthorised decision and recover from a failed upload. Repeat an action and refresh the page as well. Make sure the tests fail when the behaviour is wrong. If the assistant removes a failing check to get a green result, restore it and fix the actual behaviour.

You can build with AI without using a model for every feature. If a reviewer presses an approval button, ordinary code can store that decision. An AI summary might help the studio read a collection of feedback, but it should use the actual notes and leave the originals available. The reviewer still decides what to approve. Use the model where interpretation or drafting helps, and keep straightforward operations simple enough to inspect.

For planning and writing, a conversational assistant can help. For software, choose a coding assistant or app builder you can operate and maintain. Before paying, look at current costs, limits, data handling and how you'd retrieve your work. I wouldn't try to assemble some perfect tool collection before making the first useful thing. Choose tools for that task; you can change them later.

Keys and passwords belong in the tool's supported secret settings, away from conversations and source files. Keep private server work separate from public browser code. Practise with public, made-up or sanitised information, and agree permission and suitable handling before customer data enters a provider. If the workflow can send messages, change live records or spend money, put approval before the action. Check what it's about to do before approving it.

I'd launch this in stages. Use a separate test environment, go through the core journey yourself, then invite a few suitable testers with non-sensitive data. Watch where they get stuck and repair those problems before a wider release. Once people actually rely on it, somebody needs to notice failures, respond to support questions and recover information. Prepare for that support and recovery before people rely on the tool.

Keep asking about the unfamiliar parts as you go. Why does the data belong there? What changes when we add a second user? How would we know that this upload failed? You don't need to memorise a whole technical field to start, but you do need to keep building your understanding. I think that's one of the best uses of AI here: you can make the thing and learn why it works at the same time.

Do the work

1. Write the customer journey, scope, example inputs and acceptance checks before generating the product.
2. Build one working slice, save it and test normal, invalid and unauthorised actions.
3. Fix observed failures, repeat the checks and invite a small test group before a wider launch.
4. Get competent review for security or specialist areas you can't adequately assess yourself.

Help me build [specific product or workflow] for [customer]. Problem and current process: [details]. First-version journey: [steps]. Included and excluded features: [scope]. Test inputs and expected outputs: [examples]. Start by identifying missing decisions and proposing the smallest working slice. Explain the interface, stored data and access rules in plain language. Implement one step at a time, describe the changes and provide repeatable tests for successful, invalid and unauthorised actions. Keep secrets out of public code. Don't add features, remove failing checks or launch anything without asking me.

Make the decision

Once the small version passes your checks, let a suitable tester use it. Their attempt gives you something concrete to improve.

Reference: GitHub: Review AI-generated code. Further reading on reviewing generated code, checking constraints and retaining meaningful tests. The build walkthrough is a proposed teaching example.

Chapter 7 of 12

Use AI in your chosen business

One repeatable workflow with real inputs, a checked output and a handover.

Now I'd pick the output you're actually going to use in the business. It might be a software journey, a product page, client content, a marketing page, an enquiry reply or something under your own name. Give AI the real material it needs, explain who the output serves and decide how you'll judge it. You'll learn where it helps by completing the task.

For SaaS, take the approval-tool brief and make that first journey with test accounts and sample projects. Check the interface, saved decisions and permissions, then write down how to run it. Give it to somebody who wasn't there while you built it. Watch where they begin and whether the result makes sense to them. They haven't been there while you made it.

If you add an AI feedback summary, make a small set of test notes. Ask it to group the requested changes, link each point to the original and flag contradictions. Say one client wants the old colour and another asks for a new one. I don't want a smooth paragraph that quietly chooses between them; the studio needs to see the disagreement. Read the summary against the notes and check for anything missing or invented.

Keep those examples and run them after changing the prompt or model. Include clear feedback, vague feedback, conflicting requests and a note trying to tell the model to ignore your rules. Write down how each should be handled. Then compare what it does with what you expected, improve the feature and repeat the old cases. Compare the new result with the earlier cases too.

For ecom, come back to the commuter bag. Gather reviews from sources you're allowed to use and keep the product, date and original source attached. Ask AI to organise complaints about size, straps, compartments, water resistance and delivery, while separating the customer's actual words from possible design ideas. Read the reviews yourself too. Find out what people meant by 'too small' before changing the product.

Use that research to ask suppliers better questions: actual dimensions, materials, durability evidence, sample cost, order arrangements, delivery and returns. AI can turn their answers into a comparison table. Missing information should stay missing until you ask for it. Then get a sample and use it. Put your stuff in it, carry it, try the zip. The summary can't settle how the bag feels to use.

Give AI verified specifications, your observations and the customer's situation to draft the product page. Explain what fits, show actual measurements and make delivery clear. Use real photographs or clearly identified illustrative images. If a generated picture adds a pocket the bag doesn't have, or the page calls it waterproof without support, you've created a problem for the person opening the parcel. I'd go through the page beside the real product, including any reviews, and check that the claims hold up.

Build the store somewhere you can maintain and test it. Check variants, stock, price, delivery charges, confirmation and the support route. Place an order through the platform's supported test mode, and follow fulfilment and cancellation. AI can prepare the checklist and customer messages, but go through the actual process yourself. If the order says blue, the supplier and store need to agree that blue is what goes out.

For a content agency, start with an approved interview, recording or set of notes. Tell AI who you're speaking to and what you want them to understand. Ask for angles with the relevant source passages attached, pick the one that makes sense and work through the outline and draft. Check quotes and factual claims against the material. Use that help to spend more attention on the thought and edit, keeping the client's voice in the piece.

For video, AI can help with transcription, rough selections and captions. You still need to check them against the audio and picture. A wrong word or a cut that removes context can change what the speaker means. Watch the exported file, check names and numbers, and make sure you have permission for the footage and music. Review that export, even if it looked fine while editing.

For marketing, give AI the actual offer, customer notes, current page and genuine evidence. Ask where the message gets confusing, and make a few approaches that differ in a meaningful way. Pick one and explain why, then test it against an agreed outcome. Before a campaign goes live, check the audience, destination, tracking and spending limit. AI can help you prepare variations and interpret results, but if the checkout is broken or the offer doesn't fit, you'll need to address that problem directly.

For an AI agency, map one process with the customer first. Say the team receives course enquiries and checks an information sheet before replying. You could retrieve approved information and draft a reply with sources, ask for input when the answer is missing, and let a person review before sending. I'd test it with a changed date, an incomplete question and a completely unrelated enquiry. Check what happens when the input doesn't fit the demo.

Keep a manual way to do the job when automation fails, and record failures somewhere somebody will see them. Agree who responds and who keeps the underlying information current. Repeat relevant checks when a tool or source changes. Before connecting an inbox or another system, establish permission and the right access. Agree those responsibilities while scoping the work, including who maintains the delivered version.

For your own brand, start with your own observations, notes and recordings. AI can help find the thought, organise the explanation and spot where an example would help. Give it permitted examples of how you actually write or speak, then read the draft aloud. If a line sounds like anybody could have written it, go back to what you meant. Keep what happened, what you think and why you care in the piece. Don't manufacture a struggle or success to make it feel personal.

Connect the content to something useful. If you teach product photography, show a setup you've actually used, give the reader an exercise and offer a specific service if that fits. AI can help organise the resource, but the examples and choices need to come from you. Make it useful enough that someone can judge whether they want more of your work.

When you finish a workflow that works, save the inputs, AI task, checks, approved output and handover. Keep a good example, along with the mistakes you fixed. Next time you'll have something to compare against. Someone joining you can use the completed example, mistakes and repairs to understand the job.

Do the work

1. Pick the workflow that produces your next useful customer-facing output.
2. Gather permitted source material, define the output and write the checks before asking AI to work.
3. Complete and inspect one example, including an awkward input or failure.
4. Save the approved process and hand over the result with clear instructions.

Help me complete [specific business workflow]. Model: [SaaS/ecom/agency/personal brand]. Customer and intended benefit: [details]. Approved source material: [sanitised inputs with references]. Required output: [format]. Checks: [criteria]. First identify missing inputs. Use only supplied facts, trace claims to their source and leave unknowns unresolved. Propose a small sequence, complete the first agreed step and identify what I should inspect. Include a failure case and manual fallback where relevant. Don't invent testimonials, product features, personal stories or results. Don't send, spend, publish or change live systems.

Make the decision

Check the output against the source and brief before using it. Keep the process and a failure case so you can run it again.

Reference: Shopify: Product research methods. Further reading on product research, customer reviews and product evaluation. No tool price, demand forecast or platform endorsement is implied.

Chapter 8 of 12

Get your first customer

A prospect list, a truthful message and a real sales attempt.

I used to spend far more attention on the product than on reaching customers. You can keep adding things and pushing the conversation into the future, and AI makes it easier to stay busy doing that. At some point someone needs to see the offer and be able to respond to it. They might say no. But I'd rather have that response to work with than keep expanding a business nobody's agreed to buy from.

For the gym service, I'd look for owners who already record useful footage and want help publishing it. An introduction, a local network or a public business contact route can get you to them. Look at the business before writing, so you have an actual reason to contact this person. Don't send some automated diagnosis of their terrible marketing when you barely know what they're trying to do. Find out whether the job you've chosen matters to them.

Say you saw their public coaching videos and made a format sample using your own footage. You could write: 'Hi [name], I saw your videos on [actual topic]. I'm starting a service that turns supplied coaching footage into short edited posts. Here's a sample of the format. If editing is something you want help with, would you like me to send the pilot details?' I'd keep it that straightforward. Use what you really noticed, let them inspect the sample and give them an easy next step.

When there's interest, ask for a commitment that fits the conversation. Agree a paid pilot, arrange a demonstration with the decision-maker or inspect the inputs before quoting. If they hesitate, ask what they're unsure about. Maybe they don't understand the deliverable, don't trust the quality yet or don't have the budget. You can respond to that. And if they tell you it isn't useful to them, listen. The conversation is supposed to help you understand their decision.

For SaaS, get suitable people through the core action and help them start using it. For ecom, show the actual product in a relevant marketplace, on a page or in a community that allows promotion; make delivery and support clear. With a personal brand, publish something useful for the intended audience and give them an offer they can act on. I'd start trying to reach those people before worrying about a huge following.

AI can help organise public information about a prospect, critique your message and practise likely questions with you. Check the sources and the reason for contacting them, and keep the message truthful. Then pay attention to the actual reply. They may bring up something you didn't rehearse, which is useful. Use the preparation to help you listen and respond, including when the reply surprises you.

I'd follow up when there's a reason, like an agreed date or an answer you said you'd get. Respect the channel's rules and anyone asking you to stop. Keep the message, response, offer and next step together, so you can see where attempts are ending. If a batch goes nowhere, inspect the fit and message before contacting more people. Use the responses to improve the next attempt.

Do the work

1. Find a small group of relevant prospects and record a real fit reason for each.
2. Prepare a sample, a short message and the offer you'll send if they're interested.
3. Have the conversation, make a specific ask and record the response without upgrading it into a sale.

Review this first-customer approach. Prospect's public facts and source: [details]. Why the offer fits: [reason]. Sample: [description]. Offer: [details]. Draft message: [text]. Make it clear, brief and natural. Remove invented familiarity, diagnosis and promises. Suggest a next step and help me prepare honest answers to likely questions. Don't send the message or invent anything about the prospect.

Make the decision

Ask for the next commitment that fits the conversation. Record the answer and what you'd change about the next attempt.

Chapter 9 of 12

Manage your first customer

An onboarding note and a delivery process your customer understands.

When someone pays, your offer becomes a thing they're expecting you to do. Make the next step clear immediately: what happens now, what you need and when they'll hear from you. And if you're still working part of it out, communicate while you do that. A customer can respond to a clear question or update; they can't do much with you disappearing.

For a service, send a short note with the agreed work, required inputs, how to share them and the first milestone. Establish who approves it. Say three people at the gym comment on the edits and they all want different things. I'd ask for one person to collect the feedback and make decisions before revisions start. Otherwise you can end up making contradictory revisions.

An update should tell them what's finished, what you need from them and what's stuck. If a milestone changes, tell them early and explain what you're doing. I'd rather receive a plain message I can act on than find out at the deadline that the work isn't ready.

Keep feedback beside the brief and in one place. If you got a caption wrong, correct it. If they want a different campaign or twice as many videos, talk about the new work and price before doing it. Caring about the customer doesn't mean quietly accepting every extra request. They may not realise it's extra work until you discuss it.

For SaaS, help the user get their first useful result. Show where to begin and what information is needed, then watch whether they complete it. When an error is reported, acknowledge it, gather the detail you need to reproduce it and keep them updated. Take it seriously even if it works on your own account. Give them a visible support route and an honest explanation of the first version's limits, so they know how to get help.

For ecom, follow the order through payment, fulfilment and delivery. Give confirmation and accurate updates, and work out how to handle missing stock, wrong addresses and damaged products with the supplier before those problems happen. The buyer placed the order through your store. If another company packs it, that still leaves you needing to help when something goes wrong. Make returns and support easy to find and consistent with applicable requirements.

You can give AI approved notes to make an onboarding checklist, update or feedback summary. Read the result before sending and check that the finished work is actually finished, with dates you've agreed. If updates are automated, they need a real status to work from and a way to flag missing information. Check that it doesn't fill in a missing status with an invented update.

After delivery, ask what they used and what still needs attention. If there's a problem, work on it before asking for a public review. Get permission before sharing their work, name, quote or results, and agree the next job if they want to continue. Their use of the work helps you judge what to improve and whether another job makes sense.

Do the work

1. Send a start note with the agreed work, inputs, approval contact and next milestone.
2. Keep feedback and decisions in one shared place and address blockers early.
3. Check the final delivery against the promise, hand it over clearly and follow up on actual use.

Turn these approved customer notes into an onboarding note: [sanitised notes]. Agreed offer: [scope]. Inputs needed: [details]. Approval contact: [role]. Milestones: [dates or stages]. Include how feedback, changes and support work. Flag missing decisions. Don't invent commitments or deadlines. Then produce a delivery checklist that maps each promised item to an observable check. I will review before sending.

Make the decision

Confirm the inputs, approver and next milestone with the customer. Keep them informed while you deliver, and follow up after the handover.

Chapter 10 of 12

Make customer acquisition repeatable

A channel experiment with a clear offer and useful measurement.

Once someone has bought, I'd go back through how it happened. Where did they find you, what made them interested, and what helped them decide? You need a way to reach another suitable person. Test one route first, so you can interpret the response before changing several channels together.

For an agency, introductions, researched outreach, partnerships and demonstrations can get the work in front of business owners. SaaS might fit a specialist community, an integration, useful content or searches around the job. Ecom might suit a marketplace, product demos, creators or paid traffic once the offer and fulfilment work. A personal brand can build through useful content and relationships with the audience. Choose somewhere the buyer pays attention and you can show the offer.

Think about what buying involves for that person. If your software changes an internal process, they may need a conversation and demonstration before committing. An ordinary consumer product needs a clear page and a checkout that works. So the next step has to fit their decision. Judge the channel by how it fits that decision.

Write down the route from first contact to purchase. For the agency: message, reply, conversation, proposal, pilot. For ecom: demonstration, page visit, checkout, order. For SaaS, keep going through signup to the first useful action. Put the actual counts beside the steps and leave missing information blank. Look for where people stop.

Suppose they reply to the message but won't take a conversation. I'd look at whether you've made the next step useful or asked for too much. If calls happen and offers aren't accepted, look at fit, promise, proof and price. If they buy once and don't return, look at the delivery and satisfaction. Keep enough detail to distinguish those problems.

Content can show the work directly. Demonstrate an edit or tested workflow for an agency, show the product in use for ecom, or explain an actual attempt through a personal brand. Give somebody something worth looking at, so they can see what the offer does. Make the offer easy to find if they want that help.

If you test paid acquisition, set a spending limit and count purchases as well as clicks. First make sure you can fulfil the offer and understand delivery costs. Compare what it costs to get a customer with what remains after the order, relevant returns and support. I'd be cautious about using repeat purchases that haven't happened yet to explain away a loss on the first order. Increase spending when the actual results support it.

Give AI the data you have and ask where the process appears to be losing people, separating observations from possible explanations. Choose one meaningful change and prepare the page, content or message for the next test. Keep it tied to the real offer. Compare the new result with the earlier attempt.

Do the work

1. Choose one channel that fits how your customer finds and buys this kind of offer.
2. Map the steps to purchase and record the actual outcomes and costs available to you.
3. Identify the weakest meaningful step, change one part and compare the next attempt.

Analyse my acquisition attempt. Model and customer: [details]. Channel: [route]. Offer: [details]. Steps and observed counts: [data]. Costs and delivery outcomes: [known figures]. Separate observations from guesses, flag missing denominators and propose plausible reasons for the biggest drop-off. Recommend one change and explain what result would support it. Don't invent a conversion benchmark, causal claim or repeat-purchase value.

Make the decision

Choose the step to improve and run one more test through the same route. Compare the real outcomes before adding more effort or spend.

Chapter 11 of 12

Hire when there's a reason

A defined role, a paid trial and a usable handover.

A one-person company doesn't have to mean doing every task with your own hands forever. You can direct the business and buy help. I'd start by looking at work that's actually stuck: editing the videos people already paid for, technical support you can't handle, or packing orders that keep getting delayed. Define that problem before hiring.

Is it repeated work, or is it a decision you haven't made? If you still don't know what the package includes, another editor is going to need you to answer that. If the package is clear and edits are waiting, help with editing may address it. Separate those cases so you can define the person's actual job.

Sometimes a clearer brief, simpler package or useful AI step will address the problem. Sometimes you need a person's judgement, especially where you can't assess the work yourself. Look at what is delaying or weakening delivery and choose the help that addresses that cause. Judge the change by whether it helps delivery.

Define a task and the right working relationship. Contractors and employees have different responsibilities, so check what applies locally. Agree inputs, output, checks and who makes decisions. If you tell someone 'help me grow the business', they'll still need you to explain what that involves. Define what a finished first job looks like.

For the content agency, pay for a trial editing one permitted sample clip. Supply the footage, audience, style references you have rights to use, caption requirements and delivery format. Judge clarity, sound, accuracy, communication and whether it follows the brief. Agree the fee and use of the work first. Pay for a manageable trial; don't ask for substantial unpaid client work.

For technical help, define the feature or review and the checks that show it works. Keep the trial away from sensitive live systems until access and handling are agreed. Look at a small code change, explanation and tests together. If you can't competently judge those, get a qualified reviewer. Get help judging the result if you don't understand it.

Build the handover from a completed job. Include the inputs, approved example, process, common mistakes and checks, and let AI help organise the instructions. Then have someone try them. Where did they get stuck? What did you assume they would know? Add whatever they needed and couldn't find.

Give the role the access it needs and agree how files, customer information and accounts are handled. Keep ownership and recovery routes clear; remove access appropriately when the work ends. Review output before it goes to the customer until reliable delivery gives you a reason to allow more independence.

Watch whether the stuck work moves and quality holds up, and include the person's cost in the offer. If the process causes problems, improve it instead of just passing those problems along. You can expand the role when delivery and demand support it. Check whether the help addresses the original bottleneck.

Do the work

1. Name the delivery bottleneck and decide whether to simplify, automate or hire for it.
2. Define one role by inputs, output, checks, access and cost, then design a paid trial.
3. Create a handover from a completed example and review the trial before expanding responsibility.

Help me scope support for this bottleneck: [details]. Customer promise: [offer]. Current process and failures: [notes]. Suggest whether simplifying the work, using AI or hiring a person addresses the cause. For the person option, draft a bounded role and paid trial with inputs, output, acceptance checks, communication and minimal access. Flag specialist or legal questions for verification. Don't invent employment terms, candidate credentials or savings.

Make the decision

Use a paid trial to judge whether this help addresses the bottleneck. Review the work and cost before increasing responsibility.

Chapter 12 of 12

Take the next step

A practical next move based on what you have and what you still need to prove.

At this point I'd look at what is actually in front of you. If nobody's seen the offer, get it in front of somebody. If a customer paid and you're struggling to deliver, work on that delivery. If users are signing up but can't complete the first action, go and watch where they stop. Use the current situation to choose what needs your attention.

At the idea stage, that might mean a conversation or a small useful demonstration. While building, finish and test one complete customer action. With an interested buyer, make the offer and ask for a next step. With a customer, deliver, follow up and learn what they used. As it grows, address the acquisition or delivery problem you can see.

There are business basics to put in place before your activity needs them. Check official guidance where you operate and for what you sell: registration, licences, tax, invoices, payment arrangements and records. Employment, residency or professional restrictions may also apply. AI can help organise the questions, but verify the answers with the responsible source. Check what applies to your circumstances.

Your model brings its own responsibilities. Physical products can involve safety, imports, delivery and consumer rules. SaaS and services can involve contracts, customer data, intellectual property and insurance; hiring adds further obligations. Ask AI to organise the questions and take them to the responsible authority or qualified help. The US Small Business Administration gives examples of setup categories. You'll need the equivalent official guidance for your jurisdiction and activity.

Keep a record you can actually maintain of the offer and money: what you agreed to deliver, what it costs, the price and what's due. Improve it as the business develops. Update it when a supplier quote, extra request or support cost changes the figures.

Decide when you'll review the next attempt, what you're doing, what you expect to learn and what choice follows. A conversation can change the problem, and a test can show you the screen is confusing. Leave yourself room to respond. Make the review about what happened, rather than whether it met an arbitrary deadline.

Give AI your notes, evidence and available resources, then ask what the next action depends on. Does the suggestion require an input you don't have, or demand you haven't proved? Check those assumptions and make the decision yourself. The assistant can help you think it through.

Do the work

1. Choose one next action based on your current evidence and commitments.
2. Check the official setup requirements relevant to the activity before proceeding with it.
3. Write what you'll collect from the next attempt and the decision you'll make afterwards.

Use my notes to identify the next useful business action: [notes]. Model: [model]. Customer and offer: [details]. Evidence collected: [results]. Current commitments and resources: [details]. Recommend one immediate action, its required inputs, the output and what I'll decide afterwards. List relevant setup questions for official local verification without answering them as law. Don't invent demand, promise a sale or turn this into a huge plan.

Make the decision

Put one next action in your business note, do it and record what happened. Use that result to decide where you go next.

Reference: US Small Business Administration: Launch your business. Examples of US setup categories only. Verify requirements using the responsible authority for your own jurisdiction and activity.

Your next move

I keep coming back to the point about distribution because that's something I had to learn. I was building and trying to scale businesses before I'd really found out whether people wanted them. So I'd like you to put the offer in front of somebody earlier than I did, and then use what happens to make the work better. You can still be excited about the idea. Let the conversation affect where that excitement takes you.

And give yourself some room to enjoy making it. I think there's so much you can explore when you aren't expecting your whole life or business to look a particular way already. You might find that you like making the product, or working with the customer, or explaining something in public. Follow that interest, keep testing what you're making, and see where the actual work takes you. Pick the next thing from the guide that would help and try it.

Take care bro, and keep building.

Sources and scope

• GitHub: Review AI-generated code

  Further reading on reviewing generated code, checking constraints and retaining meaningful tests. The build walkthrough is a proposed teaching example. Checked 2026-10-05.

• Shopify: Product research methods

  Further reading on product research, customer reviews and product evaluation. No tool price, demand forecast or platform endorsement is implied. Checked 2026-10-05.

• US Small Business Administration: Launch your business

  Examples of US setup categories only. Verify requirements using the responsible authority for your own jurisdiction and activity. Checked 2026-10-05.