Nail & hammer + this meme...

I've owned cpq3D.com for years, and recently added tasktagger.com to that list, so it's about time to start materialising these.
My bet is that - in this market- you need to be a system of record to become a painkiller (vs vitamin).
That then should earn you the right to upsell other things...

I've been exploring related tracks recently, and would like to make PLG the second option for 2025 for the bottom market (first one is componentization for mid-size), by "earning the right to upsell" via related use cases.

I think we need a good catalyst, like widely spread AR glasses (snap spectacles maybe?) or similar for it to become a consumer given.
Once the consumer expects it, everything else will be a walk in the park.

I loved your previous post and this one. I target mostly just below enterprise, and it tends to be quite challenging for marketing/sales IME.The value prop might seem obvious to us, but it sure isn't common knowledge.
AFAIK we still haven't crossed the chasm, and I'm wondering if we'll ever will.

I prefer one language for both front -and back-end. As my main thing is online 3D configurators (written in typescript), I prefer this over .net.
I love .net but I don't think it covers my use case in the best way possible.

I'm also open to considering headless CMS or open source CRMs like twenty etc... However, those are big dependencies, so they might hurt longtime, which is why I'm not exactly jumping into one of those...

This should probably be in your SOP

Or when there's no-one willing to pay for maintenance/updates

It's only one js file, we got you covered. I'm however considering whether we should inject things at runtime or package then up in one big behemoth (which can be built on demand if necessary)

I see 3 potential use cases
1/ A js script included in the header that allows you to edit and place 3D overlays on any image
2/ A web component that behaves like a normal div, but contains a 3D overlay
3/ A series of react components that you can use directly

We can build it from the bottom up.

Another one is regarding (shared) dependencies...
One of the things we are considering is having a provider component to inject the dependencies, but I'm wondering if we're not reinventing the wheel here.

<vsl-provider tenant="abc" storage="xyz">
<vsl-configurator model="uvw" />
</vsl-provider>

Wouldn't it make more sense to use NIFs instead?

Dikken, ge doet er mij aan denken dat ik nog moet ontbijten... Begint goed te lukken precies!

Fyi saving in a folder doesn't seem to work on mobile

Apparently I refined it by asking 17 times for more stuff or changes...

I had a few reboots, but the initial prompt of the current version is:
write me a small client-side react progressive web app that allows me to take pictures and allows use to browse and save these in the origin private file system. Don't use any external dependencies and don't use a service worker

I've added geolocation functionality too: you can turn it on/off if your device supports it, and it stores the location in the file name.
You can also click the little red pin on the photo to go to the location in Google maps

And... Done
Link is the same: pages.virtualsaleslab.com/tools/camera...
It identifies duplicates by filename...