Few misc thoughts here:
- Lawyers want this all to work in Word.docx
- Many [ / most? ] law firms have a large, overly-complicated "doc database." These have Word plugins, and they're usually required to 'check-in' each version they prepare prior to sending out. This seems like a very natural point of attack for a dramatically superior git-esque solution.
- Most lawyers / firms have a massive distrust of cloud-hosted tools. I've heard "well, Google can read everything in Google Docs!" more times than I can count. Maybe the public is better educated now, but... maybe don't count on that.
- Toolset for bundling up *ALL* edits compiled by one side, having these "merged" and some sort of formal "approved to send" step would be huge.
- Please continue to track which person made every edit, when, and ideally, if said edit was "merged" and "approved to send" to counter-party.
- Over-invest in super easy UX & eye-candy: you're trying to overcome engrained use of a tool that's about as ubiquitous as the air we breath -- you're going to have to deliver 10x value, and ease-of-use will be critical for adoption. The current demo, and dragging links between boxes.... well, imho, perhaps not quite there yet.
- Finally, I've worked inside MSFT publishing docs & books, worked on hundreds of contracts in biz-dev & corp-dev & investment banking, and please let met state very clearly the need for this product is overwhelming. Please please please build this, and wish you all the luck in the world.
PS: Contractual.ly was pretty great. Wish it had caught more traction.
You've got some bleeding edge lawyers if they're using Microsoft Word. The legal industry is one of the main reasons that WordPerfect continues to exist.
If equity is going to be a material component of compensation, then the argument "you're not committed enough, you deserve nothing if you leave..." is utter nonsense.
Imho, many/most of these draconian equity / option terms are nothing more than attempts at 'golden handcuffs' to make it more challenging for employees to leave these startups.
Sadly, they work: I know many who couldn't leave roles til they'd saved up for years, or could finally ink second mortgage on their home, etc in order to purchase all their equity in their 90 day post-exit windows....
https://www.rubykoans.com/
Last time I looked they hadn't been updated in a while, so may not have support for the very latest & greatest features of rubylang, but find this a great approach to quickly familiarizing with 'core' ruby. Hope you enjoy.
Great article exploring specific colormaps and applications, incl discussion of pros/cons of popular maps [ e.g. Cividis better for color-blind viewing than Viridis, but is a more simplistic blue--yellow scale than others which utilize higher number of colors ]:
https://www.kennethmoreland.com/color-advice/
"The old Apple laptop would sound like a VAX in a hurricane while building Emacs!"
Sysadmin to a VAX farm in an earlier life -- this brought back some good memories, especially of what our server room sounded like when we pushed a new build... Thanks for that.
Hi Andy,
Former founder, now investment banker here.
Sorry to hear you're not interested in continuing the business moving forward. Btw, if you really want to sell, probably best to work on this answer [ e.g. I love other things > i hate this ].
My quick take:
- $2500/mo MRR in ~6mo is nice validation of the opportunity. A natural question would be "are you interested in pursuing this as an actual business, and becoming a startup founder?" You should expect this question from any & every potential acquirer. Btw, I'd coach you that "i don't love this space" isn't best answer; try "i find this super interesting, but I love XYZ and that's where my heart is..." Follow-up question: would you join us as a developer on this for 12 months?"
- You'll be viewed as "side hustle," not pre-seed startup. By that i mean to say you're level of 'completeness' and value will be categorized this way. This will make it challenging for a buyer to consider you an 'acqui-hire' level target, e.g. the old adage "$1M / developer" type acqui-hire valuation some co's use for buying teams.
- I think you're most likely acquirers will be influencer marketplace and/or related mktg / agency / services firms [ e.g. Hypr, Traacker, similar ]. They're the independent alternatives to TikTok, Snap, whomever's own features in this area.
- Scraping will be considered a fundamental risk, e.g. "does your current usage fully abide TikTok Terms of Use?" Do they offer an API? If so, why aren't you using it? How at risk is your scraping of being cut off by TT in the future? Have you spoken with a TT biz dev person about this? See 'ckdarby' comment on friend's Insta business getting C&D ltr from FB legal; very hard for you to be acquired if you have any of this risk.
- Valuation: you're super early stage; sorry, i'm not super familiar with valuation around side-hustle projects so I'd google this a bit to see if there are nice precedent / comparables.
- Classic mba style valuation rules-of-thumb, for later stage / at scale businesses: 6.5-7.5x EBITDA. Fairly standard business school valuation rule-of-thumb, e.g. if you were at scale business being considered by private equity buyers they'd start their valuation & waterfall model around here.
Finally, congratulations -- this is a fantastic side-hustle. You may be able to find a way to get a deal closed, especially if you're willing to go with the code-base to help it land, migrate off scraping to API, etc.
Not sure I totally get your point about my reason for selling. Are you saying I should or shouldn't say my heart's not in it? That's the genuine reason and I've always built in the open and been transparent about my business/ goals.
My primary motivation now is starting another SaaS project like this one, but in a niche that I'm more interested in. At the moment I think that's B2B lead gen or SEO.
Obviously very different beasts to this - mature industries etc but things I've developed an interest in by doing this more opportunist project. So I'm 100% not looking for an acquire-hire!
Happy to be viewed as a side hustle. That's basically what it has been until very recently.
Yes, those are the main people I'm speaking to at the moment. Also Indie Hacker types.
Agree, if it wasn't for the fact it relies on scraping this thing would be worth 5 x much as I've suggested in the doc. I'd say this is very hard to value, even looking at historical multiples on Flippa etc.
"Not sure I totally get your point about my reason for selling. Are you saying I should or shouldn't say my heart's not in it? That's the genuine reason and I've always built in the open and been transparent about my business/ goals."
=> Just phrasing. Say you love something else more than this; saying you don't want to do it has negative connotations. Again, just semantics, but they can seriously influence likelihood of deal & valuation...
From 1995 to 2002 I led biz dev for DataChannel's XML parser [ the first written, most widely licensed to other platforms eg MSFT, and likely most widely adopted ]. I coordinated our participation in XML & all the related web services standards bodies.
We got to participate in a lot of amazing projects, whether relatively simple open standards for DTDs that made it easy to interchange crisply [ eg MathML, many others ], or for industries with considerable interchange challenges [ eg SWIFT ]. These projects were typically fairly lightweight, and fortunately many simply 'worked' and succeeded. In this capacity XML seemed to "just work" and seemed to make the world a better place -- "victory!"
Of course you can't really discuss XML without discussing "Web Services," which is what many consider the "xml ecosystem."
Around 1996 Norbert Mikula, Mike Dierken, John Tigue, myself and probably a few other characters began riffing on various ideas of how XML + HTTP could be used. What if you could simply lookup a signed DTD for how your data was suppose to be delivered to you? Lookup a signed DTD for how to invoke its API / RPC calls? Hell, why not have a DNS-like directory of what services are available, whether on your intranet, or from vendors? That's where the original 'whitepages / yellowpages / greenpages' naming convention in the very earliest days of web services came from btw. Naive? Over-optimistic? Absolutely... But we didn't know any better, so why not. We started discussing it with lots of smart people in SGML and XML space, the concepts started turning into prototypes and it started to build momentum.
People who were interested fairly wisely said "a standards body should lead this stuff [ instead of some vendor ]," so the early work landed inside OASIS [ the original SGML standards gangsters ]. Their wisdom gleened from long years building incredibly complex SGML doc systems spared the early XML services from many potential debacles btw. Momentum began to build, and super interesting things started being built.
As Fortune500 IT, startups, middleware vendors and app servers became increasingly interested in tapping in this magic a very interesting dynamic changed: the platform players perceived all this interop, open standards as a serious competitive threat.
Microsoft and IBM in particular got very involved very quickly, and the once simple & elegant concepts quickly devolved into multiple competing standards that were a horrible, illogical, impractical mess. This happened in less than two years... Open-standards based web services essentially became an irrational choice vs just "staying with your existing vendor's stack..."
That glimmer of amazing potential magic was quickly and effectively killed. Am I saying XML & web services were perfect? of course not. I am saying a thread of amazing potential was pulled, then around 1999 it was cut. And it was sad to see first hand.
I hope GraphQL, JSON, the incredible variety of cloud services and other interesting bits tap into that same magic.
Blockchain... imho interesting, but I fail to see many use cases where business side buyers [ aka budgets ] must have a blockchain-based solution. Looks like tech still searching for need and product/mrkt fit to me... think long-term it offers many areas an interesting evolutionary step, but I don't see it as hugely revolutionary gamechanging stuff.
I've been using Bitwarden a couple months now and can only speak highly. We'll see how it's security audits & stands the test of time, but so far so good for me.
- Many [ / most? ] law firms have a large, overly-complicated "doc database." These have Word plugins, and they're usually required to 'check-in' each version they prepare prior to sending out. This seems like a very natural point of attack for a dramatically superior git-esque solution.
- Most lawyers / firms have a massive distrust of cloud-hosted tools. I've heard "well, Google can read everything in Google Docs!" more times than I can count. Maybe the public is better educated now, but... maybe don't count on that.
- Toolset for bundling up *ALL* edits compiled by one side, having these "merged" and some sort of formal "approved to send" step would be huge.
- Please continue to track which person made every edit, when, and ideally, if said edit was "merged" and "approved to send" to counter-party.
- Over-invest in super easy UX & eye-candy: you're trying to overcome engrained use of a tool that's about as ubiquitous as the air we breath -- you're going to have to deliver 10x value, and ease-of-use will be critical for adoption. The current demo, and dragging links between boxes.... well, imho, perhaps not quite there yet.
- Finally, I've worked inside MSFT publishing docs & books, worked on hundreds of contracts in biz-dev & corp-dev & investment banking, and please let met state very clearly the need for this product is overwhelming. Please please please build this, and wish you all the luck in the world.
PS: Contractual.ly was pretty great. Wish it had caught more traction.
Happy hunting!
reply