I make a Mac app targeted at developers and sell around 150k euro worth of licenses a year. It's been my only income for the last ten years or so. 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.
Would you mind sharing more details regarding your application?
Ask HN: Anyone making a living building desktop applications?
301–310 of 361 posts
Re: Ask HN: Anyone making a living building desktop applications?
#302I'm glad someone is making money. I'm not. I spent 5 years writing a unified workflow for folks writing a research paper/thesis/dissertation (Epiphany Workflow, Apple's App Store). 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 sec…
Re: Ask HN: Anyone making a living building desktop applications?
#303I'm glad someone is making money. I'm not. I spent 5 years writing a unified workflow for folks writing a research paper/thesis/dissertation (Epiphany Workflow, Apple's App Store). 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 sec…
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.
Re: Ask HN: Anyone making a living building desktop applications?
#304Re: Ask HN: Anyone making a living building desktop applications?
#305Earlier quoted context omitted.
Are you writing drivers for all these printers? Will the operating system printer drivers not suffice?
I’m generally writing drivers for certain USB VIDs (vendors) that all speak the same “language” e.g. Zebra (ZPL), DYMO, Brother, etc. Often their are edge cases for individual USB PIDs (products), and even more granularity based on device status responses e.g. cutter, firmwares, etc. So why not use the device driver? For one, they are often terrible experiences, especially Zebra on macOS, let alone other obscure mode…
Re: Ask HN: Anyone making a living building desktop applications?
#306We sell a desktop app with an involvement in dev and support of about 0.25-0.50 FTE, with revenues in the range of $50K/month although it was launched 9 years ago and the first year was only about $2K/month. The server side is just one Windows 4GB server for user signups, billing and license validation. One good thing of desktop apps is that the server side is so cheap, you are basically selling IP. It has this featu…
This sounds very interesting. Not to give away your company’s magic sauce of course, but if you were starting today, what niche would you target based on what you know?
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.
Re: Ask HN: Anyone making a living building desktop applications?
#307Earlier quoted context omitted.
If you really want to support Kafka, I think there are options. Besides the obvious option of forking the .NET client to add these missing features, you could also write some kind of "plug-in" in Java or Go or some other language with a fully featured client library, and communicate with it over some type of local RPC from your main application to query against Kafka. Whether it is technically feasible or not, it may…
I suppose .Net client has everything that typical Kafka app needs. Just not everything that management app would need. 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 arbitr…
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.
Re: Ask HN: Anyone making a living building desktop applications?
#308Earlier quoted context omitted.
what Microsoft fat client technology are you using? 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.
Yea, I develop a hobby project targeting desktop Mac (Objective C GUI, C++ business logic) and I’m not sure what Windows technology I should use should I ever decide to port to Windows. There are so many and they are all in various stages of unsupported. C#? C++? .NET? Win32? MFC? WPF? XAML? WinForms? UWP? Maybe just give up on trying to read the future and use Qt. Fucking madness!
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.
Re: Ask HN: Anyone making a living building desktop applications?
#309Yes and no. I'm an employee so it doesn't really matter, but my side-project desktop apps pay well enough that I could live off them if I go for a student lifestyle (no pricey events, no restaurants, cooking yourself, cleaning yourself). 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 v…
As a developer mainly on Mac, which windows APIs are you referring to that are new, and how do you normally distribute your app, is it through a Windows store or independently?
Separate store and fastspring.
Re: Ask HN: Anyone making a living building desktop applications?
#310Yes and no. I'm an employee so it doesn't really matter, but my side-project desktop apps pay well enough that I could live off them if I go for a student lifestyle (no pricey events, no restaurants, cooking yourself, cleaning yourself). 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 v…
what Microsoft fat client technology are you using? 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.
Imgui and juce are great frameworks.