Hacker News Reader

Subscription fee, with scan limit for something that works entirely on-device and with barcodes that likely will not change for years feels weird.

Even weirder as I understand from other comments, that scan will fail without internet entirely due to licensing server being unreachable. Strong always-online single-player games vibe.

Hey there, I understand where you're coming from.

Monetizing these types of libraries based on performed transactions or active devices is pretty standard.

The internet connection is only required for the license check which occurs at initialization time, typically once per application session (in case of an SPA). One thing to consider is that with web apps, an internet connection is kind of a requirement anyway - with completely offline-capable PWAs being the exception. Typical barcode scanning apps will want to report or look up data associated with a scanned code from an API backend.

And yeah, I'm annoyed too when I'm stuck in a login queue when I want to play Diablo 4 in single-player mode.

Industrial apps are often served from a private network with no access to the internet - I understand if you don't want to target that sector, but it is a real use case.

My hope is that these customers will opt for the Enterprise license which works completely offline. But hey, finding product-market fit is hard. :-) Thanks for your input!

How much does the enterprise license cost?

Happy to send you the Enterprise license factsheet, please send an email to the address listed on the site.

Looks like they do support that at their "enterprise" licensing tier

One that drives sales in the retail sector. “Do I have to be online in order to accept scans/payments/etc?”. If I’m a small business owner and want to scan my stock, I have to pay for the privilege, when my USB scanner works without internet and costs me $160. I really don’t think this will fly at the price/subscription they are selling it for. Especially when there’s cheaper/free options available. [1]

[1] https://github.com/maslick/koder

I guess I will find out. :-)

> Monetizing these types of libraries based on performed transactions or active devices is pretty standard.

Honestly I haven't seen it much. Yearly support/update fee of course, but this is new, very sad trend.

Meh. I agree that there are a bunch of reasons this won't appeal to many but if this was as reliable as it claims to be and I had a business reason to use it I'd gladly pay the money just to get that functionality off my plate. It could be easily justifiable if customer conversions required a barcode scan. Easier scanning = more $$$.

Online-only isn't ideal but I'd imagine the vast majority of use cases here are going to be always-online anyway (what are you going to do with the barcode value if not send it somewhere?)

> vast majority of use cases here are going to be always-online anyway (what are you going to do with the barcode value if not send it somewhere?)

Developers need to understand that connected to a network != path to the internet.

The developers site isn't even accessible from China: http://www.chinafirewalltest.com/?siteurl=strich.io

> Developers need to understand that connected to a network != path to the internet.

Developers need to understand that "vast majority" does not mean "all" and that if you're using an internal network you'd want an enterprise license, which allows for fully offline capabilities.

I get that it's annoying but I don't see a whole lot of other options if you're pricing per scan.

Well, there's option of not pricing per scan, when scan doesn't generate ongoing cost for library developer.

That's something we need to understand as customers, unless we want more ideas like subscription-based seat heating in cars, just because it's normalized behavior.

> Well, there's option of not pricing per scan, when scan doesn't generate ongoing cost for library developer.

Which, again, is offered!

(the actual issue here isn't per scan pricing, it's that the web makes it very difficult to stop someone grabbing a library from site X to use it on site Y. One of few methods to do so is to use a license key which has to be validated)

I like to imagine this as the result of some BMW pm’s misunderstanding of the term per seat pricing.

Sure, I would pay for it. But I would prefer to pay a one time fee for a perpetual license. And then I could opt to pay additional fees to access updates.

It looks like you just need to generate a JWT with the 'offline' and 'analyticsOptOut' capabilities set and patch 'prodPubKey' with the signing key you use.

(Obviously you should pay for the product, but fuck anyone who builds a product that works entirely offline except for a license check)

Nice! So if this 3rd party server goes offline it takes down your operation. I hope it's not very important.

Nice project, but BarcodeDector API [0] will probably soon land in browser, and in the meantime there are wasm-based polyfills [1] that I've successfully tested myself for QR codes which work in-browser and offline.

In-browser webcam demo from the polyfill author: [2]

Making this a paid-per-scan and online-required library will have a hard time IMHO.

[0]: https://caniuse.com/mdn-api_barcodedetector

[1]: https://github.com/undecaf/barcode-detector-polyfill#readme

[2]: https://codepen.io/undecaf/pen/LYzXXzg

Hey, the BarcodeDetector API has been around for some time, just crucially not on iOS. I didn't know about the polyfills though!

If you're looking to only scan QR codes, https://github.com/nimiq/qr-scanner is a library I can recommend and which I've used in a previous project.

One thing the BarcodeDetector API does not give you is a UI for your barcode scanning. Basically it's your job to acquire an image and pass it to the API. With STRICH, you just provide an HTML element and the scanner will live in there, including controls for camera selection and flashlight (only on Android, unfortunately).

Wait, didn't iOS recently introduce torch control? I could have sworn that was in the last few months...

As of latest iOS 17 Beta it is not yet supported, unfortunately.

BarcodeDetector (currently) has pretty poor performance. I'm sure that will eventually be fixed, though. I've had great success with qr-scanner and a web worker, though....

The wasm-based polyfill I posted works great for me, I use a <video> element to continously scan for QR codes (didn't test with other barcodes, but it is supported by the polyfill). Currently sampling 4 times per second (every 250ms) and it feels no different than a native scanner on the same device.

Edit: Just updated my post with the codepen from the polyfill author: https://codepen.io/undecaf/pen/LYzXXzg

It is butter smooth with EAN barcode when using the builtin webcam on my Macbook (720p on a 2019 MBP16)

Nice launch.

I've built software to run a warehouse before and we actually ran everything off a web app that was used both on the desktop and on mobile apps. We used barcodes for everything.

I'll be honest, this isn't a problem we ever had. Barcode reader hardware always seemed cheap, good, and worked as a keyboard as far as web apps were concerned, so integration was trivial. In fact we had more success with those than with camera based options because the hardware and software was simpler.

Where do you see the USP of this vs, say, phones with built-in barcode scanners, hand-held scanners, or finger mounted scanners?

Separately, I see your pricing is based on number of scans. How do you validate this? Do you have a server component? Does that require an internet connection, and do you see that limiting the market at all because of either offline use or rules around depending on external services?

Hey Dan. Thank you for your questions and valuable input!

I agree with you that dedicated barcode reader hardware performs well and can be quite cheap. Did you not find the keyboard-style integration limiting regarding integration in your app, basically having to design your app to accept keystrokes followed by <enter> (I think this is commonly referred to as "keyboard wedge")?

Regarding phones with built-in barcode scanners: I have some experience with Zebra TCx devices, which definitely work well, but they're quite expensive. Many companies, especially smaller ones, use employee devices and have programs that incentivize BYOD, like handing out annual cash payouts if you bring your own phone to work. Also some companies in logistics I've worked with rely on external partners (e.g. bike couriers) where you don't know what kind of device they'll use.

Regarding the pricing: the SDK periodically transmits the number of scans that the device performed to a cloud-hosted API. The license check is also online (https://strich.io/faq.html#faqDataTypes). For customers that require fully offline operation, there is a separate Enterprise license on offer.

> Did you not find the keyboard-style integration limiting regarding integration in your app

We didn't. We were able to use regular <input> fields and handle input in all the ways we already knew how to support well. It had the added benefit that manual testing during development could also be done with the keyboard which meant we didn't need to give engineers any specialised hardware most of the time.

The flexibility also helped when we ran certain processes in the warehouse in different ways. We (engineering) learnt a while after we had put the system into action that sometimes people in the warehouse weren't using a phone with an attached or built-in scanner, but were sometimes using a Chromebook with a scanning gun. They'd use this for various bulk processing, or supervisors would use this because they worked mostly in the non-mobile tools or needed the productivity of a bigger screen and laptop over a phone.

I guess the overall thing here though was that we just never thought about barcode scanning because it never came up as an issue[^1].

> I have some experience with Zebra TCx devices ... but they're quite expensive. Many companies...BYOD... Also some companies ... rely on external partners ... where you don't know what kind of device they'll use.

This is a fair point. We didn't BYOD because these devices were in constant use in a busy warehouse and personal phones wouldn't have cut it in terms of reliability, but for more occasional use I get it. External partners BYOD'ing also makes sense.

I think we had some Zebra TCx devices, or if not something very similar. They were pricey, but for extensive usage at our scale, probably not far off price competitive with your pricing. We also only had a few for a specialised use-case, mostly we used cheaper devices without the built-in scanners, and laptop/desktop hardware when mobility wasn't as important.

> Regarding the pricing...

Good FAQ answers on that one. That's my concerns addressed there! Enterprise pricing for offline support makes sense. Periodic reporting also sounds reasonable.

[^1]: Except... that time someone left a barcode scanner with the trigger depressed on a desk once and because we made an API call on a scan, it brought down the site and database. Thankfully a quick fix and some protections and rate limiting solved it from ever causing an issue again, but a funny issue.

Fair point regarding the benefit of being able to use the on-screen (or external even) keyboard for testing! A lot of apps that do barcode scanning have that as a fallback if the code is unreadable/destroyed.

And I agree that for large warehouses the cost of having a fleet of managed, dedicated devices is amortized pretty quickly.

I have built 3-4 warehouse scanning applications using a range of bluetooth hardware and BYOD and zebra scanners. From my exp, this product misses the mark for 2 reasons. 1) internet access for license checking. Every warehouse I encountered had enough dead zones to warrant offline first. 2) Pricing seems a bit high. Maybe the target demographic is clients with hundreds of scanners, but this solution wouldn't make sense for small-mid size businesses. Zebra scanners will continue to work and scan barcodes 6 years from now. Transparency on "enterprise" costs would be nice. If i had a ballpark for price for maybe device breakpoints, id consider inquiring. But as it stands, i would advocate for hardware products and quickly move on.

Fair enough! Regarding your points I have to disagree:

1) Since the library is meant to be used in a web app, how would the app be accessed without internet access? Also there is an Enterprise license which has completely offline operation, but this has been requested mainly for compliance and IT policy reasons.

2) Knowing what some of my competitors charge I disagree. I encourage you to send an email to the address listed on the page, and I will gladly send you the Enterprise factsheet. But yeah, maybe it's not for you and that's fine!

> Since the library is meant to be used in a web app, how would the app be accessed without internet access?

Progressive web app (PWA), or containered webapps like electron & co.

My thinking here is that containerized web apps built with frameworks like Capacitor or Cordova will typically resort to native facilities. Electron is not a target as the library is meant for smartphones.

I've built a bespoke warehouse scanning application in the form of a PWA before. Our scanners are meant to always be connected to the internet, but there are dead zones in the warehouses and sometimes the connection just drops out of the blue. We added support for limited offline mode, essentially remembering its state, syncing when the connection comes back or warning the picker to reconnect if they leave it offline too long.

> Since the library is meant to be used in a web app, how would the app be accessed without internet access

If a website still works when wifi is disabled, it's because the entirety of the application has been downloaded and cached by the browser; no further Network requests are needed—or invoked by something the user might want to do, like scanning another barcode.

If scanning a barcode requires a GET, POST, PUT etc. somewhere, it won't work offline.

If scanning a barcode only requires reusing a cached script/function/asset, it should work offline.

Good points.

If the app is coming out of the cache, IIRC it does not count as a page load and typically the SDK is initialized at page load (where the license check happens). Scanning a barcode doesn't require an HTTP request, just the initialization of library.

But I agree that requiring internet access at some point is a turn-off for lots of people.

I've been working on a web application that has a bar code code scanning component and I will say that while the apparent performance of this library is impressive, I am not a fan of this pricing model, and that alone pushes me to use alternative libraries [1]. As an aside, the library I'm thinking of is based on zxing-js and seems to have perfectly acceptable performance scanning the bar codes in your OSS comparison [2] using the demo implementation [3] (it scans bar codes despite the name being "html5-qrcode").

For a library like this, the only really appealing pricing model is a flat fee that buys unlimited use of the version I buy in perpetuity (even if that fee is several thousand dollars). I'm not, however, going to pay monthly forever for code that (1) you wrote once and is now static, (2) that you aren't hosting, and (3) that I need to integrate into my application myself. That feels like paying my car manufacturer a monthly subscription for heated seats [4].

If I need support I will happily pay you a support fee. Moreover, I cannot take on the liability of my app's bar code scanner ceasing working because you decide to close your doors and then the license won't reactivate.

[1]: https://github.com/mebjas/html5-qrcode

[2]: https://strich.io/comparison-with-oss.html

[3]: https://blog.minhazav.dev/research/html5-qrcode

[4]: https://www.theverge.com/2022/7/12/23204950/bmw-subscription...

Fair enough. The library you are using is based on ZXing and if it works well for you, then great. I did not manage to scan those damaged codes using ZXing but perhaps I did not fully explore all possible tweaks.

It's a bit disingenuous to claim that I wrote the code once and it is now static (I wish!), but I see that you are not a fan of aubscription models and I understand that.

> It's a bit disingenuous to claim that I wrote the code once and it is now static

Unless the library code were in some way self-updating or had some server side component, I think it's disingenuous to call the library code embedded in my app anything other than static. I assume by "not static" you are referring to decision to continue improving it, which I think is great and affords you the ability to sell me a newer version.

The problem is that unlike „server-side computing“ the web browser and also mobile platforms like iOS and Android move pretty fast. Things change, and things break. Having a „stable version“ is great until a browser vendor decides to update/break an API an the library breaks. Now you have feature updates and hotfixes for an infinite number of „stable“ versions.

Is it using the Barcode Detection API for browsers that support it natively?

https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Det...

I would expect not, as that API does not currently support iOS (which is a real shame). What's annoying is that iOS bundles an excellent barcode scanning framework in Vision, so it wouldn't be tremendously difficult to add to safari.

Hi! No it does not use the Barcode Detection API, as that is not widely supported, and the last time I tried it (which is admittedly a while ago) performance did not seem great.

Cool, I didn't even know that existed. It'll be cool when it's widely available, but even before then it's fun for some personal or PoC stuff

Similar open source product is jsQRscanner on github https://github.com/jbialobr/JsQRScanner

Yes, and like https://blog.minhazav.dev/QR-and-barcode-scanner-using-html-... it is based on ZXing.

I used https://github.com/cozmo/jsQR in production for years. Never had any problems, before all smartphones had built in QR readers, most of our users would use it primarily to interact with our product. Works for iOS and Android. To my knowledge does not use ZXing and is Apache Licensed.

I've had a good experience using https://github.com/nimiq/qr-scanner for QR codes too.

Interesting monetisation model. Wouldn’t a library which does the processing on-device be easily stealable? How do you plan to combat piracy?

There are some measures in place to combat piracy which I won't go into obviously, but probably not enough for someone determined enough to make an effort. On-device license check for unsigned code is basically impossible.

On the other hand, that person would probably never have paid anyway. Also, as mentioned in the text, there are more interesting targets if you really want to get into it, which have the same problems.

Thanks for building this. I agree there's a gap between OSS libraries and high-end products like Scandit.

Scanning barcodes is harder than it looks. Or rather, scanning an intact, well-lit barcode square-on is easy – but it gets harder as conditions deteriorate.

Are you worried about Scandit's patents?

https://www.scandit.com/patents/

Great idea!

I am not so sure about the business model though. With WASM and cross compiling it seems this _could_ be a fairly simple thing to develop these days. Though I could be completely missing the value add or the complexity of the problem. The need for tracking for licensing purposes seems anachronistic and probably easily hacked around. I would expect to see open source competitors offering a free library that does this at some point.

Hey, that's what I initially thought as well! Turns out 1D/2D barcode scanning is a surprisingly involved topic, with tons of research papers. It's a topic with both depth (like advanced recognition techniques for certain types of codes) and breadth (wide variety of code types).

As mentioned, there are several OSS competitors, mainly QuaggaJS and ZXing which is at the core of some wrappers like JsQRScanner or HTML5QRCode.

Am I understanding correctly that the enterprise license allows offline scanning, but that it's not possible for the standard tiers?

I'm using one of the other commercial offerings for a side project, and the one we went with was largely chosen based on its capacity to work in dead zones in our service area. This looks like an interesting alternative if it's also able to scan when the internet drops out.

Hi there. All image processing/code decoding is done on-device. An internet connection is required for the initial license check and for usage tracking (see https://strich.io/faq.html#faqDataTypes for details) in the Basic and Professional tiers.

Correct, the enterprise license offers completely offline operation (= zero HTTP requests) as this is something often required for compliance reasons, and can be useful for PWA use cases and no-reception like basements.

Congrats on the launch! We looked into barcode scanning with webassembly about 2 years ago, and the open source libraries weren't great. Really glad to see that webassembly can work well for this.

This app is adjacent to my indie electron app [1] for designing and printing labels, including barcodes. My app runs on Mac/windows and can be licensed offline. I love offering my users affordable one-time licenses that will work “forever.”

I also offer a monthly subscription to satisfy the herd.

1) https://label.live/

How does it compare to scandit? [1] I have used scandit before in a project in a drone to scan barcodes in warehouses, and had to do several hardware/software tweaks to scan some barcodes, might give a Strich a try if it’s better.

[1] https://www.scandit.com

Do you still need to grant the web page access to the camera on every page load on iOS, or have you found a workaround for this?

Hi. From iOS 13 onwards camera access can be permanently granted on a per-site basis, see https://stackoverflow.com/questions/48847388/how-to-permanen...

Congratulations on the launch! Great landing page, and impressive demos.

Thank you so much!

Why do I have a weird feeling this would be something Zebra would try to acquire? ;)

Show HN: Strich – Barcode scanning for web apps