Death by business model. The company was based on the concept that existing regulations and design constraints were overly conservative, and their customers paid the price.
Google Workspace tools, like Google Meet, can automatically transcribe the meeting, and then you can use AI (Gemini) to summarize and generate searchable minutes.
These days it is trivial to record the meeting and have it transcribed and then summarized by an LLM to produce "automatic" minutes. Searchability is a bonus.
Definitely. I'd much rather have people put in a smart 4 hours, then more hours. The older I get, the smarter I work, and the fewer hours it takes to get more done.
Why not have a standard section in every successful paper that covers all of the null results that led up to the successful conclusion? There are lots of standard sections. Seems easy to add a requirement for the failures that led to the success. Many papers already include tips, tricks and gotchas, perhaps we just need to formalize this a bit more. Seems much easier than trying to find a way to get people to publish full papers on null results.
This approach has worked for me, and many others. Read the Lean Startup for the general approach, and The Mom Test to learn how to talk to prospective customers. The main point is that you need to talk to customers and work with them throughout the process.
Childish. And, of course they must have known there was an official LLM cohort taking the real test, and they probably even knew that Gemini got a gold medal, and may have even known that Google planned a press release for today.
You learn where your customers hang out, and then you hang out there and authentically become part of the social group. You spend weeks/months/years learning what they like, their workflows, and their problems. Or, better, you've already spent years working with your customers so you have some experience in these matters. Then you spend more time setting up face-to-face discussions, at conferences, online, or wherever they hang out, *not* trying to shill, but honestly and authentically trying to learn what they need.
It may take dozens or hundreds of attempts, and then you find a small group, maybe a half dozen or so, that are early adopters, willing to live with your experiments and provide feedback. Work with them to hone the value proposition, and learn how to communicate it effectively. Tweak or pivot the product to fit their needs, often for many more months.
There is no simple solution that involves making a few social media posts, or paying for advertisements, or spamming people with email. Everything that actually works takes lots of personal time and energy.
The biggest problem I have, is that, even though I know from experience that I should talk to customers to understand their problems and build a solution that provides them value, and spend time talking to them to understand the value proposition, how to communicate it, and how it fits into their workflow, I don't enjoy those bits, and I prefer to just code things I want to build. I prefer to willfully delude myself into thinking that the thing I want to build is something other people will want to pay for. Oh, wait, and I prefer not to charge people and not to sell ads. So there's that too. Am I doing this right?
Stop comparing yourself to stories you read in the media. Actually, stop comparing yourself to others pretty much all the time. Media just makes it worse by telling whatever story they are interested in.
So that kind of violates the principles of the local first software since you still need the cloud and license key in order to run the app. It also means more work for the developer, since they have no other reason to provide a server in most cases. It also means that they need to have logins which are not actually necessary for local first software and one of the benefits. Not so easy.
Subscription models are associated with SaaS because you're selling a service. The service is typically storing your data or providing capabilities on the back end. With a local first app, the company is not paying for back-end resources, so there's a mismatch between the expectations of customers who are actually providing the resources on their own computer, and the desires of the company to make money.
Where do you check their subscription in order to cut off the service when they stop paying? One of the nice bits about local first is that there's no need for logins. Do you install security software in your local first app, which, typically, includes the code in a format that's fairly easy to bypass? Pirating desktop software was a big issue for companies. Are we going back to that horrible world?
With true local first software, there is no backend. Sometimes there's a static host that just delivers the code, but has no endpoints. Providing the code, or the extension, is not a service that the customer cares about. It's not for the customer. That's for the developer.
Sure, you can try it charge subscriptions, but what are you actually charging for? You're not storing any of the customer's data or providing a service that they need, since the software should work entirely without your help. Fundamentally charging a subscription without having a centralized server is pretty tricky. Even the traditional desktop apps that transitioned to the cloud, like Photoshop or Maya, have really worked hard to beef up their cloud-based service to justify the subscription fee. A mismatch between your business model and your technical infrastructure is not going to stand up well over time. Don't get me wrong. I'm just trying to figure out what business model works for local-first software?
So your primary technical goal is to do local first, and you keep the cloud because it provides a business model that works? That feels very brittle. The way you're describing it, local first is an optional additional element for a cloud-based tool. I don't think that's the primary intent of the local first movement.
And, we are not managing the LLMs. We are communicating with them. The better a developer gets it communication in general, the easier their life will be in the better job they will do for their company. The more they understand about what their customers need, the better job they will do building those tools. None of this is about managing. It's about learning how to communicate, how to ask the right questions and how to listen.
You are experiencing the Dunning-Kruger effect of using AI. You used it enough to think you understand it, but not enough to really know how to use it well. That's okay, since even if you try and ignore and avoid it for now, eventually you'll have enough experience to understand how to use it well. Like any tool, the better you understand it and the better you understand the problems you're trying to solve, the better job you will do. Give an AI to a product manager and their code will be shit. Give it to a good programmer, and they're likely to ask the right questions and verify the code a little bit more so they get better results.