> I'd do some research into the wide variety of software that hospitals and health care facilities use and then look into the channels they are purchased through

I've done a little of this, and it's surprisingly difficult. :)

> Follow the chain back to the devs and it is likely that one of those intermediate businesses would be interesting to talk to as a VAR candidate.

Hmm, this is an interesting idea. I bet systems like EPIC have use third-party subcomponents. It's quite likely that it would be less expensive for them to use my product than maintain their own. (If indeed it's an in-house effort.)

> For inbound marketing, your web site and standard SEO practices should suffice.

I'm already #1 on Google for most of the common search terms, using an anonymous browsing window. So I could do more of that, but I think partnerships is where the actual money is. I think selling to individuals will basically be small potatoes by comparison.

> focus on the ones that are 2-5 times larger than your largest to date.

Good idea. I have quite a few friends from pharmacy school that work for large pharmaceutical companies, and we're all old enough now that a lot of them have purchasing power. :)

> Be sure your VAR agreements give you solid protection and a clear way to terminate

Another thing to learn about.

> Figure out what it would cost for them to make it themselves or have someone else to make it for them. If they do a lot of business with you, at some point, a VP or GM is going to look at the amount they are paying you and say 'why are we paying so much for this, we should build it ourselves and reduce cost'. For example, if your feature took you 1 man-year to develop and a customer is buying 20,000 license/year, they are paying $100,000/year. They may figure they can pay someone to build it for them for $100,000 and see an ROI beginning in only one year.

This would be hard, because health care changes all the time and new words are quite literally invented daily. I have largely automated the ingestion and filtration of new words, but it does take a few hours of effort every week to keep on top of it. (At the end of the day, a human has to determine what's real and what isn't. There's a surprising number of typos and misspellings in peer-reviewed journals.) So it's not necessarily a set-and-forget, but the data gathering, normalization, and sorting basically is. It would make virtually no sense for even a very large company to develop this internally. In fact, most large companies don't pay for spell check software at all. (C.f.: lots of misspellings in peer-reviewed articles.) But there is a market for it. An EMR company was the first to contact me; I suspect they don't have existing solutions, because the alternatives are $60/seat and up.

I WAS thinking about an unlimited site license. Say you're an EMR company, and you have 300,000 licensed installations... you pay me I dunno $50K/yr max, and you can integrate it into as many instances of your software as you want. Exact figures would need to be thought about more.

> If there is a low barrier to entry, be alert for competitors. Bank a portion of the revenue. Be receptive to exiting.

I've thought about the exit angle. I would consider offers. But this is actually just a hobby. I have no intentions of quitting my day job anytime soon, because this project is so low effort. I wrote software to automate most of the annoying bits, and I wrote more software to make the annoying-but-cant-be-automated bits less annoying.