Nice to hear there are more people out there doing this :)

I'm currently developing a very specialized desktop application for a laboratory and it has been an amazing experience. Working closely together with your users means you get to prioritize what really matters and that you can clearly see the effect of your software in people's lives (in this case, at least 5x increase in productivity and a more healthy distribution of work). I especially enjoy demo time, because I see the enthusiasm in the faces of my customers. It can be tough, though, establishing your reputation at the beginning.

My only experience using really expensive software comes from the academic biotech sector, in which (for a while) there was a thriving high-end software business, with research groups paying $10K+ for a limited license for DNA sequencing and analysis software, and also software that came packaged with instrumentation, things like mass spectrometers, that cost $100K+.

The stand-alone software for DNA analysis has been mostly replaced by free open-source Python packages written by researchers who didn't want to pay the high fees or deal with things like distributing HASP dongles etc.

On the other hand, writing the software that comes packaged with expensive instrumentation, and that's optimized for that instrumentation, remains a viable business. The cost is bundled into the overall cost of the instrumentation setup. A research group/university that buys such instrumentation expects it to be supported over time, and so that's where low volume high end software production is not really going to change. The software is so closely integrated with the hardware, and software failure has such serious consequences, that there's no way FOSS could ever work in that situation. This is as you say a more business-to-business situation.

> from the academic biotech sector

Yes, academics will rewrite proprietary software. Collaborating is what they do, and Free Software is done basically the same way they do everything. They would rewrite it if it was free too.

Business will have a harder time doing the same.

The business opportunity is in software that's inseparable from the hardware. Academics won't work on that because they don't do product development.

Coming from that exact same domain. I still see a little risk: I used to use a specialized image analysis software for microscopy coming with the instrument and the software was hitting its limits mainly because it was running locally. We started using third party software or even developed our own software and were going to buy fewer license from the instrument manufacturer. Of course instrument controls waa a thing, but also this: if not integrated these instruments are getting harder to sell.

What I am trying to say is that even these software business model tied to the instruments are no a guarantee anymore.

Similarly, the article doesn't take into account the fact that many developers work on in-house software and developer tooling that are not directly sold to anyone.

Custom in-house development follows much the same principle as B2B products: the very high marginal cost are considered worth it by the business because of the degree of specialization they need or the advantage they gain over the competition.

Of course I won't become billionaire off it but it's not for the lack of "value" I'm creating.

Caveat here is that you need to be a sufficiently large shop for this to pan out. Need the economies of scale on your side.

I've seen several times smaller organizations attempting to adopt this model (because Google does it or whatever), with the result of the tools team being an enormous bottleneck for the organization.

Not really, it depends on the tool. I wrote a lot of tooling at my last job: ISTR there were about 15 people when I started and a bit over 30 when I left five years later.

For example one tool took about 3 weeks to get to a usable state but it sped up a production task that previously took one person 15 minutes to the same task being done in parallel over 5 units and taking a total of 3 minutes and still only required one person. At our typical sales volumes, it was a no-brainer: my time was paid for by the end of the next month.

In pretty much any small manufacturing/processing shop there are lots of little wins like this.

I am an individual contributor, decently paid at a medium size business. I developed warehouse management systems, inventory managers etc. Very small team and projects have been quite successful.

Do other teams depend on your work?

I've run into like "the build system team", where the build system was some patchwork of hacks that never quite worked, and was also completely opaque to those who used it. The cycle was

1. Try to do something

2. Encounter a build problem

3. Talk to the build system guys, they promise to look into it fast

4. Twiddle your thumbs for a week while the entire team is blocked

5. Goto 1

I actually had this as a planned footnote in the article, then cut it because I haven’t added support for footnotes yet lol

Footnotes(1) not supported?

(1) This is a footnote. You don't need any fancy software to write a footnote.

The best footnotes I've found provide nice bidirectional linking for easily jumping to / back from the footnote so that it disrupts the reading as little as possible.

The beautiful / fun part about having a blog is that it's your own little garden: you can adjust things just like how you see fit, and footnotes were just a case where I figured I'd do without until I could implement it in a way I was happy with.

Have you considered the very low-tech solution of simple HTML anchors to link back and forth?

Definitely! That's what my goal implementation will be compiled to, anyway. I use Hugo, a Go static site generator, to build the markdown posts into the site. Adding footnotes is just a matter of figuring out how to use the right syntax in the markdown, output the right anchors in the HTML, then sprinkling a little CSS on top.

I'm 99% sure Hugo can do this, I've just learned to be wary of putting things in between myself and actually hitting the damn publish button.

Hugo Markdown guide says yes: https://www.markdownguide.org/tools/hugo/

With link to syntax: https://www.markdownguide.org/extended-syntax/#footnotes

May I suggest you add "footnotes on hover"? I feel like this is the ultimate expression of the idea, and books would do it that way if they could.

Hover is a great experience on desktop, but it annoyingly requires having a separate solution for mobile. Right now 60+% of the traffic on the site is from mobile devices, so figuring out something (hopefully simple and very lightweight) that works for both mobile and desktop is the goal.

Your suggestion is noted, though!

Along these lines, I've always liked the system Randall uses for What If: https://what-if.xkcd.com/

Agreed. I've pinched his popup implementation for my homepage and expanded it a little so that there's both a footnotes section with anchor links at the bottom for non-JS use and search engines, as well as the popup panels. E.g. https://www.buttercookie.de/The%20Burkiss%20Way/Transcripts/...

Oh thanks, I really like this variant. It needs a name: click-to-hover, perhaps?

How to sell software and earn a million:

  1 x $1,000,000
  10 x $100,000
  100 x $10,000
  And so on

I agree with you, low volume doesn't mean anything.

when you have 1 x $1,000,000 customer, they dictate your terms. When you have 1,000,000 x $1 customers, you dictate the terms.

It's why you don't see any trillion dollar company who does custom software.

The entire point of doing business is to give the customer what they want so we get paid.

The competitive advantage we exercise today is an architecture/process which allows for us to deliver a customized product experience to all of our customers. We de-skilled a vast majority of the implementation & support activities around our product so that domain experts can operate much more directly with the configuration throughout.

Ditto! B2B is alive and well. I absolutely prefer it because it's a far more rational interaction and sales process. Margins can be higher and it's a better class of customers most of the time.

> Being in the business of low volume software is fantastic if your customers are other businesses.

And governments ( local, state, federal ). Security software ( network, dbs, servers, etc ) along with support can be quite expensive. Niche software to meet regulations ( especially in finance but I'm sure in other industries as well ) can be quite lucrative. Not everything has to be bulk or ads.

Agree.

The "only" major problem is this space is that you need to be "connected" in ways that the most anonymous mass-market products not.

Also, is easier to get into nasty competition, corruption and all that stuff.

Is not always, and you can get good customers being decent, but are problems more prevalents on the space, and is VERY important you NAIL your contracts.

The first time the gorilla (like government!) come for you, is nerve cracking! And you can't shield behind "social media" to get out!

> SQLite vs nightmare distributed abominations

Don't see the benefit of using SQLite over a RDMS like MySQL or Postgres, especially if users are still in the tens of thousands.

> especially if users are still in the tens of thousands

I've got unit tests over business methods backed by SQLite that say otherwise.

The biggest benefit with SQLite is being able to ship your customers 1 self-contained binary distribution that "just works". Anything beyond this and we are talking about nasty customer-owned database instances or us shipping docker containers and hoping the gigantic abstraction bubble doesnt pop on us.

I've shipped multiple products that are backed by a SQLite database for core functionality (authentication, billing, and permissions mostly), and individual SQLite databases for customer data.

It has made it incredibly simple to downgrade and delete customer data when they request. The application kills the billing profile, and emails the administrative email for the organization a link to download and delete their data.

> Your users can actually be trained and held accountable

What does it mean to hold a user accountable?

Not the OP, but also selling B2B software. You can hold a user accountable that they'll actually use the software purchased. The company is spending a lot of money on it, finds value in it, and wants to ensure it's being used and implemented correctly.

B2B software with figures like the OP means you're building a professional relationship with a customer (as opposed to a transactional one), and can push back when they're complaining about something, for example.

> "Your software isn't giving us the numbers you said it would!"

> "It will, if you use it as you were instructed, we're happy to review that with you again, but you have to have the internal SOP that you'll use it in the way it was intended if you want the numbers it can provide."

Also, users are sometimes simply ordered, by their bosses or IT, not to press buttons in ways that are known to break the software. This is sometimes considered cheaper than fixing bugs, or at the very least, mitigates the problem until the next scheduled deployment window. It’s a very different world.

Very true, but I'd paraphrase it more positively: If the deployment cycle is long/complicated/expensive enough, everyone is happy if a whack workaround exists and it's not breaking everything. Not all bugs are actually critical and have to be solved the next day.

And I'm saying this a developer, where we would (and have) gladly sometimes fixed the bug during the 1h call with the customer, but until it was being rolled out... weeks, maybe months.

For our product, a user not using our software properly would be like any arbitrary office worker incorrectly using Microsoft Word.

At some level, it is still our responsibility to provide a reasonable UX (and we have weekly meetings with our customers about this). But, our customers are also fully aware of the various contractual obligations and take ownership of problems caused by poor training or hires on their end.

Mostly for support. Companies give trainings on using B2B software so if users are coming with basic questions you can push back to company contact/manager/buyer with: "wtf" your people are trained on using application. Rise the support fee or sell additional training.

For B2C you cannot have any expectations, even if user knows how to use computer or understands basic English or has good enough eyesight to read any text on your site.

Well what we see for B2C companies is usually that they just don't care and you don't get any real support but that is a different discussion :)

I’d love to know what you build!