Some bugs get fixed fast, some don’t (likely because they are caused by much more fundamental parts of the software that can’t easily be rewritten). Some ongoing and much-reported bugs, for instance, concern multiplying “Words read” on the browser, and the occasional inability to finish a lesson (also in the browser). I assume those are hard to give a quick fix to, otherwise they probably would have already been fixed. Other problems are fixed quite quickly, yes.
3 Likes
Yes, to be fair to LingQ, they are far more responsive when it comes to fixing bugs than other apps I have used. Unfortunately some serious bugs remain.
Like many others in the thread, I can’t help but play backseat product manager. So I’ll muse a bit, but with a bit of humility, since I don’t know the team’s situation. And I aim to keep a polite tone that doesn’t land harshly on the ears of some hero dev that has been working 80-hour weeks and is on their last straw.
I would guess they are pretty limited in funds, and have to be very careful in what work they take on. And they have a codebase with some code quality problems. It’s pretty typical with startups, particularly self-funded, to grow out their codebase with features for a while without too many problems. And then the tech debt piles on after some years and the code gets harder to maintain and update. This happens to almost every startup, and is potentially bad when there’s no “second wind” of revenue to throw at problems. If they had the money, then it’s feasible to pay down the tech debt quickly or rewrite large amounts of code.
The thing to do in this situation is to stop adding features and focus for a while on making the product be a good user experience with fewer bugs and lower future costs to adding features. In fact, you might remove features that aren’t very popular or strategic. Especially if these features have a lot of tech debt and are a clear maintenance burden.
As a pretend product manager, the AI features scare me a bit, because they have high transaction cost and LingQ offers a flat-rate lifetime license. So a popular AI-based feature (simplify lesson) could drown the company in costs. I would definitely have some strategy here, e.g. put AI features on a separate tier like they did for tutoring, or use an OAuth scheme with OpenAI to call the inference endpoint using the user’s OpenAI billing.
The Reader seems like the heart and soul of the product, but it has some bugs. I honestly don’t think it’s too bad. But the bugs I see in the Reader seem shallow and maybe relatively easy to fix.
SRS - maybe remove it. Or at least stop adding more functionality to it. I’ve heard many accounts of people not wanting to use it. I gave up on it too–using input for review works better. SRS/vocabulary review even seems to go against Steve Kaufmann’s learning recommendations. I would have had a better starting experience without SRS seeming like something I needed to do.
Other ideas - What if there wasn’t an import because we don’t need an import? Suppose the “reader” were just a browser extension that called LingQ APIs and provided some overlay for viewing translations, word status. (Same architecture as Rooster’s plugins, I believe) Then you just browse wherever you like, Medium, BBC, Amazon, and read the content within the other website. This allows viewing illustrations and other images within the content. Removing import would also reduce server costs and avoid legal risks around copyrighted content appearing on LingQ without permission.
I’d also invest in CI/CD with test automation to catch major bugs before they deploy. It’s not a realistic goal for most SAAS to aim for zero bugs. CI/CD is just a relatively cheap way to find most of the bad ones before releasing. There is upfront cost to set up build pipelines and write test automation. There is a constant recurring cost on writing test automation with new feature code, but you don’t need manual test passes on each release.
If the strategy is to encourage development like Rooster’s on tools that integrate with the LingQ API, it could be a good investment to document/version the API to encourage that “free” development. I do think LingQ is well-positioned as a kind of data hub for language learning. If I were writing a new language learning app, I would be keen to have the backend part already handled. Add a referral program or revenue-sharing plan for developers, and that could unlock a different kind of marketing.
Okay, that’s too much typing. Better stop now.
3 Likes
Speaking as an ex software engineer, you’ve made some good points. However I will point out that very few companies and freeware developers produce browser extensions that work on an iPad, and that’s because iOS is locked down tight. I’ve written iOS apps but not browser extensions, so I don’t know how hard it is to do.
1 Like
Yeah, I have to admit, I know little about browser extension development. Maybe that particular idea has problems for iOS, as you say.
1 Like
From what I understand, the GPT related features are quite cheap. the generated audio (especially Narakeet voices) and DeepL translate are not. I agree that there should be some sort of limits to stop abuse.
It seems browser extensions can be converted quite easily. Although you need a Mac device to work on it / deploy.
3 Likes
I’ve developed iOS apps using a virtual Mac on my PC. It is a bit tedious but it works. Unfortunately I would have had to pay £100 a year for my app to be hosted in the App Store, and since it was a utility for my own use, I didn’t bother.
If it’s so easy to do, it makes me wonder why companies don’t create iOS browser extensions. I wanted to use that app that lets the user watch Netflix videos with language learning support, but they have no iOS browser extension.