A project is something you're building. A business is something other people depend on.
That's the simplest way I can put it. The switch doesn't happen when you register a company or make a logo. It happens when other people start relying on what you do, and you have to keep delivering it.
What this means
I think a project becomes a business when three things are true:
- Strangers pay you. Not friends, not family. People who owe you nothing.
- It's repeatable. You know roughly where the next customer comes from.
- You have obligations. Support, reliability, privacy, refunds. Things you now have to keep doing whether you feel like it or not.
Before that, you're experimenting. After that, you're operating. Both are real work, just different work.
What I learned
I got a taste of the operating side when I ran Yaks Inc., a small software company I founded in 2024. For about a year, I handled day-to-day operations, managed teams working on product development and mobile apps, and did consulting for clients.
What that kind of work makes obvious: a lot of it is invisible, and none of it is optional. Clients need updates. Teams need clear priorities. Things need to be written down so they don't live only in your head. None of that shows up in a product demo, and all of it decides whether the business runs.
Real example: HairOver is in between
HairOver is somewhere between project and business right now.
The business-like parts already exist:
- It's live on Google Play, with real people able to download it.
- It has a support contact listed publicly.
- The website has privacy and terms pages, which you need once real users trust you with their photos.
- There's a pricing structure, a cost per image to manage, and a distribution plan.
What would make it clearly a business is the first condition above: strangers paying, repeatedly, through a process I can repeat. That's the milestone I'm working toward. The math of those milestones is here.
The obligations also grow quickly for a photo app. People upload pictures of their faces. That means privacy and trust aren't nice-to-haves. They're part of the product from the first user.
What changes when it becomes a business
Support. Someone will have a problem at a bad time. You need a way to hear about it and a standard for how fast you answer.
Operations. Payments, refunds, app store reviews, infrastructure costs. For an AI product, watching cost per use becomes a weekly job.
Systems. Things you did by hand once need to become repeatable: a checklist, a template, a script.
Documentation. If it only lives in your head, the business stops when you do. Write down how things work.
Automation. Anything you do the same way every week is a candidate. Automate the boring parts, and keep your judgment for the rest.
Hiring and delegation. Eventually, you can't do everything. Delegation starts with writing things down clearly enough that someone else can own them.
When to hire, delegate, and automate
My rough rule:
- Automate repetitive work that follows clear steps.
- Delegate well-defined work that's holding up growth, once you can describe it clearly.
- Keep the decisions that shape the business (who the customer is, what to build, how to price) close to you, especially early.
And one warning: hiring before the work is clear tends to make things slower, not faster. Adding people to a fuzzy process just multiplies the confusion.
What to do
- Check the three conditions: strangers paying, repeatable, obligations. Which ones are true for you?
- List your obligations to users today: support, privacy, refunds, reliability.
- Write down one process you repeat, clearly enough that someone else could follow it.
- Automate one repeated task this month.
- Set a support standard, even if it's just "reply within 24 hours."
Mistakes to avoid
Acting like a business before you have customers. Company registrations, fancy tools, and org charts don't create demand.
Acting like a project after you have customers. Ignoring support or reliability once people depend on you costs you their trust.
Hiring into chaos. Make the work clear first.
Keeping everything in your head. It limits how far you can grow and how long you can step away.
My current thinking
I'm trying to do this in the right order with HairOver: prove people pay first, then build the operations around what actually happens, not what I imagine will happen. The Yaks Inc. experience taught me how much of running a business is invisible work. I'd rather add that work when it's clearly needed than build an organization for customers who don't exist yet.
Key takeaway
A project becomes a business when strangers pay you repeatedly and you take on real obligations to them. From that point, support, operations, systems, and documentation are part of the product. Build them as the business needs them, not before.
Next: The Math of $1M MRR.