Although .Net went multiplatform years ago, my app relies on WinForms a lot so it's Win only, except through Wine. I would love to support Mac as well but the only realistic option looks to be Electron based, and it would be a significant step back for my Windows users. Maintaining two different GUIs looks like a problem for micro company.

The best thing about desktop software is it can't break for all the users at once like server-based app can. That gives some piece of mind when you're micropreneur. Sure, there are bugs, but they affect only users who downloaded buggy version. You can't crash all installed instances just like that.

The worst thing is, it's hard to ask for a subscription. Yes, I hate it as a user, but would love it as a business owner :)

https://www.cogin.com

We also have major upgrades which do bring in some more cash since they're more expensive and more users buy them. But it's every 5-6 years. And it's still significantly lower than regular new licenses.

I'm thinking about adding a Saas "Team" edition, which would offer centralized management of users, connections they use, permissions, with some auditing etc. First problem is we would have to store some sensitive data (connections) which gives me a security scare. Second problem is we'll introduce central point of failure which gives me another kind of scare. And very soon we'd have different versions of client software running on end users machines which should all work correctly with a server. That's a third scare, a versioning one.

It's beginning to look clear why it's an idea from few years ago but still not implemented.

Azure AD I meant just for user / rights management - not full azure for actual storage and everything.

WiseJ is a drop-in replacement for WinForms apps, to make those run in a browser.

The WiseJ 2.5 is yet on .NET 4.8, but the new WiseJ 3, planned for March, is running on .NET Core.

The key features for me are: (1) all the wiring is hidden, so no need do not deal with Javascript. All processing is done in server. (2) Refreshing the browser by pressing F5 keeps user's session. (3) Background tasks work seamlessly with UI updates. (4) Can use System.Drawing.

It is a paid library, but very reasonable price.

That's not a bad thing. My company pays quite a bit of money for various libraries and if we notice a bug in any of them, we report it and it's usually fixed within 4-6 weeks in a new release.

There is no discussion with 5 people chiming in and you don't need to follow up constantly. Report it once, answer maybe one or two questions on how to reproduce it, and even very complex bugs will be gone.

I know that there are a lot of well maintained free projects but being able to write a report and to be guaranteed an answer back on the very next day is very calming when you have customers waiting.

https://github.com/dotnet/maui

Also, it's hard to bet on a new MS GUI framework, when they released and abandoned several in the last decade. Will it be supported in 5 years as a minimum? Yes, Winforms looks outdated, but it still builds and works as it did back in 2005.

One more thing, I'm not using vanilla Winforms but also excellent DevExpress controls. For example Winforms has a grid, but DevExpress grid is highly customizable, works ok with 100k rows, has filtering, sorting, etc. It's not only about base GUI framework, it's also about entire ecosystem of GUI controls. And maturity of these controls. E.g. Devexpress has MAUI grid, but I don't expect is to be as mature as winforms one.

I'm not saying that MAUI couldn't be useful for some cases. Even many cases. It's just not yet ready for my kind of software.

The biggest irony is that this tech would have allowed them to open a store on Windows 7, 10 and Mac which could have been way more popular due to market share than both the Windows and Mac app stores.

However if you don't have such specific requirements, Avalonia or Uno might work.

https://venturebeat.com/2021/11/22/conduktor-which-brings-a-...

If anything, it's a testament to what an absolute pain it is to develop on existing message queue/event streaming platforms, so it's clearly a valid niche.

I'm slightly surprised that the .NET client isn't fully featured, but I've never tried to use Kafka from a .NET language before.

Btw. that's also the problem with all other queuing systems we support. Their APIs are made to support Send/Receive scenarios, what these systems are built for in the first place. They rarely support "delete message in the middle of the queue", and never "replace message" or "insert message at arbitrary position". I guess API authors are worried that such functionality would lead to apps mistreating queues as a kind database, which is not intended use case.

However that sort of functionality is often needed when you're troubleshooting and fixing a problem. It's not like everything always just works. In reality things go wrong, message format changes, invalid data goes into queue, etc. And then we have to abuse existing API and/or give only subset of useful features to users.

About combining Java or something else - that might be possible from technical point of view, but remember this is a desktop app which ships as an installer. Not an environment you'd set up on the server. We would have to include another runtime and make sure it works correctly in different scenarios on end-user machines.

Worked like a charm.

Basically, it is a JVM implemented in .NET so you can easily interop to the missing management APIs from the Java client and there is no extra runtime install to worry about or calling out of process.

Might be worth a try.

We have a desktop app that processes DICOM data to do implant treatment planning (where to place an implant in the patient jaw). Output is a STL file to print a drill guide for the oral surgeon to perform a guided surgery.

Our desktop scanners for dental labs and our intra-oral scanners for dentists generate 3D meshes of the patients oral situation.

Those meshes are the input data for the CAD/CAM Software my team builds. It is a desktop app for the digital design of dental restorations. The GUI is in javaFX and 3D visualization is done with OpenGL 4.5.

Once the restorative Design is done, that app can generate many different output formats. Labs will feed the design files their local milling machine or 3D printer. Dentists can send it to centralized milling facilities of their choice to produce the crown or bridge or what have you.

Some impressions can be seen here:

https://youtu.be/5THQMr5SAH0

Your observations is spot on:

Indeed, the environment is far from ideal. 2-3 years ago dentists had to apply a powder onto the patients teeth to make just the scan of the teeth work. Now the software has matured to work powderless. The scan has to work for a wide variety of surfaces and vis-a-vis refractive indices like teeth, metal implants, ceramic or gold inlays, gingiva, orthodontic engagers. The very high end models even detect tooth decay / caries.

The stitching is another challenge. Again, in the past the scanner would loose his reference on the mouth and it was fiddly to get it back to continue from the last scanned part. The team working on this was brilliant to overcome this problem and now it is a smooth experience

Finally, accuracy is something all devices on the market having a hard time with. They are operating on the limit of what is possible. Small partial scans are no problem. But when you scan a full arch, you must ensure the deviation does not exceed 30-50 microns over that full arch. Otherwise, if the dentist plans to do a big bridge that spans several teeth a lower accuracy will lead to miniscule deviations and twists in the designed and later produced bridge, that the patient will recognize it and feels that it "just does not fit right".

Our mouth is super sensitive in this regard because of the high number of nerves/sensors. Our tongue operates like a magnifying glass. When you have a small hair in your mouth or between your teeth you will feel that right away.

Damn, you weren't kidding - https://www.youtube.com/watch?v=AA4IWd3Svm0

Very impressive indeed. Looks effortless and natural, but I'm sure that the processing engine is not exactly trivial.

The processing on that to achieve such a low latency is amazing, flat out.

Fun watch.

Any chance you could enlighten me?

p.s. the drill guide arrived, the implants go in next week!

For the latter you then also need the intra-oral scan. The output of the IO scanner is a simple (but massive) 3D point cloud. The software then is meshing those points on the fly. Using the color information from the IO scanners camera, shaders are added to generate the right texture for teeth, gingiva, etc.

We have a module in the CAD Software that allows to Integrate the surgical and prosthetic workflows through real-time case data sharing between coDiagnostiX and DWOS CAD. The Real-time (or asynchronous) connectivity between lab technicians and implant-placing dentists enables better prosthetically-driven implant planning and immediate provisional design.

On a personal note, don't be afraid of the procedure. With those drill guides and today's planning solutions we made leaps in implantology. In the beginning the surgeons did it by hand and feeling. I shudder at the thought.

Reading your comment made me really happy. As a dev I am always excited to have contact with our customers. Other hate it, but I love giving 3rd level support.

Yes, your "Cares Visual" Straumann software is just a branded version of our Dental Wings one. In terms of functionality there is no difference, but I think with your version you got by default access to the vast Straumann product portfolio (hundred of implant kits and materials), plus their validated (FDA approved) workflow and access to their centralized milling facilities.

> dont take advantage of a lot of the software that's available to me. I do crowns, bridges, and implants mainly.

Yes Cares Visual is very flexible and offers many different ways to do restorations. It can be daunting at times :).

> Most of the general dentists do take impressions, and send those along, which I pour in gypsum, and scan in the scanner. I do have one dentist that I do work for that uses an intraoral scanner.

That is what we see in Europe as well (I assume you are US based). Dentists are more conservative when it comes to switching to digital dentistry. But I think it is understandable. Having their patients safety in mind, they want to be sure before applying completely new technology. Your dentists uses a Trios IO scanner. Since Care Visual is an open system we can deal with input from many 3rd party devices (i.e. non Straumann).

What topics would interest you? Or do you have any feedback in particular? I am happy to take this conversation elsewhere. See my email in my profile.

We had a team that also build Lab management software but overtime we painfully became aware that an integrated billing service is a maintenance nightmare with yearly changes to tax laws, the myriad of different health care providers/insurance companies ever changing what treatments they subsidize to which extend on an monthly or even weekly basis. Multiply that with all the different countries we operate in, it became unsustainable.

So again, kudos to your father to prevail in this space.

The tech stack for this app is really interesting (to me at least, natch). Lots of native node modules that need finesse on both macOS and Windows. I don't yet support Linux because out of thousands of users, only 2 people have emailed about Linux support (probably both from HN!).

I really love building Electron apps. It's a total joy bringing something (albeit "inefficiently" wrt memory and "native" qualities) like this to market for a niche that's otherwise a dumpster fire of old and clunky 1980s-era Windows-only software.

As for licensing, Label LIVE is licensed per computer. I wrote a custom license implementation leveraging JWT. The JWT is signed by my license server and the app verifies the signature and that the contents match the "fingerprint" of the computer being licensed, expiration, etc.

I'm a little surprised to read this from an Electron dev. I remember reading old forum posts about how the Spotify port for Linux was arranged by two devs who met after work for a few hours and got it working well enough that Spotify let them release it as an unsupported client. There was one or two issues that had to do with importing local music, but besides that it ran perfectly fine. You're of course welcome to do whatever you want, but if your runtime is essentially a web browser, I doubt there's going to be much trouble getting it to work on Linux. But what do I know, I don't make a living off of printing labels...

> It's a total joy bringing something like this to market for a niche that's otherwise a dumpster fire of old and clunky 1980s-era Windows-only software.

Here's my grumpy old man take: I kinda prefer the clunky Delphi forms of yesteryear. No, they weren't very pretty, but they were stable and performant enough that if you bought a license, you could guarantee that it would run forever. There was a special kind of feeling of ownership with that software, because it really felt like it was tangible and "yours". I don't think any Electron app has ever made me feel that way; at best it's a begrudging relationship with software I need for work, at worst it's one update away from being changed enough that I want the old version back. Again, take this with a grain of salt, I don't know your heuristics here.

Second, auto-update is disabled by default because I don't want a dumb bug on my side to break someone's "it just works" printing system.

IIRC, Spotify "unofficial-but-official" client largely predates the Electron version and this story is from the Qt era of Spotify (which was wonderfully light and fast).

Managing 10+ levels of JS promise chains can be a chore if not architected and named properly. Or worse, when you write a feature that’s close to the user and realize it requires asynch all the way back up through 10+ sync calls so now it’s refactoring across 30 files and you forget one edge case that doesn’t resolve/throw and it takes days to track it down. Normal solo project problems.

Integrating fabricJS with a custom wasm module to dither images. That was a 10x speed improvement but took a few hundred hours.

Early on I chose react/flow/redux/immutable/semantic-UI as my front-end “stack” and it’s been mostly good to me. Of course, I wish my codebase was all perfect typescript but eventually I’ll get there.

The node ABI changes over the years has really stressed me out. It seems like it breaks all the native code every 3 months. Ugh!

Customer support has been delightful. Out of a few thousand emails only 2 or 3 have been awful. Sometimes I’ll get an email at 2pm on a Sunday saying “I have to print 5,000 labels by Monday morning or else I’m fired!” and we are always successful. That feels good. The toll free number on the website rings my cell and sometimes I wake up to missed calls from Nigeria or UAE and I think that’s pretty special. Call volume has not been overwhelming. Thank god.

Marketing is a huge chore and I mostly disdain it.

However, I was about 5 minutes on your site and could not find a list of compatible printers. Where did you hide it :) ?

Maybe you could have a list of recommended printers too?

Looks like a great app though - I have a forthcoming need to print a lot of inventory labels and I think your app would be great for that.

So why not use the device driver? For one, they are often terrible experiences, especially Zebra on macOS, let alone other obscure models with zero Mac support. Another is printer drivers are almost exclusively tailored for large paper sizes, don’t give the user fine control over orientation, often auto-scale and hijack all these settings to best fit, which then destroys any attempt at fidelity with the intended output DPI which is often critical for matching with the smallest feature of a barcode. It’s tough to explain but in short, if your smallest barcode’s smallest feature is one dot width, then the next size larger must be double the barcode size because you must double the smallest width to keep the same relative size to ensure scanability. It comes down to “don’t dither barcodes” and all sorts of enforcement can happen if the app controls exactly how these are represented to the printer. No guesswork allowed.

All this to say: the printer expects to be told exactly what to do, but the driver plays loose and fast.

Eventually, after only focusing on thermal printers, a few years into development I added the ability to send perfectly sized PDFs to print queues effectively allowing access to any printer with a system driver (inkjet and laser). You can easily test “both ways” and see what you prefer. Using the in-app “driver” has so many advantages. You can adjust most print settings and they get saved for each design vs externally. You can buy a new Mac or PC and plug-in a supported thermal printer and it’ll just work without any drivers. It’s really nice UX in an otherwise very hostile environment.

TLDR: I’m not writing inkjet/laser drivers, only thermal, and only when enough users request explicit support because of problems they are facing (above).

But it would be AWESOME if I could let a user click a button and send them to a labellive:// URL and have it just work. I'll explore a little and see if there's a mom-tested way to make this usable.

Again, very cool app!

I definitely have users triggering labellive:// integrations. The nice thing about the URI is it automatically launches the app if it isn't open - which is not true of HTTP integrations. The downside is it can be slower, especially on windows. Been there, done that. Maybe there's a workaround because Windows optimizations like this are a black box/art.

The other challenge is going to be referencing a standard design. Today, the integrations reference an absolute path or a "pinned" design file. I've had a few subtle requests to allow pulling down a standard "reference" design from the cloud (that you host for your users), and the app will cache the design based on a computed hash that you include in the URI. If your design changes, update the hash, Label LIVE will pull the update on the next invocation.

There's a lot of fun room to play with this. Let me know if you'd like to team up by emailing help @ label dot live. Now that I've got a fairly sturdy base of features my 2022 focus is to really hit and deliver on the potential for integrations like this.

That's certainly not the trend. Evernote has even released a Linux app after all these years. And for good reason - the Chromebook market. Hey is another.

1.https://www.beekeeperstudio.io/

Electron abstracts plenty else that's 'OS based', for all I know/knew it has/had a printer API.

Cross-platform apps are what it's about; it wouldn't be accidental. There are plenty of Electron apps that work and are packaged by third parties for Linux that only advertise (by the first party) Mac & Windows support. Spotify I think, for example.

It was a long way. I started in the Pro Audio niche and initially supported Windows, Linux, Mac. Over time, I learned the hard way that supporting Apple's constantly changing OS is very expensive, plus Mac users tend to act the most entitled when stuff doesn't look or feel like their native OS. And Linux just never sold a license, instead I got lots of Open Source bitching. So eventually, I dropped Linux and Mac support, doubled down on the new Windows APIs and then things got nicely profitable. Price is one-off $299 for the regular app kit with perpetual updates (so far). People use the apps for making movie sound effects.

I did not realize this was a mark of the student life. Who knew I was still a student at age 49?

I would hate that a stranger enters my house to clean, and I would hate it even more when I was not at home.

Separate store and fastspring.

the current problem for me with Microsoft fat client is there are too much options and no clear one that Microsoft will support long term.

They deprecated .NET Native and C++/CX and are yet to provide any tooling that compares to them.

.NET Native is stuck in C# 7, while C++/CX got replaced by C++/WinRT with the argument that it is ISO C++ friendly, when in reality it offers the same tooling as using Visual C++ 6.0 with ATL back in the days before .NET came to be, but their developers are so stuck in COM pre-historic tooling that they don't acknowledge that.

Apparently WinUI 3.0 would be the future, with the merge WinRT and Win32, however issues pile up exponentially and even Windows 11 is making use of the deprecated UWP, as the team cannot keep up.

Since MAUI depends on WinUI 3.0, it is yet another reason why it keeps being postponed.

Windows on 2022 with Microsoft stacks MFC (yes really, much better than C++/WinRT), WinForms or WPF (eventually with C++ if required).

Otherwise Qt, Delphi or C++ Builder if enough budget, or PWAs if possible to do so.

Qt 5+ for anything with any level of complexity. Windows has already given up on 'native' UI.

JUCE for audio plugins.

Don't bother with all the 'modern' pretend-windows-is-a-touchscreen-os frameworks.

If pressed I would say WinForms is the most practical choice for most apps today - even though it sucks, even though it's ugly. It's actively worked on (unlike WPF) and it lets you use the latest .NET version.

WebView2 (better Electron) is probably where most Windows development is going in the future, the Windows team is investing a heck of a lot more in it than other technologies.

Imgui and juce are great frameworks.

Having been out of the web app development bubble for about seven years now, there's whole industries that work entirely in the pay-for-it-and-then-download model, and while games-as-a-service is more popular now than ever before there's still plenty of the old-school way of doing things going on.

I really like the simplicity. You can buy the thing, maybe from Steam or maybe from a DRM-free store like Humble, download it, play it. You can get a refund if you don't like it, or buy another copy and gift it to a friend if you do.

[0] - https://store.steampowered.com/app/386900/The_Cat_Machine/

[1] - https://store.steampowered.com/app/654960/The_Eldritch_Zooke...

* What's your tech stack for the games? Are you using an engine?

* Who made the art? If you did it yourself, what software are you using?

* How was the process for releasing your game on Steam? Did you have to do a lot of marketing to get users to greenlight your project?

* How did you make the trailer for the Eldritch Zookeeper? If you didn't do the voice, how did you hire the voice person?

* The Cat Machine has 107 reviews on Steam. How many users does that translate to?

* Does your current employer have a clause in the contract discussing IP made on your own time? Did you have to get an exception from your current employer to be able to release games on Steam?

Thanks in advance.

Marketing for The Cat Machine wasn't too bad, I had an okay ground game with getting coverage from gaming websites and someone posts it on Reddit and for 2015 that was good-enough marketing for the time, more than enough to Greenlight the game. The voice actor is Scott Gilmour (@scottgilmour7 on Twitter) and I found him after listening to about 100 voice samples on all the different VO websites. He's fantastic! I don't share my sales numbers publicly, but Steam is about 70% of The Cat Machine sales, and about 25% is from the Apple Mac Store - where the game actually hasn't been published for about a year now, I need to get on that and reupload it. And games is right now my full time job, so no IP clauses needed negotiating, and my old employer back in 2015 was very chill about letting me work on my own stuff.

Hope that helps!

With Modo they do offer a perpetual license option where you can keep using the last version you paid for.

Thanks for your insights into your process. I agree, DaVinci Resolve is an excellent replacement for Adobe. I got the Speed Controller deal last year, it's nice having the jog/shuttle wheel and buttons.

Deciding what price to set games must be difficult. I'm in Australia, and the price of your cat game is $21.50. Even though that's equivalent to a large pizza and drink, it's steep for an indie puzzle game. I wonder whether a game like this would sell more and profit more if the price were $5 instead of $20.

I am a web developer and always assumed that you need SaaS or mobile app to make money from programming. But I hate to be responsible for customer data or troubleshoot servers at night.

I might have to look into desktop development and even game development as that was the reason I studied computer science.

But I'm mostly using C# and Unity these days. There's too much useful stuff build into Unity to ignore it, and C# is very pleasant so I didn't find it particularly hard to make the jump - there's just a very definite 'Way' Unity wants you to do everything and so most of the time it's just a case of working out what that Way is.

It has this features:

* B2B in a niche market (TAM < 100K-200K users)

* Some viral component so you do not have to spend money on ads for growth.

* Sold as a subscription and only as a subscription. Don't innovate with licensing focus on product, this is important. When users have fewer buying options, they decide faster. That's why Steve Jobs reduced 50 Mac models to just 3.

* When the subscription ends, the application must stop working. This is also very important. You want your entire user base to be able to install the last version. You do not want to support older versions, you only want to support one.

* Has to have a very generous trial so that users have time to find use cases with your product. Better a trial based in actual usage instead of exploding trial base in calendar days. You want your users to actually use your product and depend on it.

> * Some viral component so you do not have to spend money on ads for growth.

Indeed. For years our sales department was simply our customers. They'd call their friends and tell them they need to get our software, or when they switched jobs they'd work hard to get our software used at the new place.

Now we have a small but proper sales team. However word of mouth got us very, very far.

> * Sold as a subscription and only as a subscription.

This was a key point my boss realized early on as well. It's much easier for the accounting department to handle a fixed recurring cost, than a bi-annual huge expense or similar.

It also allows you to incorporate usage into the price, so the price scales with the customers' income, not unlike cloud offerings.

We have a small fixed monthly cost, and a variable cost (per invoice/order essentially). The variable price depends on volume, but it's very predicable and makes it so the customer doesn't have to worry too much if business is slow for a while.

Note that viral is not the same thing as word of mouth. Viral means that one user expressly or subliminally forces other users to use that software.

For example, a customer asking or encouraging a vendor to use some specific software because it makes things easier for the customer and later, when that vendor is also infected with the need, they ask or encourage their own vendors to use that software too.

This is the distribution mechanism that we have for our tool.

Since we integrate very well with our own products, we can supply superior data to this second product, causing the effect you're talking about as these other customers of ours puts pressure back up the chain.

* B2B niche - agreed, this is essential

* Viral component - I wish I could make label printing viral... but I feel like I'm dealing in the "colonoscopy of software" with my app

* Only subscription - I agree this maximizes revenue, but I find subscriptions user-hostile, so I also sell a one-time license

* Subscription expiration - obviously essential

* Generous trial - agreed, essential

It can be a relatively small gap in theory covered by several larger tools but only superficially covered either because they do not truly understand the pain point of that gap or because they simply want to limit complexity of their base product and their surface of support.

So then you focus on developing that feature to perfection with a strong focus on integrating with each of those larger tools, whenever possible without any collaboration of those larger tools (that will come anyways later if you get the traction).

The larger tools will never compete with you directly because if they created a tool doing the same thing you do, they would have to integrate with their direct competitors, which is a bad scenario for them as either they get expressly blocked by the other tool developer if seen as a threat or because by having such tool they would be ultimately improving their direct competitors tools.

Our current position is that if a customer of us decides it's time to change the larger tool, one of the factors of the decision is how well the new larger tool integrates with our tool.

Go onto any software listing site (eg. Softpedia or AlternativeTo), pick a not-a-brandname commercial product and chances are that it will be a single-person project. From things that are really well-polished and look like a team effort to pimped-up crappy weekend projects. Lots and lots are made and run by a single individual.

Whether they sell well is an altogether different question, but it's generally not hard to make several $k per month off a decently useful consumer desktop software. All depends on the size of the niche, the fit (read, specialization) of the product, its quality and the amount of marketing effort.

This business model is still often referred to as "shareware", so if you want to find communities of people that are involved in it, that'd be the keyword to search for.

Here are the ones that I use most and the companies that develop them:

Fission; Audio Hijack (Rogue Amoeba): https://www.rogueamoeba.com

Amadeus Pro (HairerSoft): https://www.hairersoft.com/index.html

Transmit (Panic): https://panic.com

Jedit Ω (Artman 21): http://www.artman21.com/en/

BBEdit (Bare Bones): https://www.barebones.com

GraphicConverter (Lemke Software): https://www.lemkesoft.de/

I only run macOS on my laptop and yet it's where I've spent the most money on various utilities.

MacOS-only software I've paid for: Bartender, BetterTouchTool, Forklift, SoundSource, Pixelmator Pro, iStat Menus, Nova, Alfred, DaisyDisk, and some other things I'm sure I'm forgetting.

But as you can see later on in the entry, StackOverflow's survey shows the numbers as being much closer. So your target audience matters. I'd expect that software developers aren't the only set of users where the ratio is far off of the average.

I try my best to make it "worth it" to purchase the app. Label LIVE is a super- boring business label printer app so it takes a "special" person to 1) need the app and then 2) decide that they'd save more money by cracking it than just paying for it. If I 10x my pricing (as my competition does), then I would fully expect users would find it worthwhile to crack and distribute.

An altogether different option is to pay 2x the commission and use "full-service" reseller frontends like Digital River, PayProGlobal, etc. These are referred to as "registrators" and they used to be useful, because getting a merchant account and processing cards was a royal pain the ass. But now there's Stripe, so virtually no value in them. In fact, they tend to make thing more difficult to the clients than needed to justify their own existence (like requiring phone numbers, calling customers back to "verify" purchases and other artificial b/s like that).

Re: piracy protection - wildly depends on whom you ask. There is a camp of people that put minimum effort (literally a a single "if" check in the code) and embrace having their stuff cracked and hacked. The logic is that this acts as extra marketing and helps converting pirates (lol). There are also people who use packaged solutions like VMprotect and (previously) Armadillo. This tends to nip piracy in a bud, but creates issues with antivirus false positives. It also makes the software heavier and more fragile. There's also a middle ground of custom protection schemes that, if deployed wisely, can create 100x more headaches to crackers vs the effort spent on coding them in. Not that hard to do, but these aren't drop-ins, obviously.

Also, closely related, is the question of how the licensing works. Previously, most of the shareware used completely offline licensing using "keys" that were either hardcoded into the program or verified algorithmically (read, with elaborate checksums and such). This caused an emergence of keygens and it also fed credit card fraud with people smash-n-grabbing keys in bulk and then published them for the street cred. Surprisingly, a lot of shareware still uses this method and they still bitch and moan about the consequences. The alternative, obviously, is to use online activation. That is, what is sold is an activation token that can be swapped for a machine-specific license, via an exchange with the licensing server. This nearly completely eliminates the CC fraud and it allows for finer control over licensing. There are some drop-in solutions for this, but all of them are really quite basic and almost universally suck. However, the good news is that is fairly simple to roll out your own online licensing scheme in a matter of few work-days (assuming you know a bit of web backend and frontend).

I wouldn't say all of them suck. But that's because I built one [0] for the sole reason that, back in 2016, I too thought all of other ones sucked.

[0]: https://keygen.sh/build-vs-buy/

This is inaccurate and misleading.

The calculator assumes that there's no cost to integrating with your system. It also assumes that the developer is salaried, which is almost never the case when it's a single-person shop.

The amount of effort required to learn your system, to do the integration, to test and to support it is absolutely on par with the time it would take to make a simple licensing framework from scratch. Except that the latter doesn't create an external dependency for a critical part of customers' experience.

This is all from a perspective of desktop software vendor. Perhaps things are different when your service is used for WP plug-ins or web apps, but for desktop apps - IMNSHO - the value of it is fairly low.

Thanks for the feedback! And that’s correct, but I think you misunderstand the calculator. This is for the cost of the licensing server alone, not the integration into a software application, which will of course cost additional time/money either way. Regardless, the real build vs buy savings in almost any third-party are in often forgotten long-term maintenance costs.

> It also assumes that the developer is salaried, which is almost never the case when it's a single-person shop.

If you don’t have a salaried developer, or at least have an average spend per-year to be able to input (even if it’s yourself at an hourly rate), then you likely aren’t my target market. And that’s totally fine. One-person shops like to unnecessarily build things in-house because they typically value their time at near-zero. They’ll spend weeks building something they could have paid $19/mo for. (Which is fine -- they churn more often and require more support, in my experience.)

> The amount of effort required to learn your system, to do the integration, to test and to support it is absolutely on par with the time it would take to make a simple licensing framework from scratch.

Keyword here would be “simple.” In my experience from running the business for nearly 6 years, most licensing systems aren’t simple. And if they are, they likely don’t even need a licensing server in the first place -- just do signed license keys.

I have testimonial after testimonial of the opposite conclusion -- that the API saved significant time and money -- especially for the long tail, years after integration.

Unless your licensing system is incredibly simple (and in my experience they rarely are), there’s money to be saved in not building and maintaining it in-house.

Also, it's worth checking with the accountants first before taking on a role of a tax collector. When yet another random country demands a sales tax on purchases made by its citizens, it's just a spherical pony in a vacuum. Best to first check if their demands have merit.

if so, that is a recent development.

Every iota of effort spent going after pirates is effort not going into servicing existing customers or getting new ones.

PS. Having cracked versions floating around affects SEO ranking of the master website, it affects sales and overall perrception of the product and, as importantly, it also hits support with a lot of bogus bullshit from people that aren't even customers. So for every iota one may "save" by not adding protection, they would spend multiple iotas dealing with the consequences.

That said, long-term, we expect to earn more from subscriptions for businesses, than we do from single-user lifetime licenses. But again, ATM, it's the single user licenses that sell well.

However I really like your approach having a pay-once personal edition and a subscription team/business edition. It's something different from the subscription-everywhere trend.

Additionally, our long-term vision is to make the bulk of revenue from Teams subscriptions, where most value comes from a web-based dashboard (https://paretosecurity.com/teams), which is closed sourced.

They reached out to us. We integrated their SDK (trivial), provided sales copy and screenshot, then waited about two weeks for the review.

For the first few months, we got the most revenue from SetApp, it quickly jumped to ~$800, but these days, we earn more from selling single-user licenses. I expect the SetApp part to become smaller and smaller as we grow our Teams subscriptions.

Generally, I think it was good. It got us a few hundred users very early on, which helped us focus on the features and fixes that mattered. It also helps with brand trust, i.e. if you are in SetApp, there is less chance of you being a scammer.

My latest product is a drag and drop tool for data transformation (merge, split, clean, dedupe etc): https://www.easydatatransform.com

Things have mostly moved to web, but desktop apps still have major advantages in some areas: -less latency -data kept locally -better development tools

Recut[2] is an app that basically does what Atomic Edits aimed to do, but actually succeeded. I think it's because it was a native Mac app which meant it had access to better libraries for editing videos. (That or I gave up too early on Atomic Edits.)

Orbital[3] is desktop app that allows you to search, filter, preview video files on your computer like YouTube. I posted on some subreddits and it had potential but I realized it wouldn't be enough to sustain me. It could've worked as a side-project (if I was working as a SWE) but being as my main source of income was from YouTube ad-revenue, it wasn't worth it.

VideoHubApp[4] is a desktop app that does what Orbital aimed to do and actually earned a couple thousand dollars. It was started a few years earlier and was built with a similar tech stack.

All that is to say, I made desktop apps that had potential, but didn't have the funds to see them to completion. Of course you could say it would be different if I had a SWE job + funds, but then I may not have had the time to learn React + Tailwind + Electron and complete these apps.

[0] https://github.com/SuboptimalEng/atomic-edits

[1] https://www.reddit.com/r/webdev/comments/ohbl6i/i_made_a_des...

[2] https://getrecut.com/

[3] https://github.com/SuboptimalEng/orbital

[4] https://videohubapp.com/en/

[0] https://www.budgetwithbuckets.com

magnificent! I hate reconciling my amazon -- and recently walmart grocery pickup -- purchases for this reason.

And yes, it is almost always easier to punch in numbers on the desktop.

What am I suppose to use when I’m out and about or traveling? I was on vacation when I got paid in December. The only thing I had on me was my phone.

I am planning to create another app that might generate a similar income stream. I've done 0 paid advertising - only some posts here-and-there; I would probably have more sales if I knew how to market my app better.

https://videohubapp.com/en/ - MIT open source: https://github.com/whyboris/Video-Hub-App

Generally I would say try to minimize the amount your spending per keyword - broader search terms or the broader options on those search terms always cost more.

Might help a ton if you renamed your software to something that is more searchable (or just add some kind of name on the end or start)

For something like this I would probably start at like 30$ a month and keep optimizing - worst case you lose only a few hundred over the course of a year.

But it is almost impossible to get any worthwhile traffic from Adwords in 2022 (in terms of volume or quality) at 5 cents a click.

Small question: how do your users find your product?

After a while, I just stopped all marketing efforts and now it's all just word of mouth/google search.

> removed the feature the allowed for toolbars

Should be that, I presume.

Best part: it also shows battery health really well with discharge charts and can track multiple batteries (if you still have a laptop with which you can swap...).

It begins with collecting ideas from websites and files, moves the ideas into an outliner, then supports organizing relevant ideas according to a report outline, and finally, supports reviewing relevant ideas while the user writes each section of the report.

I gave away 850 free copies that were good for a year and sold a couple dozen copies. I'm trying Reddit ads now. Zero success. It's daunting. I'm struggling and depressed. It's a damn good application, but I can't find a way to reach my audience.

I took a look because, as a current student, I often have to write research papers and tag ideas from multiple websites and sources. I think the cost is a little steep for Mac apps in general, let alone anything a student might want to trial. The question students are asking is "How much can I spend to improve my research paper skills?" $40 is comparable to a night out with friends or several meals and might turn off any potential customers.

Looking at the promotional screenshots for the application, I don't get a gist for what the application is or does. The actual images of the application are smaller than the text describing what is in the application. It's also not clear from those descriptions what the benefits of the application are. I'm not sure what a "structured workflow" is but maybe giving a juxtaposition between the traditional way a student might try to organize a paper and Epiphany's way might help students visualize how they could use the application themselves.

Lastly, the website[1] needs more examples and demonstrations of the application in action. I still can't tell what I would gain from spending $40 on a Mac app. To use an example, none of my friends are willing to buy the Things app[2] at $9 on iOS or $49 because they can get other apps that do the same thing for free. It's a price comparison game and there needs to be more discussion around what can be gained with this app over a competitor.

I hope this helps and I wish you well with your application.

[1]: https://epiphanyworkflow.work [2]: https://culturedcode.com/things/

In response to your comments, I reduced the price to $9.99. I'll make it clear that there is a money back guarantee for all apps in the App Store.

The other suggestions I take very seriously. I will implement them, but this will take time. Several weeks probably.

Just from reading your post, I suspect the app is too specific for your workflow and not generic enough that people can use it if they have a slightly different workflow.

After five years with no sales?

Stuff like this, https://www.biotek.com/

I have done WPF and Windows Forms for companies using such kind of hardware.

Qt is the major alternative for these customers.

Also note that iPads and Android tablets with plugged monitors are a kind of desktops.

There is one instance where we still use machine control / HMI non-web, and that's when there is no TCP/IP stack available. Doesn't happen that often anymore.

It seldom comes up though.

We did this with meta-refresh and progressive loading (https://blog.codinghorror.com/the-lost-art-of-progressive-ht...) earlier on as well. Benefit is that you get that client-server model without having to do all that much special for the client side, works on any client that has a working browser (even ancient IE5/Netscape4 rendering engines), even embedded systems and weird stuff like NetFront and Opera Mini Java (which runs nearly everywhere).

A lot of actions are essentially reading for status and anomalies, and every now and when adjust or control things (not real-time actuator control like a robotic arm or something like that, that requires hard realtime loops for us), anything bigger than that you'd do on a full desktop style system anyway and you can just use a modern web app in the browser for that. Those then also work on tablets (wallmounts! yay!), PDAs (well mobile phones without modems today) and other devices.

In my case a web app just wouldn't work very well (it's hard to connect a web app to things behind a firewall)

I'm also a firm believer in pay-once software, you still get recurring revenue unless you saturate the market, which a small company won't do anyway.

What's the name of your app, I'd like to give it a spin.

My perspective is Enterprise is hard to hit with SaaS. It's also hard to build an integrated (AD/Network/Data/Files) desktop solution. It still seems more viable to start with a standalone, offline, Desktop solution that individual enterprise employees might consider trying / e.g. something like an app that replaces excel with better efficiencies. Maybe while building some SaaS-like component (advanced processing in cloud, API integrations, etc) that still opens the door for non-enterprise users. Ultimately while building a portable/cots cloud based solution. Further letting you evaluate ways to pivot in either SaaS or COTs in the future.

Im still not confident that an MVP approach shouldn't just always accommodate seemless accessibility (SaaS) for a larger general market, and that I shouldn't discount enterprise requirements for non-corporate LAN user bases.

This is currently my approach -- not making a living (yet hopefully) -- but will report back soon. I have a baddie of a productivity tool that can fragment features to a few pay per use web APIs that I'll package with a front end for non-enterprise.

A slight tangent: It's very, very challenging to enable collaboration in these types of environments. Magic Wormhole [0] has been an interesting solution I've wanted to integrate, but haven't yet.

[0] https://github.com/magic-wormhole/magic-wormhole

Wails because I imagine extensive Golang based services (preference/experience) in any cloud env. .NET would be my other approach for O365 based integrations.

Rust has something similar to wails, https://github.com/tauri-apps/tauri . Then there all the traditional native vs cross-platform methods.

No approach, or cross platform framework, really seem quite right. But I figure time and money would be the important factors in any serious avenue I want to take things.

Many our customers specifically looked for an on-prem solution as they don't want to deal with SaaS and its privacy issues and use-based pricing. With an on-prem tool like ours they get unlimited runs, unlimited data volumes, unlimited use for a reasonable fixed price.

I believe SaaS is overhyped and in a few years the trend will change toward on-prem SaaS-like apps and platforms.

Congrats. That's the dream (to me). Bootstrap and create a handful of jobs.

It being desktop-first makes it as easy to try out in a corporate environment as Sublime. The data never leaves your machine. Desktop-first is a big deal in devtools for this reason.

[0] https://github.com/multiprocessio/datastation

Not a single company took me up on my offer. After hearing I would charge extra for the questionaire, they always just bought the standard license and filling the questionaire suddenly wasn't required any more.

https://openrefine.org/

https://loshadki.app/

[0] https://www.inkdrop.app

[1] https://www.youtube.com/c/devaslife

Also needs to pay for the cloud servers running it lol.

I don't see anything wrong with this. Users buy software because it solves their current problem now, rather than a possible feature in the future. The revenue stream is definitely more reliable though. Just that as a user I wouldn't mind if the software I bought today stays that way forever, and as a developer I wouldn't mind developing software to completion then leaving it as that.

It isn't released yet, but I do have some loyal beta users, so I'm hopeful that some of them will buy the app once the last couple of issues are fixed.

There are a surprising number of "controls engineering only" shops, it's not clear to me how that kind of business works out logistically when so much of the software requires certain kinds performance from the hardware and vice versa.

I have a background in embedded and a couple years ago I built a custom Windows GUI for an Advanced Motion Controls based motion system as a freelance project.

Until your post, I totally forgot that I have a Kollmorgen AKD control with a servomotor in my basement. A customer had sent it to me so I could test some custom hardware I designed for them and I always wanted to see if I could integrate it into my GUI project, but got so busy I completely forgot it was there.

Time to dust off the hardware...

Similarly, with software, I am more likely to purchase desktop software from the MacOS app store. I feel exposed giving my information to a company I may not have heard of before. I do buy a lot of useful looking desktop software on the Mac OS app store.

It must be tough converting enough customers though and pricing is not easy.

Tried to sell it for $5 home / $14 office, but only got a handful of purchases. I still personally use it every day and have probably collect 10k+ Snips across all my computers. I converted the entire program from VB.NET -> C#.NET over a year which burned me out and I've kind of just let it wither due to lack of interest.

I aimed for the "10x better" than free tools, but most people are fine with the Windows Snipping Tool. :shrug:, on to the next project. I recently added an achievement system and a screen Gif capture feature, but haven't found the energy to polish+deploy those.

The Windows store is a total joke. And this must be their third or fourth attempt. It must be quite embarassing for Microsoft.

- Mission Control Plus to enhance macOS' Mission Control: https://fadel.io/missioncontrolplus

- Batteries to see your devices' batteries from your Mac: https://fadel.io/batteries

Between public & private grants and the occasional consulting gig to add a feature or support contract, I can live :)

Tech stack is C++17/20 & Qt, I target Win / Mac / Linux (and mostly develop on Linux).

A lot of applications in the legal realm are like this, I was shocked to find out how many Judges won't allow the usage of wifi in their courtrooms, and that you can be hit with contempt for using the internet during a trial.

That and building applications that are specific to hardware devices, such as fingerprint scanners, and thermal imagining, it could be done via a service and a web front end, but at that point you are doing more work, for no real benefit.

For side-business it'll be a lot tougher than it was when I started 30 years ago.