> 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.
HttpResponseMessages also implement IDisposable, and should be disposed. HttpContent also implements IDisposable, but disposing of the parent HttpResponseMessage also disposes of the child HttpContent object as step 1, so you needn't have a second using statement.
In a typical usage scenario in an async Task, this is what it'd look like:
using (var response = await _httpClient.GetAsync(requestUri))
{
response.EnsureSuccessStatusCode();
var result = await response.Content.ReadAsStringAsync();
return JsonConvert.DeserializeObject<Foo>(result);
}
- Ability to specify WHERE to cache files. This matters, because I have drives for data on my workstations, and partitions for data that're reachable in an OS-agnostic way on my laptop. I doubt I'm the only one who wants to cache music on a drive other than the SSD system drive.
- The titlebar always says Spotify Premium (or Spotify Free). Because that's super useful to people.</s>
I can confidently say a few things about working at a big company:
- I have created whole products from scratch by myself with my tech lead doing code reviews
- I have worked on "legacy" code as well
I find both satisfying for different reasons. Legacy code has a bad rep, but "legacy code" should really be called "valuable code", because it has already demonstrated its market value. It has nothing to prove. I've learned things from reading legacy code: little stuff like language features, and bigger stuff like architectural tips.
Both are different, both can be rewarding. Greenfield isn't synonymous with better or more fun. I personally enjoy being the commando[1] (with infantry tendencies as well), but the other stuff can be good, too, and we each have different preferences. That said, being the "commando" can be exhausting, and I wouldn't want to do it all the time.
> we are talking about those people who are willing to trade off security for a chance of building something great
I object to your phrasing (though not your thesis), because it's the type of phrasing used for other forms of hero worship: police, firefighters, military personnel, etc. It's the kind of wording used by star-struck wannabes, to be frank.
I also object to your use of "great", because I think that--with few exceptions--most startups aren't working on stuff that'll make the world a better place. Most startups work on stuff that'll get funded; that means you see lots of largely similar companies in startupland. (I suspect a contributing factor is also the relative lack of life experience of a lot of these founders: they simply haven't seen enough of the world to be more imaginative[1].) And that generally isn't stuff that will make the world better, because those kinds of problems are hard, and often require lots of financial and non-financial capital to work, even if at the end of the day, there's a lot of money to be made for the players that are successful.
> Not everyone is suited for this sort of thing
Normative phrasing aside, there're equally-valid alternative explanations: not everyone believes they are a beautiful and unique snowflake. Or, gambling is more fun when done at a casino. :)
[1] You alluded to a phenomenon in your other comment, about younger people not knowing how to tackle a problem they might encounter if they worked for a big company. I suspect that's more a function of lack of experience in that they couldn't even imagine the problem unless they'd worked in an environment where it would arise. I suspect this is why you see relatively few enterprise-y, B2B startups, despite the untapped goldmines in that space.
> Some people might do better (even financially) staying at more stable companies.
I would venture to say that MOST people will do better financially if they stay at a large, established company. A new grad might think their 0.05% equity stake will make them rich, but most startups fail, and even the ones that don't are rarely homeruns. Established companies with deep pockets often pay better, and grant their employees RSUs. RSUs are much easier to cash out if the company is publicly traded.
I was recently granted a non-trivial pile of RSUs. Enough for a down-payment on a house in the Boston area. That's better than I'm going to do with 99% of startups, and my salary is reflective of a mature company with deep pockets. (Another thing startups often lack.) In many ways it's the best of both worlds. And if I leave? It'll be for another large company (Google, Apple, Facebook, etc.) that'll make me whole for anything I leave unvested on the table. Good luck with that at a startup--liquidity matters.
I'm not alone -- I have friends at Apple and Google. Their RSUs vesting layers are crazy. For one friend, it's 70% of his gross salary, and he's not what we would call "senior management". He'd be stupid to join a startup.
An object can be a value object, and it can be immutable. Or not. (Though I can't think of a reason a value object should ever be mutable once it's created; it would be a very pungent code smell.)
These are orthogonal ideas; not contradictory ones.
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.