I get your thinking here - free market spots a gap and competes on price. But personally I think this is a "poor" business strategy.
Firstly, competing on price is a race to the bottom. There's always someone who's prepared to offer it for less. And that always means the offering ultimately gets worse over time.
Secondly if you go thus route you attract customers who are "price sensitive". They'll leave you as quickly as they joined for someone who offers a lower price. In other words you are self-selecting the worst possible kind of customer to have.
Thirdly you send a signal regarding quality. A $5 product is obviously worse than a $100 product, because if the $5 -could- charge more they -would-.
(Hint: for VC funded companies the customer I the VC NOT the person paying a subscription. So be careful comparing your pricing to VC company pricing if you are not VC funded.)
Yes, look for pain. If you make something good charge more, not less, than incumbents. Build a customer base of people who are quality sensitive not price sensitive.
30 years ago I had a product on the market at $199. It sold well, validating the market space. A not-quite-as-good competitor appeared for $99. He made some sales. I was tempted to reduce my price. An old head told me otherwise. Sales wise we'd say things like "you get what you pay for". We outsold the new-guy. Which meant we had lots more revenue for support, docs, polish and so on. Today we charge $399. The competitor folded after a couple years.
We aimed high, charged a lot, and focused on delivering quality. We attracted loyal customers who appreciated quality more than a few $ saving. 30 years, and 50 products later, we continue to dominate our space.
Firstly, writing the code is perhaps only 10% of the product cost (over its lifetime.) Support, marketing, adjusting, debugging, handling edge cases and so on are where most of the costs lie.
In my case brighter folks than me wrote very good code in the same space. But taking working ode and turning it into a generic product is a lot of work.
Think of it like building a landing strip for your plane. If you're the only one landing there, then the specs are simple, and tight. You need little more than a grader and a building big enough for your plane. But if you're building an airport (think, say, JFK) you have to cater for everything from a Cessna to a Dreamlifter.
A LLM can certainly speed things along. But I wouldn't want to build based on LLM foundations. Long term support and maintainability would scare me.
This isn’t really a problem a developer can fix, if you’re fishing for ideas. The problem exists with the content owners and competition based on exclusive content.
Shutterstock is $1500/yr per seat for level I use, with frustrating UX in search function and now you have to pay for a subscription, and then pay even MORE if you want to use anything they deem to be "highly desirable" like Amazon. Oh you have a subscription? Well to get access to what you see here you have to subscribe even more. They added AI content which is chock full of AI slop and copyright issues which clearly isn't being moderated. They also have a ton of vector files which werent checked at all because they're just JPGs saved in vector containers, making them pretty much unusable. Also suffer frequent outrages/download issues that take hours to resolve which clearly is an issue when people have deadlines.
I fail to see how choosing to pay for a Spicy Autocomplete service relates to using open source software?
I use them to watch for changes in German laws and other changes that affect my work.
I wish there was a better, faster way to catch changes to a specific part of a page. The tools are expensive, clunky and not all that reliable.
Which tools do you use right now for this?
How often should a new tool check for changes? Does it have to be every hour or minute, or can it be once a day, or once a week, maybe?
In my case, once a month is fine.