cleverfoo

I run a small business (scanii.com) and I've noticed over the past year an increasing number of customers leaving us to European competitors, customers that have been happy with us for years, using our European region, but now have concerns over US foreign policy and are giving preferred treatment to EU suppliers. When I asked they said, I'm paraphrasing here, "happy with the product but management wants EU supplier".

What this means in practical terms is that, if the tide doesn't change, US entrepreneurs will have a potential buyer population that is roughly cut in half if they can only sell to US buyers. This will have a cascading negative effect in the number of startups that succeed - impossible to quantify at this point.

Large corps can skirt around this issue by establishing an EU entity and trying to buy goodwill that way but that's not an option easily available to small businesses.

I fear rough waters ahead.

It's hard, and some might argue impossible, to statically analyze reachability in a dynamic language like java that allows for runtime class loading and redefinition. As it turns out, Java is much closer to javascript than C++ in terms of dynamic runtime behavior.

With PGO you do a lot of deliberate work to profile your application under different conditions and feed that information back to the compiler to make better branch/inlining decisions. With a AOT cache, you do nothing up front, and the JVM should just dump a big cache to disk every time it exits just in case it gets stared again on the same host. In this case, training runs would just be a” run you did to create the cache". With that said, the big technical challenge right ow is that building the AOT cache is expensive hence performance impacting and cannot really be done alongside a live application - but that’s where I think the focus should be, making filling the aot cache something less intensive and automatic.

Another aspect this strategy would help with is “what to do with these big AOT cache files”, if the AOT cache really starts caching every compiled method, it will become essentially another so file possibly of a size greater than the original JAR it started off with. Keeping this is in a docker image will double the size of the image slowing down deployments. Alternatively, with the aot cache concept, you just need to ensure there is some form of persistent disk cache across your hosts. The same logic also significantly helps CLIs, where I dont’ want to ship a 100MB CLI + Jlink bundle and have to add another 50MB of aot cache in it - what I do want is every time the client uses my CLI the JVM keeps improving the AOT cache.

Best of luck with your launch!

That is very kind of you, thank you.

> What did "getting it out there" consist of for you? How did you get it out there in the beginning?

For Scanii in particular, the original product was a thin wrapper around an open source AV engine, a hacked on a weekend UX, and a credit card processing integration to collect payment - the very minimal needed to find out if _anyone_ was willing to pay for this service.

With that said, what worked for me in this case is not what I would focus here since it depends on what kind of business you are trying to build. What I do believe is important is focusing on the economics of your space which, for IT, is all about productivity or, more succinctly, saving people's time - they pay you X for something that could cost them, in terms of people's time, Y to do.

So, what you want to ask yourself is whether signing up, paying and onboarding onto your product (the X in the equation above) is significantly lower than the next best alternative, either doing the same on a competitor product or building something themselves - the Y above.

For scanii, even at launch it saved people lots of time managing and operating malware detection engines which are cumbersome and hard to keep up to date. I had a feeling that would be the case when I launched but I couldn't be sure until our first customer voted with their credit card.