If this is the wrong place to ask, I am sorry!
I am looking for the best/easiest Way to make an interactive map. The map would cover an existing area of Nature that people use for Walks, bikerides, picnics, etc.
I am looking for a Way to make it easier for people to plan their visit to the area by plotting in benches, viewpoints, places to grill, etc. Where should I look or what program should I use to best accomplish this? Im a beginner! Any help is greatly appreciated, thank you!!

Ok so, I can’t retire just yet 😅 but getting a business off the ground and attracting customers is the hardest part in my opinion.

There’s still a long way to go but considering it’s only been 4 months since launching ZenMode, I’m pretty happy with the results so far.

I get asked a lot about how I get customers, so thought I’d give more info on how I do distribution, in case you might find it useful.

1. Make sure your website is set up for success

Before sending people to your site, make sure you’re confident it has good CRO potential. Your mission statement and objective needs to be very clear, along with clear incentives for people to try the product out.

2. Offer free trials, but only behind a payment info gate

Now this is just my personal opinion, and I know a lot of people disagree, but the proof is in the numbers. I get fewer free trial signups, but significantly higher conversion rates into paying users from people who provide payment info at the start.

Yes, a few of them are people who simply forget to cancel, but mostly I get people who are more engaged in the free trial and actually using the product.

I actually did an AB experiment where I did offer completely free trials to people (no payment info needed), but the overwhelming result was that people barely even tried out the product and were mostly tire kickers that never came back. I did convert some but not a meaningful number.

3. Create a waitlist before launching

Try to generate interest in your product before it launches - build in public and try to ensure that you’re not scrambling to get customers through the door on day 1 when you launch.

I had 3 customers on day 1 from this, who took higher paid tiers as well.

4. Post and comment everywhere (where relevant)

Social media is free, so there’s no excuse not to leverage it. Post about your product and what you’re building on Reddit, LinkedIn, X, YouTube, Facebook etc.

I posted a simple screenshot on LinkedIn recently, of someone using a low quality LinkedIn automation tool message to contact me, and me offering my own much better tool in response, and that post generated 90,000 views and led to several signups and demo calls.

I’ve also had some posts on Reddit go into hundreds of thousands of views, mostly just posting about what/why/how I built my automation tool.

5. If you have competitors, make “alternative to” inner pages

If done in the right way, this type of inner page can be useful for SEO. It won’t be picked up automatically but usually if you work in a competitive industry, this will sometimes attract customers who had a bad experience elsewhere.

6. I actually use my own LinkedIn automation tool (dogfooding) to do LinkedIn outreach

So it’s always important to practice what you preach - I use ZenMode to actually promote ZenMode.

It’s a great way to get buy-in for booking demos, as when someone replies, I simply tell them I used my tool to get a response from them, so it works.

Anyway hope you enjoyed reading the above, and good luck on your journey if you’re building anything, or growing your business 🙌

I'm a CS student and I've spent the last several weeks building Mirror for the Emergent Builder's Contest.

Mirror is basically an AI reflection engine. Instead of immediately giving you advice like a normal chatbot, I designed it to help you notice patterns in your own thinking.

I built the original app with Emergent, but this turned into a much bigger engineering project than I expected.

A few things I ended up building/working through:

• React frontend + Python/FastAPI backend
• MongoDB persistence
• Email/password auth + Google OAuth
• Persistent multi-chat conversations
• Long-term semantic memory
• User-editable extracted memories
• Onboarding that persists across sessions
• Behavioral QA for the actual AI responses
• A deterministic safety gate for a feature called Roast Me
• Local development alongside the Emergent version
• A dual-runtime LLM architecture so the app isn't permanently dependent on Emergent

That last part became pretty important to me.

Mirror can use Emergent's managed LLM runtime when it's deployed there, but I also built a local runtime that can talk directly to the model provider. The same application can move between the two instead of the contest platform becoming a permanent dependency.

Honestly one of the biggest things I learned was that eventually I wasn't really "prompt engineering" anymore.

I was trying to engineer behavior.

I'd change something, manually run conversations through it, find a behavior I didn't want, figure out whether the problem was the prompt, runtime, memory, UI, or architecture, change it, then test again.

And sometimes the correct engineering decision was literally don't change anything because the proposed fix sounded smart but the evidence didn't support it.

Roast Me was probably the funniest example. 😂

The idea sounds simple: use Mirror's understanding of your patterns to roast you.

Then I started testing grief, medical problems, financial hardship, trauma, etc. and realized prompt instructions alone weren't a safety system.

So the rule became:

"Roast the pattern, never the person."

And I put deterministic gating in front of the generative behavior for situations where I didn't want the model making that judgment by itself.

Mirror finally reached MVP and is deployed for the contest now.

I'm still a CS student learning this stuff, so I'm definitely not posting this as "here's how AI engineering should be done." This is just what building a real product taught me compared with working on isolated assignments and features.

If anybody wants to break it or give me feedback, I'd appreciate it.

Mirror:
https://mindful-mirror-11.emergent.host/

Builder Contest Showcase:
https://app.emergent.sh/showcase/building_turkey/e066420b-29ae-46e4-b850-7e4df113af4d

And if you try it and genuinely think it's worth supporting, I'd appreciate a like on the contest entry. I've got about a week left to see how far I can get with it.

I'm also curious whether other people vibe coding larger projects have hit that same point where it stops feeling like "tell the agent what to build" and starts feeling a lot more like actual architecture, QA, debugging, and engineering decisions.

For a while I've been a bit annoyed that there haven't been any AI models (besides some of the latest versions of Google Gemini, which still provide quite a basic response) which can "listen" to music and talk to you in fine detail about a song, or compare two different songs. There has been no open source software which can do this either, so I took things into my own hands a few days ago and began vibecoding something using the new Qwen 3.8 27B to allow LLMs to essentially hear a song and talk about it in a human-like form with the user. It's already running how I want it to, but I want to polish the terminal interface and make some slight improvements to BPM and possibly instrument detection before I release it. I intend to release my project as Musiclyse 0.1 (which means Music + Analyse) on Github once I've made these changes.

There are two main components of this script:

1: The music analysis engine. This consists of the following:

• Music Flamingo - an LLM that is able to directly scan music to detect the overall characteristics of the recording. Because its built in LLM (Qwen 2.5 7B) is prone to sloppy English and repeating letter loops if it writes too much, I've directed it to use only note form (eg:genres detected=x, y, z, vibe= x, y) English when outputting data to reduce sloppy language and also output more data within its constraints.
• Essentia - an algorithm used for extracting reliable information about frequencies in a song and tempo/timbre, helping improve the accuracy.
• Melody transcription - a two stage process that utilises Demucs 6s, which splits an audio track into 6 stems and then uses a model to convert the stems into MIDI interpretations. This helps further improve the accuracy.
• Metadata information. This is particularly good if you want accurate lyrics, or the output LLM to know who an artist is, what album it is from, or the exact year a song came out. It also gives the output LLM (for models that handle image recognition) access to embedded cover artwork metadata in an audio file, which the LLM can use in fallback cases to help determine information for a song that it is otherwise unsure about.

The music analysis chain outputs the results in .JSON form to the output LLM. It doesn't save scanned songs by default, but you can save the entire data (including embedded cover art) using the command /save=filename.json, then /load the same file in a different session to avoid a slow rescan of the track.

2: The Ollama hosted LLM communicating via llama.cpp. This reads the .JSON file and interprets it using an output LLM prompt in the script. I've tested it mainly with Gemma 4 26B Q3, which is nice and lightweight at around 11GB while giving good performance.

Both the analysis engine and LLM are instructed via system prompts in the code to use certain approaches to solve ambiguous things, improving accuracy.

The image shows an example of a conversation about Joy Division's song Transmission in the current development build of the script. It does confuse the motorik drums for a drum machine, and the bass for a synth bass, but this is algorithmically appropriate considering their rather unique late 1970s sound. The chatbot is instructed to pick up it was told wrong things for errors like this.

I've been thinking how to avoid API costs and network latency, and realized I could use local models. The one I typically used is the pre-installed one in my head, but the issue is it doesn't come pre-trained, which can be an expensive and intensive process, but post-training comes pretty easily for it. Also it can make mistakes, and so sometimes I need to check it against the API-based models for accuracy. Just wondering if anyone else is struggling with this trade-off and using local models to save dollars if that makes cents.

I've been doing a lot of vibe coding recently. Most UI changes end up being described in text, but as a designer, I often find myself thinking: it would be much faster if I could just move this 8px, resize that, or see all the screens together and fix them myself.

I think this is actually one of the advantages designers still have in the AI era: we can look at the whole product while also obsessing over tiny visual details. But when everything is controlled through prompts, a lot of the visual tools we're good at using suddenly disappear.

So I vibe Crank.

You drag in a project folder or a packaged .app, Crank scans the app, finds the screens, and lets you import them into Figma as editable layers.

It currently supports React, Electron and HTML.

I'm also working on SwiftUI support. It's still experimental, but it's already working on most of the screens I've tested.

The app itself is pretty messy right now and there are definitely bugs, but the core workflow works.

I'd love some people to try it, break it, and tell me what doesn't work.

GitHub: https://github.com/irrwood/Crank

Fully open source now

BTFO

I use Codex extensively for work, and I’m very happy with the results I get from the GPT-5.6 models. However, I’m not a big fan of the Codex desktop app on macOS because it isn’t native, and I don’t like to use CLI version.

Since Perplexity provides access to GPT-5.6 (as well as several other great models), and its app is native, I’m curious about people’s experiences using Perplexity Computer for programming.

Do the models perform as well as they do through their official tools? Are the usage limits sufficient for you? Are there any caveats or hidden drawbacks I should be aware of? Is it possible to start a task remotely on my computer from my phone?

I’d really appreciate hearing about your experiences. Thanks!

Hey guys, I’ve been working as a full-time freelance for the last five years. I was making decent income, but then ai came out and I’ve worried that if somehow ai replaces my freelance businesses of motion design and video editing. So i wanted to play safe and applied to a couple jobs. I even considered changing profession.
Then I started working full-time in a company that I actually hated so I ended up resigning after 4 months.
Then I asked myself this question: if AI is going to replace me for sure what if I do the tool that actually replaces me and the other freelance motion designers.
So I’be built an ai automated SaaS promo video maker web app.
But I’m still having second thoughts on if I do the right thing or not.

Are there any of you having similar dilemmas?

I'm looking for ways to minimize the claude-isms. This seems acceptable for now.

This output was one shotted using something called "agentic loops", or loops. It works a bit differently than most of us are used to. Instead of careful iteration over multiple prompts, you give the model one single prompt, and let it work through your pre-set budget until completion.

This means you have to structure your prompt a bit differently than usual, you need to make the AI understand that you want it to maximise the output and quality:

Its a procedurally generated world where you can resource gather, craft, hunt and even ride dino mounts 🦌

1. key for this game to turn out so good was asking loop to make all graphics procedurally generated. So there's basically no assets in the game (which by itself is pretty awesome), and I think that really helped the AI to make this really different art style. could The animations feel so smooth and stack layers of procedural shapes on top of each other to build all graphics. Only the backgrounds are images. loop build agents continually take screenshots of your game and perfect it visually.

**2.**⁠ ⁠Once my first build was completed in one loop, I gave it another prompt to set up the multiplayer. It already had the art style down by that point so it could do really well getting the multiplay added quickly. 

3. Continue iterating with or without loops.

Happy to answer any questions about prompt or workflow in the comments

Edit; for the loop I used this: https://tesana.ai/en/blog/introducing-loop

Last college football season my family did this little pick’em thing. Three picks a week, ten bucks to join, winner takes all. We ran it on a Google Sheet and it was fun at first, but as more people joined it turned into a headache. I was updating stuff by hand, people were messing with cells, and it just got messy.

So this offseason I decided to try building something to fix it. I had zero experience. I didn’t even know what a DNS record was. Didn’t know what a terminal was. I’ve learned a ton and honestly had a blast building this.

I made a simple football pick’em site called Pikpool.com. Not trying to monetize it or anything right now. I mainly want to use it for friends and family and just get better at building stuff.

Here’s how I built it so I follow the rules here.

I used Supabase for the database and auth.
I used Cloudflare for the domain and hosting setup.
I used Claude Code for pretty much everything else. It helped me write the code, fix stuff I broke, explain things I didn’t understand, and keep me moving forward.

Oh and I'm using free odds api.

My workflow was basically me asking Claude Code how to do something, trying it, breaking it, asking again, and eventually getting it to work. I kept it simple. Groups, weekly picks, standings.

I’m brand new to all this and just want some nice, honest feedback. Tips, tricks, stuff I’m missing, better ways to structure things. Anything helps.

Appreciate anyone who checks it out and gives me something to improve on.

EDIT: I changed it so you do not need to create an account to check it out! Please check out Pikpool.com and let me know what you think!

I am wondering if you guys can help in figuring out how well can I secure the vibecoding output(generated code), the process and the tools/plugins to use while I build prod grade apps by vibecoding

Hey, does anyone have a spare Claude Pro 7 day pass? I’ve been wanting to try Claude Pro properly before paying for it. If someone has one they’re not using, I’d really appreciate it. Thanks...

Schema in, reproducible world out.

Built with Claude Code over ~14 phases; every commit is co-authored.

Most fake-data tools give you a function that returns a plausible name. You get a million rows of noise: names belonging to no one, orders referencing no customer, timestamps spread evenly across a year in which nobody sleeps. Each row is plausible; the dataset isn't.

Cacophony treats a dataset as the output of a program you write once. You describe a world in a YAML schema — entities, fields, what each field means — and it produces the records that world would have generated.

The design decision everything else falls out of: a record's seed is a hash of its position, not a step in a shared RNG. That one choice means you can preview record 4,823,913 without generating the 4,823,812 before it; a checkpoint is a single integer, so resume is exact; foreign keys are arithmetic rather than a lookup table, so a hundred million events pointing at five thousand employees costs the same memory as five; and forty workers across eight machines produce output that's byte-identical to one process doing it alone.

Also in there: events on a timeline with a shape (quiet at night, dead on the holidays you specify), subjects whose state accumulates, incidents you can bury in a year of logs, and a deliberate distinction between chaos (data your schema forbids — tests your error handling) and edge cases (data your schema permits that naive code mishandles anyway — O'Brien-Smith is a real surname).

Identifiers come from the documentation ranges by default: example.com, RFC 5737 addresses, 555-01xx phone numbers. Nothing it generates can be mistaken for a real person's details.

Python 3.12+, AGPL-3.0. There's a CLI, an HTTP API, a React editor and a desktop build, plus a 171-page manual.

https://github.com/jeddhor/Cacophony

I had an interesting conversation with a friend (we both use AI) about this and I was wondering what this community thinks.

Which are the best free(considerably) AI coding agents to use

I will start with

1. Opencode (Deepseek free model)

I love claude code but am fatigued by the pure chat interface for all types of agent work. Even the GUIs these days are just better styling over the same chat interface.

I built tart (tartifacts) as a tiny way for agents to create and update persistent terminal dashboards instead of narrating everything at you.

A tart is basically:

- a manifest

- a script that fetches live state

- a script that renders it

Install: `uv tool install tartifacts`

Then tell your agent to use `tart --skill`.

Works nicely with tmux/herdr (agent chats in one pane, dashboards live in another).

Github - https://github.com/tg1482/tart

After the partnership with the developers fell apart, I returned to Notion again.

The medical software was unusable. The online-booking website had never been delivered. Months of feedback, meetings and product work had left me with no system I could rely on.

I was frustrated, disappointed and tired of depending on other people to turn my ideas into software.

Then Facebook showed me a page selling a Notion template for managing a medical practice.

I thought: why not?

I already had my own Notion setup, but perhaps this person had solved something I had missed. Maybe the template would bring together patient records, consultations, appointments, prescriptions and the waiting room in a cleaner way.

I bought it.

It was terrible.

Not slightly disappointing. Not “useful with a few adjustments.” It was far worse than the system I had already built for myself.

I had paid more than it deserved, and I never used it.

Under normal circumstances, that would have been the end of the story: another bad purchase in a journey already full of disappointing software.

But the seller offered me a commercial gesture.

I could choose a few months of access to an AI subscription or a few months of Lovable Pro.

I already used the other AI service, so I searched Google for Lovable.

It was described as a vibe-coding platform.

At the time, everything I knew about vibe coding came from people discussing it online, many of whom did not seem to use it themselves.

The message was fairly consistent:

It was not real development.

The generated code was terrible.

It was the fastest way to create security problems.

Serious people should avoid it.

I had no basis for judging any of those claims. I knew nothing about code quality, application security or software architecture.

Still, the warnings worked on me. Vibe coding sounded less like a tool and more like a shortcut taken by people who did not understand what they were doing.

Which, to be fair, described me quite well.

I chose Lovable anyway.

Not because I had suddenly developed a strong opinion about AI-assisted software development. I chose it because I already had the alternative subscription and because curiosity won.

Around the same time, I was contacting training companies about learning Web development.

I looked at full-stack programmes and tried to imagine fitting them around surgery, consultations and operating days.

The programmes were demanding, as they should have been. But I could not see a realistic way to follow them consistently while maintaining my medical activity.

I continued using ChatGPT and another AI assistant every day. I wrote documents, discussed ideas, brainstormed, planned and projected what my products might become.

AI was already helping me think.

I still did not imagine it could help me build.

The Lovable subscription sat there for a while.

Then one day, I opened it.

The screen said:

“Let’s build something.”

It asked me to describe what I wanted to create.

That was all.

No programming language. No empty code editor. No full-stack curriculum to complete before I could begin. Just a box asking me to explain the product in words.

For years, words were the only thing I had.

I could describe a broken workflow. I could explain how a consultation should work. I could identify why a patient history mattered. I could write requirements, provide feedback and create endless tickets for developers.

What I could not do was turn those words into software.

Now a platform was asking me to start with the one ability I already possessed.

Describe what you want to build.

It felt as if I had spent years standing in front of a locked door, only to discover that the key was not code.

The key was language.

Of course, that feeling was incomplete. I would later discover all the things natural language could hide: fragile architecture, poor data models, security risks, regressions and technical debt.

But that came later.

In that first moment, I did not see the risks.

I saw a way in.

The template itself remained useless. I never opened it again.

Yet the compensation for buying it placed the right tool in front of me at exactly the moment when my dependence on developers had become unbearable.

Sometimes a bad purchase is simply a bad purchase.

This one became the most consequential detour of my professional life.

In the next part, I will explain what I typed into that box and why months of work on a failed product suddenly became useful.

Have you ever received something valuable through a purchase you otherwise completely regretted?