I was sent a cold email the other day offering an MVP in eight weeks with one of their professional software engineers.
If you run a service business (insurance included) with any kind of proprietary process, consulting, coaching, agency work, specialized billing, it’s only a matter of time before someone pitches you on “productizing” what you do.
The email usually sounds something like this:
” We’ll put a senior engineer on it, build your MVP in eight weeks, and you’ll have recurring revenue compounding from day one. “
It’s a compelling pitch. And the core idea isn’t wrong. Turning a service into software can be transformative. But between the vision and reality, there’s a minefield of questions most service business owners never think of asking.
Let’s walk through them.
Your Methodology Is Your Moat. Who’s Guarding It?
The thing that makes your business valuable is what you know and how you apply it.
The moment you hand that methodology to a development team, you’re codifying your competitive advantage and placing it in someone else’s hands.
Ask yourself:
- Who owns the code when the project is done?
- What about the algorithms, the decision logic, and any AI models trained on your processes?
- If the relationship ends, do you walk away with everything?
- Or does the developer retain rights to the underlying framework?
Get this in writing before a single line of code is written.
Not in a handshake.
Not in a Slack message.
In a signed agreement reviewed by your attorney.
Where Does Your Data Live—and Who Can Touch It?
If your business handles client information, especially anything in healthcare, legal, or financial services—data storage isn’t a technical footnote.
It’s a liability question.
You need clear answers on:
- Where the servers are physically located
- Whether data is encrypted both in transit and at rest
- Who has access to it on the development side
If you’re in a regulated industry, you also need to know whether the infrastructure meets compliance requirements like HIPAA, SOC 2, or whatever applies to your space.
“We use AWS” is not a sufficient answer.
Plenty of platforms run on AWS and still have terrible security practices. You need specifics about access controls, audit logs, backup protocols, and breach notification procedures.
Security Isn’t a Feature. It’s a Foundation.
An MVP built in eight weeks can be impressive. It can also be a security disaster.
Speed and security often work against each other in early-stage development, and if your development partner is optimizing for a fast demo, security may be the first thing that gets deprioritized.
Before you launch anything, even to your existing clients—ask:
- Has the platform has undergone any kind of security audit or penetration testing?
- How user authentication works?
- How sessions are managed?
- What happens if someone gains unauthorized access to the system?
If the developer brushes off these questions or tells you “we’ll handle that later,” that’s a red flag. In software, “later” often means “after the breach.”
Can One Engineer Actually Build This?
Many of these pitches center on placing a single “senior engineer” with you. That person may be genuinely talented. But building production software is not a one-person job.
A real platform needs:
- Frontend development
- Backend architecture
- Database design
- Infrastructure and DevOps
- QA testing
- Security review
One person might be able to prototype something that looks good in a demo. But a prototype is not a product.
Ask who else is involved.
Is there a designer?
A QA engineer?
Someone responsible for infrastructure?
If the answer is that one person handles all of it, you should understand what you’re getting: a proof of concept, not a production-ready platform.
What Happens After the MVP?
This is the question that separates a real technology partner from a project shop. Software is never finished.
After launch, you’ll need:
- Bug fixes
- Feature updates
- Security patches
- Infrastructure scaling
- Someone to answer the phone when things break at 2 AM
Before you sign anything, get clarity on:
- What does the ongoing cost structure look like?
- What does maintenance run monthly or annually?
- What’s the hourly rate for new feature development?
- What’s the response time for critical issues?
If the pitch focuses entirely on the build phase and glosses over what comes after, you’re looking at a project that will be expensive to maintain with a different team—one that has to reverse-engineer everything the first developer built.
“AI Built on Your Methodology”… What Does That Actually Mean?
AI is the magic word in every sales pitch right now. But when someone says they’ll build AI into your platform, you deserve to know exactly what that means.
Are they talking about:
- Simple automation and decision trees?
- Document generation with templates?
- A large language model fine-tuned on your data?
Each of these is a wildly different level of complexity, cost, and risk. If they’re training models on your proprietary data, you need to understand who owns that model, whether your data could be used to train other models, and what happens to it if you part ways
“AI” without specifics is marketing, not a technical plan.
The Recurring Revenue Math Needs a Reality Check
The pitch often includes a tidy revenue projection. Fifty providers at $299 to $599 a month. That’s $15,000 to $30,000 in monthly recurring revenue. Sounds great on a slide.
But that number assumes:
- Clients will pay for software access on top of whatever they’re already paying you for services.
- The software delivers enough standalone value to justify a monthly subscription.
- You can support a user base without a dedicated support team. Churn will be low enough to make the economics work.
None of those assumptions are guaranteed.
Before you get excited about the revenue model, pressure-test it with your actual clients.
Would they pay for this?
What would make them cancel after month two?
The Bottom Line
Turning a service business into a software platform can absolutely work. Some of the most successful SaaS companies started exactly this way—someone with deep domain expertise decided to productize it.
But the gap between a cold email promising an MVP in eight weeks and a real, secure, scalable product is enormous.
If someone approaches you with this pitch, don’t say no.
But don’t say yes, either.
Say “answer these questions in writing first.”
Those who can clearly, specifically, and without deflecting answer your questions might be worth your time. The ones who can’t just told you everything you need to know.
