Well... I've always believed that a good go to market should be extremely multi channel with paid being gravy anyway. I think DigitalOcean was successful because we did a combination of: Actually useful content marketing + being where your customer actually is (so attend&host event/conferences etc) + genuine community outreach and interest in what your customer base is all about (I spent time every day during DO on HN making sure if anyone had a problem it was solved) + for devtools (at least back in my day) I think supporting OSS meaningfully was also incredibly important. To a degree in DevTools, DevRel can basically be the same as paid influencers, I had Mikeal Rogers (rest in peace) working for me and his mission was "Do whatever you want as long as it's net positive to the nodejs community, have fun!" so I guess "paying influencers" can mean few diff things. With youtube a lot of people use sponsor blockers now too so paying someone to shill your shit in the middle of their video is probably not as effective as it once was, tho I doubt the sponsor blocks are as widespread as ad blockers.
If you're just getting started I think the best thing you can do by a mile is just attend conferences/events where your ICP is and try to bootstrap PLG with it.
This question is asked often, and the answer is always that it depends on who your audience is. Channels that work for one person might fail for you, and vice versa. Every product solves a different problem, which means different people who seek out information from different places.
Step 1 is to understand who those people are for your product, and figure out which information sources they trust. As implied above, almost nobody trusts online ads.
Mostly, yes! They use a very specific clay from a producer which went out of business a few years ago. They've bought up all the stock they can and use that clay for pretty much all of the character puppets, along with other materials. There was a great documentary on the BBC a couple of years back which went behind the scenes and talked about how they make and use the puppets.
This seems a lot like Cloudflare OS (https://blog.cloudflare.com/cloudflare-os/). Is that a fair comparison? If so I'd be keen to understand how this differs aside from not being baked into the Cloudflare estate.
Fair comparisons. Paperclip does the org chart and the orchestration but it depends on other runtimes to actually run the agents. OtoDock also runs on Claude Code and Codex, the difference is the agents run inside it, as persistent processes in a sandbox on your server. Or also you can pair one of your machines with one command and you make any agent run on it with its tools and files synced to the platform, with automatic fall back to the server when the machine is offline. Cloudflare OS I only know from their post, so I cannot compare it properly yet.
Of course! I don't see how anyone could expect to excel at a craft without also studying the work of others.
This is where AI concerns me for people who are juniors in their field (software or otherwise). You get quick answers which don't help with learning, and it's very easy to never read the code. It's like a very tempting drug that stunts growth but feels like progress.
I'm a hands on engineering leader for a team of about 20 engineers and I've been spending the past 6 months trying to get my team to understand just this.
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.
Out of curiosity, what was the path that the engineers have been taking? The limiting communication between agents to my mind is obvious to anyone who hasn't swallowed orthodoxy Agile development completely whole. And in my experience the people who have, are rarely the devs. Context switching, between agents, people or whoever, require ramp up time to relearn context. It's always slower and more expensive, other potential upsides about long term training or developers being more replaceable notwithstanding. But no agent gets long term training, not in a 1M context window.
And our in house "Agile Practitioners" (their job title) pushed this to a state where the next four tickets in a task get broken down to four hour long pieces of work go to four different people, regardless of their context or skill set rather than what two years ago was what one person just owned and did in a day. Work in progress is minimized by the metrics, but it doubled the overall man hours. And the Ops Director gets promoted on that WIP metric while half the team quit citing the changes due to the added communication burden and lack of ownership.
I'm thinking some people are approaching agentic development in the same manner, splitting work up across agents too aggressively, giving each agent new context/upfront plans, when the one session could have done the whole problem in the one context window.
Right, the ultimate context switch is constant pinging and meetings. There’s very little reason to have engineers be in 5+ meetings a day. But at a lot of orgs, they are, and that’s an extreme context switch cost 5x a day. It’s different if it’s a purely technical meeting about the problem you’re solving right now, but they’re typically not.
In the few instances that I’ve been able to see a total stranger prompt a model, I learn a lot about them.
The model output is fairly uniform because the models are fairly uniform, but the input is how I understand the prompter’s theory of mind for the LLM.
The higher fidelity the theory of mind, the more productive the resulting conversation is. Basic things, like knowing what the model is even aware of.
It’s okay at subjective product judgements with limited context, and so the best engineers make the most important decisions themselves, constraining the model’s solution space to something looking like success.
Maintaining consistent progress towards a common goal with a bunch of different perspectives is the job.
I've been using elixir professionally and for hobby work for the past 7 years now. Language models are damn good at it, and have been for some time.
The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.
That assumes that they do actually believe it's a mistake. They didn't explain the reasons they've gone for this architecture in much/any detail. I'd be interested in hearing them talk more about that in the future.
Perhaps you or I would make a different decision based on the aims that lead them there. But there isn't enough information to say whether or not their decision was a mistake, even if it has lead to a peculiar bug. It may be perfectly legitimate and we just don't know some of the constraints they had.
Right, the point is it's a kind of elephant in the room - they even allude to it not being a common use case - but they say nothing about the rationale. That leads me to suspect it was a kind of "seemed like a good idea at the time" situation.
They also touch on this when they say that it worked for them for a long time.
This is a pretty classic symptom of a system that was designed a certain way early on and then runs into issues as the system grows.
One can argue that this was due to a bug, but it's a bug that they shouldn't really have had to deal with - a consequence that the design opened them up to.
This is also my view. These sorts of roles can have a very high impact and be very successful if everyone feels like they're rowing in the same direction.
The people in those roles need make people feel like there is value in seeking their input. They also need to find ways to say yes that helps things happen in the right way, rather than stopping them entirely.
This happens naturally in organisations where security is valued by everyone. InfoSec / CIO roles can operate very successfully and deliver a lot of value. As soon as people lose faith and see them as the "no" team, they start trying to hide from them.
There are lots of ways to create this but it's as much about the people in the role, as it about the organisation itself. If either are skeptical about the other, it falls apart very quickly.
The first is a piece of small charity / business governance tech. I'm a trustee of a small charity in the UK, and my wife has been a senior leader of one in the past as well. All the governance tools are super expensive and aimed at businesses with large boards. They're not very suitable for smaller charities who just need something to help them maintain and publish policies, track key structure changes, and governances cycles.
So I'm working on a small bit of SaaS which helps those organisations to stay organised, and walk them through particular processes. The two big benefits are:
1. An audit log of all actions taken across policies, risk registers, board member terms, key information submissions, etc. So you can always see who did what when.
2. A calendar + reminder system which does things like prompt the Chair when someone's term is coming to an end, and auto-populates upcoming meeting agendas.
It's been useful for the charity I work with, I don't really expect it to be a big thing but the hosting cost of ~£40 a month is already saving me a lot of time. I'd like to see if I can get it in use by a couple of other organisations though.
---
The other is a data toolkit for UK secondary schools. We have quite a complex way of assessing a schools outcomes for students called "Progress 8". The spec for it is published by the DfE, but there isn't really a tool out there which will do the calculations so a lot of schools either work from complex spreadsheets or wait for the DfE's announcements with the league tables.
My father is a Director of Schools Performance at a Multi-Academy Trust and this seemed like something we could pair up on. He's got a very comprehensive spreadsheet which does the initial calculations, and some continued analysis but it's not very easy to use and making tweaks can take days.
I put together a prototype project which would take in a csv of pupil results and spit out all the Attainment 8 and Progress 8 results. The next step is to wrap it up into a nice web app, and do further analysis. I'd like a school to be able to see things like the Marginal Contribution of each subject and such.
Again, this isn't something I expect to sell to many people. Schools in the UK have no money going spare right now, but it's been a fun venture into the world of data.
I'm not sure the star count means much these days. Regardless, the tool seems interesting. Thanks for adding the videos into the readme as well, it seems quite polished from those - although I've not tried it out myself.
Two reasons really. First, there have been instances of bot networks allowing people to buy stars on their repos. This was more common back a few years ago but I'm sure they still operate.
Second, stars don't denote usage or downloading of the code or app. Lots of people use them more as bookmarks which show interest but not much more.
I think if you go back a few years people really did think of GitHub stars as some kind of social proof. That seems to have largely come back around now, and while it's a sign that the project has some attention, there are better ways to see that it is active.
None of that is to devalue the work you've done. It does look like a nice and well thought through application.
But the thing you said donnot experience why you so not wana try out the app.
And if you really wana see the proof like that people are using the app that i only have the download of the file and reddit users feature requests
I as a developer wants to know why you do not want to try out the app so I can improve
reply