Earn enough to pay my bills, don't take up too much of my time and energy (so I can spend it on my own life and projects). Remote only, async bonus - few meetings as possible. Doesn't need to be an engineering-led company, but also don't interfere with them.

For me, purpose, passion, etc come from working with a good team to build the best thing we can. Industry is a bit less relevant, unless it's really low brow stuff.

Sprints, agile, whatever don't matter to me, if it doesn't turn into a grind of the same dumb meeting every day/week where nothing of value is answered.

Product companies over agencies and non-tech companies - with agencies you have to justify your existence constantly (and you're a line item), and non-tech companies just don't understand the work and will undermine you. Product companies are where ideally peace can be found and there's enough stability to grow your career.

D - whenever I feel like buying some at the supermarket

I prefer drier, savoury snacks these days. I get a bag of mixed "luxury" tree nuts (i.e. not just peanuts but cashews almonds etc) and then a much smaller bag of wasabi-coated peanuts and mix those together, and I'll have a handful of that every day or so. The wasabi nuts give it all a nice kick so it's never just one boring flavour.

You are allowed to keep some data for cases like financial stuff etc, not sure on specifics as there are quite a few national privacy laws these days (California's one, GDPR, UK's GDPR, South Africa's POPIA).

The approach to zero out data and anonymise as much as possible is sound - I've done it before for dayjob stuff. It's useful because metrics don't get skewed by data going missing.

Interesting, in my view it's not very much text ha!

I'd like to dig in a bit more if you don't mind: I suppose the view on the amount of text content depends on the purpose of it in your and my view - do you suggest very minimal text to give it more of a "straight to the point" kind of vibe or something else? From my perspective I'm trying to keep it a bit light while still establishing some authority with the customer, and be clear on exactly what they're getting. So it's not exactly a heavy sales page but also not a one-click everything.

On point 3, it will be useful for Hey to contain its own explainers and how it benefits the usage of Hey (or other benefits in general). "Go read over here" doesn't provide the necessary context on your own app in relation to the protocol, which is what is missing here. In other words, I'd say the same thing whether it was Lens, ActivityPub, or any other protocol: users need to see it through the lens (haha) of your app.

First thought: Knowing nothing about the Lens Protocol, why would I use this?

In other words, are you gearing this towards people already in the dapp space or more generally?

Here's my first revision: ns2024test2.carrd.co/

• Clearer product delineation & more detailed descriptions
• Straight to the point
• Pricing in EUR (might change to USD, it's more dependent on which kind of clients I'd like to get)
• Consolidated some of the offerings

Ideas for refinement:
- One thing I'm toying with is potentially trying to ditch calls from the offers altogether - at least, reduce the need for them as much as possible.
- An introduction video from me

Thanks for the feedback! Will definitely move the blocks around a bit.

To be clear, this is explicitly not the same model as DesignJoy. I think he's actually corrupted the "productized service" term a bit, because not all productized services are just subscriptions. See here, as I'm following Jonathan Stark's description: jonathanstark.com/fps

Under that definition, tiers/plans are not applicable. The offering as I'm exploring it is selling individual tasks directly, and that's what the offering list reflects.

One way I've seen recently is that you licence the code as AGPL, which effectively makes it unusable for corporates as they'd need to share their source code to use it. Then sell non-AGPL licences to fund the project. Of course bad actors can just ignore this too.

In terms of an exit, it may be harder yes, at the very least in the sense that you would need to find buyers who understand the why & how of the business model. Not impossible, but outside of tech circles it's not like everyone knows how OSS works.

That being said, you don't have to have it open source in order to offer self-hosting options; it's just convenient. There are plenty of paid developer tools in certain niches that give you licence keys & install instructions on how to do it yourself. Mailcoach is a great example - a 1-year licence costs a little bit more than using their SaaS option at low scale, but if you use it a lot the self-hosting makes sense.

I find ChatGPT good for figuring out issues with tech where the docs and issues are seemingly obscure. MySQL and Docker in particular.

Tried CoPilot on PHPStorm for a month. It was pretty decent, but I felt like I had to spend half my time refactoring away the hallucinated function names.

Cursor looks good, but I'm a Jetbrains guy so I need that sort of interaction on a fully-fledged IDE. VS Code extensions can bring a lot of functionality but it has never felt as cohesive as a purpose-built IDE for me.

Been using DDG for years. I only switch to !g for highly semantic searches or to confirm DDG not finding something (most of the time Goog can't find it either). Kagi seems decent but haven't felt the need to try it yet.