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

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 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 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 the first version be self-serve?

Usually not. Sell the capability as a managed service first and productize once the interface is solid. More in self-serve or high-touch.

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.