#buildinpublic #robwalling #startsmallstaysmall #saasplaybook
Hello all,
I am looking for some advice on how to proceed with my early SaaS idea validations. Being my first time SaaS side gig, here is my basic question:
Should I continue validating my ambitious, likely enterprise-level idea or try to go back to basics and find a smaller audience size?
I was inspired by an article to start sending cold emails:
https://www.indiehackers.com/post/no-audience-no-list-no-seo-no-problem-8c1d461b43?commentId=-Nb0paQJ4cA4bUfDZKfR
My goal was this:
I'm currently in Week 3 after sending 22 cold emails or invites to LinkedIn to try to connect with people. Some are former colleagues that moved to different companies, some are LinkedIn folks that are in the "Risk" business area for a company.
My idea is around record retention, and here is my initial contact email:
Would you be up for giving me your thoughts on an idea I'm exploring? It's aimed at companies looking to better manage and organize data retention policies by simplifying, reporting on, and reducing time spent by risk, compliance and engineering teams to enforce retention rules.
The reason I started this idea is at my current employer, I often work with Risk Engineers and Risk Managers that don't have a solution to properly manage databases, teams impacted by database changes/cleanup, and whether databases are actually being cleaned up in a timely fashion. I spoke with one of the head Risk Manager, and his overall response was "we absolutely need this". Unfortunately that's the only "hit" so far (still validating).
The part I'm struggling with is determining at what point should I start building vs continue validating vs pivot to a different idea with an easier sales cycle. Since the nature of record retention requires a customer with a combination of longevity, size or a risk team, I see the primary customers would be larger companies with a longer sales cycle.
I'd be happy to build the tool for the aforementioned Risk Manager, but being a software builder myself, I fear I'm biting off a bit too much being my first time on the validating/marketing/sales side of the coin.
Any advice on whether I should proceed with validating and working through the pre-sales effort to pursue and validate this idea?
Thank you,
Ask yourself this ... what do you want to sell in a few and simple words ? and what is the value added to the client ? then make a landed page and see how it goes. :)
Pedro
Thanks Pedro for the read and reply.
*Properly managing your record retention without developers"
I think this needs some tweaking but after talking with my company's Risk Manager, the hardest struggle for their risk team is getting the engineering teams involved in the effort.
Aside from initial configuration/connection to the database, the development teams would have a low/no touch for the Risk team to report and execute data cleanup as per the record retention policies.
For context, here is my full pitch:
*****
# Idea
Cross-Team Data Retention Management Software (tentatively called Purgo)
# The Problem
Various groups play a role in complying with data retention policies and following through with cleanup:
Software engineers are critical in the implementation, execution and maintenance of the scripts, but unfortunately they have the least incentive (relative to other work) to actually implement these non-functional data retention policies. Many times the data won't be purged for 10 years or more in the future and tend to deprioritize the effort needed to implement data cleanup when new software and databases are released.
# Benefits
For a monthly fee, Purgo decreases engagement needed from the software teams to implement and maintain data retention rules, offers cross-team visibility for shared databases, and provides reporting dashboards on which databases are adhering to their respective policies. Secondarily, the programmatic cleanup of unused data should ultimately allow the decrease of storage costs for databases especially as data moves to the cloud. Here are the core phases to manage the data cleanup process:
Phase 1: Register databases/tables, control columns (PK & Last Updated), and which team(s) own/utilize the tables
Phase 2: Apply retention policies
Phase 3: Schedule cleanup
Phase 4: Report database health and levels of compliance
By having a standard, repeatable process for data cleanup, the software teams are only required for initial connection setup and basic testing that the cleanup process is functioning as expected.
# Price
Plans start at $99/month and will scale up as more databases are managed by Purgo.
That's the idea....would you pay for it?
Thanks for taking the time to read through this. Again, even if you only have time to answer with a yes or no, it will be a big help.
*****
Ask yoursef if it pays off to clean out/to purge the trash that teams make when doing software projects ?
People pay to remove toxic waste, nuclear waste, normal waste (i think it's included in some bill they sent us), but cleanning "bits and bytes" waste i think is a thing open for debate. When you go to the toilet you just have to press a button and everything goes away ... maybe that's an idea to clean software project trash. :)
A decrease of storage costs ? how much does a software project takes in terms of storage ?
And will they let you apply your "purginator" to their precious and confidential software project ? Maybe to the non-confidential parts ?
Pedro
@PedroMartins - good questions to consider; some I've already considered which could prevent certain technical features to be useful.
The particular audience I'm targeting are records retention related to regulations, in the one case related to commissions data needing to be purged if it's 10 years old. There are other categories of data so my idea is more about compliance than "trash" data to clean up.
There is the aspect of decreasing storage costs which I would need to do some additional research to say "if X amount of records are cleaned up" or "the database would cost X with an average Y amount of records", how does that translate into optimizing the size of databases. Part of my pitch talks about the "data engineering" side of if where cloud costs are correlated to size of the database, however cost savings are less direct/obvious for self-hosted database.
Regarding connecting to their "precious and confidential data", I have thought about this one extensively. Some options I thought might help mitigate the risk that my software couldn't connect to the data sources, or worse the customer decides not to use my software for this reason:
"I could deploy it within their servers and databases ..." do you know what this implicates ? your are going to mess with their servers and databases ... do you think they will let you ? :)
Pedro
@PedroMartins - I see how you interpreted that, sorry I wasn't clear.
I would created a distributed version of my software that each customer could deploy within their ecosystem (e.g. their AWS account). It would still be a standalone webapp with its own database to store app specific data. Being deployed within their ecosystem, I believe customers would be open to allowing the webapp access to read from other databases that have the cleanup needs. At least compared to a central webapp that I control, outside their firewall, app ecosystem, etc.