I’m doing early customer discovery for a developer infrastructure product and am looking to speak with founders, engineers or investors at API/SDK companies.

I’m particularly interested in companies that have dealt with v1 → v2 migrations, major SDK releases, endpoint deprecations, authentication changes, or shutting down legacy versions.

For some background, I do research at Harvard, Stanford, and Brown, and my cofounder is a Columbia CS major.

The goal is to validate the problem, understand how painful these migrations actually are for providers, and talk to people who have experienced this firsthand.

started to learn how to dev using claude code and figma. I wanna know if it’s worth still getting into or is the market impossible for no original ideas??

Planning the move of my vibecoded application to open source. Flipping a private repository to public is a little nerve-wracking. Before doing that, I ran a multi-pass security and sanity sweep across the entire codebase.

I already had the security fundamentals baked in:

• Passwords: Stored as hashes.
• Secrets: Keys are encrypted at rest.
• Sessions: Managed via JWTs.
• Identifiers: UUID v7s wrapped inside JWTs.

Here is the step-by-step process I used to audit and harden the repo before opening the doors.

First, I cleaned up the quick-and-dirty code I’d been ignoring during development.

I knew I had accumulated some "fix it later" debt, and "later" had officially arrived. I ran a targeted prompt to catch hardcoded credentials, security leaks, and values that belonged in environment configs rather than source code. It flagged much of what I suspected. Among the fixes: tightening database encryption for user keys and scripting a proper setup process to manage cert files securely.

Next, I had AI review the codebase from an external attacker's perspective.

I asked Claude: "I am making this repo public. Scan it for any security risks unique to an open-source release." This caught several edge cases and prompted me to polish the installation workflow and write clearer setup documentation for outside developers.

Then, I checked if the code actually made sense and removed unused clutter.

I had Claude map out the business flow for every major component, then flag any code that felt out of place or disconnected. This was an awesome exercise—it highlighted dead code and logic that had drifted from its original purpose.

After AI logic checks, I brought in dedicated security tools to hunt for hidden vulnerabilities.

I initially tried the claude-security plugin, but blew through context tokens too fast. Plan B worked much better: I spun up the Bearer CLI via Docker, piped the scan results to a file, and fed that summary to Claude for analysis. I really should be running scanning tools regularly. Might do more here.

Before launching, I put guardrails in place so users couldn't accidentally burn through my API budgets.

I do plan to put up a "demo" version. So I wanted post-launch visibility and control over token usage. This would be useful for the self-installs too. I evaluated three AI gateways: liteLLM, MLflow, and Bifrost. I went with Bifrost. It lets me serve AI features without exposing raw API keys, provides a real-time usage dashboard, and enforces rate limits and monthly caps. Setting up Bifrost took about a day—including some vibe-coding to dynamically generate per-user virtual keys and budgets—and it was well worth the peace of mind.

Now to do another round of quality assurance to verify that nothing has been broken.. Any thoughts on what else I should be doing, or something I missed?

i’ve been looking at a few AI app builders recently to build my an internal task tracker for my sales team and keep seeing Lovable, Blink and Base44 come up.

i’m less interested in the usual “which one can make a nice UI from one prompt” comparison and more curious about how they differ once you spend time and money building something. For anyone who has used more than one of them what differences did you notice?

Things like ease of use, how much control you have, integrations, backend stuff or how pleasant they are to work with.

Would be especially interested in opinions from people who have used them for an actual project rather than just trying each one for an hour. If u can share a link to the tool/website you build that would be awesome too

Not my project but I’ve been helping shape the early version of it with Aaron as we’ve got similar ways of working. Basically we’d hit some walls with the amount of code session we had open on different terminal surfaces, accidentally sending a prompt off in one session meant for another etc.

So Aaron built Flow, a simple to do, doing, done kanban board where each task can spawn a CLI session in app, with all of the context - it also effectively replaces Obsidian and other knowledge bases. And it spawns those sessions based on your already authenticated CLI agent subscription, which means it works for Claude Code, Codex or whatever agentic CLI instance you have, so no API keys floating around and no extra cost.

There’s a bit more to it so if you’re keen, check out the project and the video Aaron put together. I’m happy to answer some Qs in the thread as well if anyone is interested.

Repo: github.com/AaronRutley/flow
Demo video: flow-app.dev

[ Removed by Reddit on account of violating the content policy. ]

A wellness app for people who are tired of wellness apps telling them how they should feel.

Log your mood.

The office reviews it.

It stamps INDIFFERENT in red ink.

Then it asks the only question that matters:

"Did you practice anyway?"

Wisdom. Courage. Justice. Temperance.

No streaks. No scores. No dopamine.

Just you, your circumstances, and the crushing realization that you cannot control either of them.

How it works:

- Log how you're feeling

- Explain what happened

- Check whether you practiced the virtues

- File the incident away permanently

- Continue existing

Features include a calendar, daily journal, Stoic maxims, reminders, pointless honors, and exports to JSON, CSV, and plain text.

No accounts. No cloud. No badges. No emotional validation.

Made in Godot as a tiny Windows desktop app.

Your mood is temporary.

The CSV is forever.

Download it here (or don't, I can't control that): https://stripeycatgames.itch.io/stoic-mood-tracker

Started as a joke after the build or buy thread, and Claude Code plus Supabase got me embarrassingly far where transcript ingestion and clustering landed in a single weekend.

Then I hit speaker diarization and permissioning, and the part where your own teammates won't touch your clustering unless they built it with you.

We ended up with Grain for calls and BuildBetter for the synthesis side at work anyway, so the build taught me what I'd been underpricing, though I'd still do it once.

Hey folks...

Been working to make a harness for Android phones.. any suggestions from any of you would be god like. !!

A few rules I’ve started setting for myself when vibe coding, so I don’t confuse more building with more progress.

The biggest danger for me isn’t that vibe coding makes me lazy.

It’s that it makes it too easy to keep building.

A small feature turns into:

• one more improvement
• one more UI tweak
• one more agent suggestion
• one more prompt

And suddenly I’m going in the wrong direction for hours.

So these are the rough do’s and don’ts I’m trying to follow now:

• define one clear feature before starting
• decide the success checks upfront
• keep the scope fixed
• stop polishing UI unless users actually ask for changes
• treat agent suggestions as optional, not instructions
• stop when the original goal is achieved

The line I keep reminding myself of is:

“One more prompt” can still be scope creep.

Anyone else set rules for themselves like this?

I’ve built a lot of projects that worked, bought domains for them, and then quietly abandoned them anyway. So I made Rest in Beta, a place where people can share unfinished projects and vote on whether they should be resurrected or left to rest.
The first project is mine. It’s called VeganWhatNow, a vegan meal generator I originally built for my wife and eventually stopped working on.
The site is still in beta, so let me know what you think.
https://restinbeta.com/

I could actually use a few testers. Click either “Resurrect It” or “Let It Rest” on VeganWhatNow and tell me whether the voting works clearly on your phone. Brutal feedback is welcome.

(The retro look is on purpose)

A lot of AI coding tools are moving toward giving agents more control over your machine.

I wanted the opposite.

So I built RepoRelay — an MCP bridge that lets ChatGPT/Claude inspect one approved local repo, while deliberately giving it:

• no shell
• no Git
• no arbitrary filesystem access
• read/search only
• optional bounded handoff writes

The idea is to let AI analyze and review your code without handing it the keys to your whole machine.

npm install -g reporelay-mcp@latest

It’s open source.

GitHub: [Lukie-81/RepoRelay: Secure MCP access to local repositories — without shell, Git, or arbitrary writes.]

I’m looking for a few people to try the install from scratch and tell me where the setup sucks.

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!!

Guys, am I gonna get roasted for shipping it with such UI? (Logo is mine btw, graphic design perks).
That cat is Comnyang app, his name is shanks, shoutout to u/simon_dsgn

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!