The OpenClaw form factor of using a chatbot to orchestrate sessions seems to be working for folks, based on what they're saying atleast.

Simon Willison talks about using Claude Code for Web, which shows up on the phone app to code on the go from his phone. He's got some useful notes on his blog: https://simonwillison.net/2025/Oct/20/claude-code-for-web/

My 2 cents: Try the OOTB options to get a feel for the ergonomics that suit you best, then vibe code something that works for you.

Not every project needs to have Github as a dependency. Its added overhead and coordination work that isn't needed for every job.

YMMV, and I get it if you're in a commercial/professional environment, but if you're a solo dev or a small team, then IMO Github doesn't need to be a part of your orchestration (setup project, issue CRUD, pr, etc), just state sync/distribution.

Agents can use local trackers as drop-ins to GH and have similar commands provided to do the same job.

Its fewer moving parts, and more forgiving as you can fix things locally, before pushing out to GH or your Git server of choice.

I agree with OP that beads has great primitives, but I think its become a bit unwieldy in trying to becoming something "everyone" including larger teams can use.

Going to try Ticket out, though personally I prefer JSONL to MD for this kind of tracking, since I find that Claude finds a good concise balance of detail on its own when writing to JSONL vs Markdown files where it tends to be verbose.

While a Chrome Extension (not a standalone app), it does a fabulous job of recording system audio and input, and also gives a ton of additional features like annotations, etc.

Records to localstorage, and lets you export to a variety of 3rd party platforms (I can't remember if S3 is supported OOTB, but that shouldn't be too hard).

I've used it mainly with GDrive, as most of our team lives there, so this has been a seamless way to store and share videos without lock-in at Loom.

I recommend this to most folks who need a quick way to replace Loom, and even meeting recorder tools.

NGL it took time to get used to it. Being an ex-founder, it was doubly difficult as not only did I have less agency than I was used to (and frankly expected), I was also no longer on an equal footing to my friend. This led to some friction and disagreements of how things should be done, but at the end of the day, it came down to perspective differences as a founder and as an employee, and I learned to make with peace with the fact it was his company, and not mine.

In retrospect, I think the fact that we were friends first, and had spoken a lot as fellow founders beforehand, made it harder to align expectations in this dynamic. Thankfully, we parted on good terms, and I'm still helping them out as a consultant, which feels like a nice middle ground for me.

That said, I'm not looking to jump back into something like this anytime soon.

If I do however, I would definitely go into any future engagement with more tempered expectations of what I'm there to for, and what I want out of it.

As obvious as it sounds, a lot of things can be taken for granted due to the prior relationship (on both sides), and its important to lay out as much of your thoughts and expectations upfront, so that there is as little ambiguity and misunderstandings down the line. No detail is too trivial, especially around compensation, and its important to recognize and remember that you're there to do a job, not just helping out a friend, which is how the conversation usually starts.

This whole thing has taught me a lot about handling that balance, and a lot more about myself as well.

Do you have any references that you could point me to on how to get Sveltekit running to build Chrome extensions?

Sorry for the digression, but this has been a bit of a bugbear for the past month and would dearly love to know how to get around it.

It's lighter and a narrower footprint, but builds on JS fundamentals while introducing core concepts of component frameworks.

This allows you to build on these concepts like stores, hooks, actions, etc. which all have equivalents in other frameworks as well.

Transitioning beyond this to other frameworks is by choice but the foundation is more or less the same.

Personally, I found the transition between Vue and Svelte more intuitive, but only real difference I found between React and Vue/Svelte is JSX syntax and getting to grips with a few of its idiosyncracies.

And Svelte's tutorial and learning ecosystem is by far the best I've experienced so far.

Hope this helps.

There are a few use-cases where you'd want the ability to have a managed/hosted vanilla Mongo setup vs an emulated experience.

Atlas is a virtual monopoly for Mongo solely due to SSPL, and it has created a ridiculously overpriced ecosystem for hosted and managed services, and tooling around it.

Parking the technical merits to one side, considering the sheer number of devs and early-stage products that are built on Mongo, I'd love for someone to go after them next.

The trust is fundamentally broken, so it's not really worthwhile to pursue this as collaborators. Unless you're keen to run the business yourself, there isn't much point in fighting this beyond getting your 1st year vesting.

It's honestly not worth your time and energy fighting for something you're not keen to do. And it's definitely cheaper for them to give you 7% more than the 3% offered, and avoid all this hassle and potential legal expense.

If you do want to persist, then you need the investor on your side, as otherwise you can't force the other person out (they'd still keep their 10% but that's the price you pay for that move).

I have to say I find it really odd that someone who's invested $100k is being silent on this, or isn't worried about this situation, especially if the future of the business is now more of a lifestyle business. I fail to see how they'd get a return they'd expect. I'd assume they're actually on the other side, but want to appear neutral.

FWIW if you end up leaving, I'd advise not agreeing to a non-compete or a non-disclosure. It's not about you starting a competitor, but more about them not being able to restrict your future options as they're forcing you out, and they will have to potentially consider the threat of you competing with them at any point in the future.

It's a credit to your efforts that you've built the tech of business that's gotten such good traction and numbers, so you've got learnings and experience that will serve you in good stead in the future.

It's just unfortunate that you ended up with such shitty partners.

Good luck, and I assume quite a few of us will be hoping you bounce back from this, and rooting for you.

I'm really looking forward to the breakdown of much of what has been teased here.

Top of mind: Is Postal the self-hosted transactional mail server (https://github.com/postalhq/postal)? Been looking at using this for an idea, and wanted to know if there are any obvious gotchas to look out for.

BTW your verification email is landing up in spam in Gmail.

The cloud deployment AFAIK would allow for better multi-tenant management, and SaaSifying the management experience.

From personal experience, running the controller on a Pi in your home network is good enough for most scenarios. Plus if you want to customize, you can poke around the APIs and wire up what you want. It's pretty powerful once you get the hang of it, and there are some fabulous libraries available thanks to community contributions on Github.

In our case, we ended up using Mikrotik devices for our physical layers and Unifi as our APs. So far, the performance of the Wifi devices is excellent (though tuning high density configs was a bit of a pain), and the Mikrotiks give us exceptional control over the behaviour of the network topology.

Playing to the strengths of each vendor was the way to go for us. Worked out way cheaper as well.

We would buffer/pause video based on the video player state of the slowest connection, and still allow users to manually control playback.

Fun app, and a great example of the versatility of XMPP.

Finding people is the hard part for us as a business, so finding a balance between technology and available skills was a priority. Since Meteor is a public framework, it has a ready ecosystem for onboarding (tutorials, etc), plus with being standardized it reduces complexity for onboarding. Any JS dev can pick it up in a few weeks. It has enough checks and balances to ensure some level of consistency in implementation, but beyond that, you need to setup your own process anyway. Again being standardized, it helps with BCP as well.

Since Meteor is isomorphic, it gives us a very interesting advantage of tying code ownership to both front and backend code, which results in functional ownership not just code ownership. That emphasizes full-stack development, which is a priority for us. Our mantra is to do more with few people as we can, and Meteor lets us do that very well.

Technologically, Meteor gives us access to a wide variety of capabilities as a technology team. NPM opens up the JS ecosystem, Apollo/MDG gives us the ability to move towards GraphQL if needed, build tools allows us to push code for web and mobile environments out-of-the-box, integrations allow us to handle scaling, and Meteor has gotten better at opening up options to allow for more granular tuning (queries, reactivity, etc.).

It might not be the most performant, but honestly I'd rather throw an extra $50-100/m at hardware on DO/Linode, than justify having to hire more people.

It helps that we're not planning at building apps targeted at millions of users, but when you hit that kind of scale, refactoring is anyway going to happen. This quote from DHH (https://twitter.com/dhh/status/885445986943868929) is the best way to explain this anyway :)

As has been highlighted by others, MDG is still releasing updates to Meteor regularly, so there's not much reason to doubt they're stopping anytime soon. In addition, there's been a resurgence in the community to contribute modules to addressing gaps in the ecosystem, which have made Meteor more relevant again for a lot of us.

This is highly opinionated, but for us and the fact that its about doing business, not just the best technology, Meteor ticks enough boxes to make it our choice moving forward.

If you look at it through that lens, I think it makes it viable (valuable even) in 2018.

IMO, I think Meteor is a victim of promising too much too soon. The real value only got unlocked IMO when they made NPM a first-class citizen. As a team, we aren't really missing out on anything being on Meteor. We think it makes us more effective as developers.