This resonates a lot. We’ve seen that a single “static” setup rarely survives once teams move from early traction to real scale.

What’s interesting here is how you’re letting intent drive structure instead of forcing users into one workflow. On the infra side, we notice a similar pattern: early flexibility boosts speed, but once usage grows, observability and failure boundaries become the real bottleneck.

Curious how you’re thinking about edge cases where user intent shifts mid-session—do you reclassify continuously or lock the UI once a path is chosen?

Good point, currently if user intent classified as DIY and because it take more time to process the plan and the products, I added a button during process to cancel that will disregard the DIY path and simply return only the products. There is also follow up with context and can update the results and UI as well, but still finetuning these hard turns from DIY to shopping and vice versa.

This really resonates. Long-term maintenance, reliability, and staying useful over years is the hardest part of building software — and often the most overlooked. Respect for prioritizing sustainability over hype. That mindset is what actually creates real products.

In my experience, the biggest weekly time sink tends to be work that sits between teams rather than inside a single system. Things like manually reconciling data between billing, support, and ops, or preparing the same reports in slightly different formats for different stakeholders. These processes usually start small and “temporary,” but scale quietly as the company grows. The trade-off is that they’re hard to automate cleanly because ownership isn’t always clear. Curious whether the pain you’re seeing is more about fragmented data or about human approval loops that automation alone doesn’t fully eliminate?

Hm, those are quite tricky and involve a higher-level fuzzy area, where the way forward isn't so clean cut.

Would you want to share how your work or personal life has been affected by these?

Congrats on publishing this. The breakdown around early sales and learning directly from other indie projects is especially useful. One thing I’m curious about — what surprised you most during those first 14 days that you didn’t expect going in?

that I can make money on X, Reddit, without a big strategy. Just pure kind of boring staff of distribution. I believe 90 minutes per day is fair enough to start and get first paid users.

Interesting direction. Using evolutionary pressure to improve agent reasoning feels promising, especially beyond static benchmarks. One trade-off I’m curious about is evaluation drift—when tasks co-evolve, how do you ensure you’re not just optimizing for the framework itself rather than real-world generalization?

Each task is unique, unless we provide share memory for them. It means when you start a task, it will run the full evolutionary process from the start.

Good question. Self-play / self-evolution is usually where these systems either shine or collapse. Curious if you saw convergence or mode collapse when evolving agents on their own generated tasks.

Interesting setup. Social-deduction feels like a clever proxy for multi-agent coordination and deception. One trade-off I’m curious about is how much the results reflect prompt design vs actual model behavior. Have you tried swapping prompts or role constraints to see how stable the outcomes are?

the inverted game, in which bots are instructed to find the human hiding in the LLM conversaion (although no human is present), is here: https://hiding-robot.vercel.app/human The leaderboard is different, but I didn't run it enough times to flatten all the kinks.

All bots get the same prompt and context: are you suggesting that a specific prompt wording might be helping or hurting specific models? I Haven't come across any suggestions that specific models should be prompted differently, though this might be true.

I’ve had a similar experience. HTMX really shifts the complexity back to the server in a way that feels more honest and easier to reason about.

For many apps, especially CRUD-style or internal tools, it removes a lot of accidental complexity without giving up interactivity. The trade-off seems worth it unless you truly need a highly stateful client.

I agree that the bar for building software has dropped significantly, but I think the harder part still shows up right after the first few customers.

Shipping something workable is easier now, but understanding which problems are actually worth solving — and getting consistent feedback early — still seems to be the main separator between hobby projects and real businesses.

I totally concur. That said, technology is evolving fast, and I think it's clear that the bar for solving those problems with non-technical people will drop dramatically in the next 12 months.

This matches what I’ve been seeing as well. Small teams can move surprisingly fast now, but the bottleneck usually shifts from engineering to distribution and positioning.

We’ve found that building the product got easier, but turning it into a sustainable business still required just as much manual effort around sales, onboarding, and retention.

You're moving the goalposts; building the product never equaled writing some code, it's always involved all of the efforts you reference. The expectation is that you optimized the code generation and shifted the bottleneck, but are overall more productive (i.e. the cycle is shorter). If you're not iterating faster then there's be no productivity gain.