TJ Larkin

AI as a business

What should a software MVP include, and what can you do manually at first?

Short answer

Only what the client needs to get value. Do the rest by hand: billing, data gathering and edge cases can be manual for a couple of months. Sell it cheaper, use it yourself first, give a few people early access, and lead demos with what works. Aim between enterprise-grade and sloppy. Fast still can't mean broken.

One of my problems is wanting things to be too perfect. On a call in July 2026 I talked myself out of building everything first, and the list of things that could wait was long.

"I think we need to get this thing going and live and sellable, even if there's basically a lot of manual stuff on it, and we'll sell it for much less than we normally will."

What should the MVP include?

Only the pieces that deliver the core value. When I scoped a local media website, the MVP was three pages: a news homepage, a business directory and a job board. Launch it in the markets where you already have an audience, then add over time. I didn't even connect it to lightbreak at first. If a client showed up, we'd duplicate it by hand. My estimate was about 20 hours of work.

What can be manual at first?

  • Billing. Automated billing for expiring directory memberships can wait. Payments can be handled by hand for two months.
  • Data. Directory businesses can be scraped manually, around 3,000 businesses for a region.
  • Coverage. Events only need to be good enough, not every Facebook event.
  • Polish. A client who doesn't care about design can skip newsletter styling.

Strip it to the core, which in that case was events, the directory and the newsletter tool. Sell it cheaper and fix the automation later. A teammate added a good trick: hide the manual steps behind a submit form that emails the team. The customer sees a product. You see a task.

How do I balance fast with scalable?

There's a fine line between enterprise-grade and entrepreneur-grade. Enterprise-grade means hardened and scalable in a nearly perfect way, and it costs a fortune in money and time I don't have. Being too half-baked is a problem too, especially once people want to buy the system today.

I was in exactly that spot: about 25 of my own brands on one system, and at least five people with money asking to buy it before I'd even tried to sell. I need to make money soon, but scalability is key. The answer is a middle ground.

AI makes the demo part easy. I can get demos that look really cool working pretty quickly. If you wanted a business directory up for your town by Sunday, I could do it. It just won't be scalable or as pretty, and it probably becomes manual. That's fine for testing one place. Getting something to truly work at scale is so much harder, and that's why the real version takes real time.

Do I have to fix every bug before I sell?

My fear was that early customers would hit enough little broken things that they'd say "cool" and move on. What talked me out of waiting was looking at what the product solved. For local media owners, my newsletter software solved two problems at once: the ability to do a newsletter at all, and doing it in 10 or 15 minutes. It should also make them money, because more newsletters means more ad inventory.

Entrepreneurs get stuck in the weeds on every design element. Those customers mostly couldn't do a newsletter at all yet. My partner and I had to get out of our own way.

The demand was there. I showed it to an owner of 10 newsletter brands, who called it magic and asked what I wanted to charge. I said $400 a month and he said they'd start tomorrow. For the right audience I think it's worth around $500 a month.

How do I demo a product with known bugs?

Open with what already works. For the broken part, say it's still being built and show the manual workaround instead of the broken automation. When events were broken in my newsletter software, the workaround was pasting the event page text into the block. I didn't think a client would walk away over a two-week timeline for full automation.

Should I use it myself before selling it?

Yes, when you can. With a new version of my newsletter software, I said plainly I wasn't even using it myself yet. I wanted to run my own newsletters on it first, because I don't want anyone to buy it if it's not good.

  • Give it to a few people free first, because even if it works for you, other people do things differently.
  • If they're happy after a couple of weeks, open it up.
  • Early customers get a cheap deal in return for a review, knowing it won't be perfect and working with you on fixes.

Should the first version be self-serve?

Usually not. Sell the capability as a managed service first and productize once the interface is solid. With greetform I was afraid to charge for it as software because the backend settings and setup were hard for outsiders. So I offered it as a service: I tell Codex, in plain language, which questions I want, in what order and with what conditional logic, and it builds the survey.

A productized service sits in between. You already have the bones, so you take the 90% that doesn't need to be custom and work with the client on the last 10%. It costs more than signing up for a SaaS and figuring it out yourself, but it's much more tailored. I think a lot of the world is going that way. More in self-serve or high-touch.

What does an MVP cost, and how do I fund it?

Expect scope to grow. An outside dev team quoted me $4,500 for a newsletter production tool. Then I kept adding pieces as I used it, and I ended up around $9,000. I designed it myself in v0 and handed them the design. What I valued was a developer with an enterprise-software background, not just someone who can vibe code something that works for a while.

AI has changed that math since. Nick from Oakville Digest told me on my podcast he built his own ad operating system with Claude Code in about 20 hours, with client portals, reminder emails and reporting dashboards.

On funding, one idea I've considered instead of raising money: pre-sell 20 or 30 lifetime deals at around $2,000 each. Software alone wouldn't sell that way, so the deal would include quarterly consulting calls and a private channel with me. That money funds the build.

How good does version one have to be?

Moving fast isn't the same as sloppy work. A first version should ship quickly without obvious errors, broken layouts or wrong images. My working scale: below 7 out of 10 is unacceptable, 7 is minimum competent, 8 to 9 is expected.

For the launch side of this, see should I launch before I have a full plan.

Answered by TJ Larkin. From Local Media HQ podcast conversations, team and partner calls and my own notes, 2025-2026. Last updated .

Related answers

TJ Larkin / Answers / AI as a business