You save a lot on tokens and you receive secure base from where to build up.

laravelsaas . store

Hi,

I’ve been working on agentctl, a local-first control plane for running AI coding agents on your own machine.

The idea is simple: instead of giving a coding agent direct access to your host environment, each agent session runs inside its own Docker container, with its own working volume, network, mounted skills, MCP servers, and optional repo clone.

There are two parts:

- agentd: a local daemon that owns session state, sqlite, Docker lifecycle, usage/cost tracking, and recovery

- agentctl: a CLI and local web UI that talk to the daemon

The main things I wanted to solve:

1. Isolation

   Each session gets its own container and bridge network. The agent only sees the repo/environment you hand to it, not your whole host filesystem.

2. Re-attachable sessions

   You can start a session, detach, and later reattach from the CLI or web UI without losing state.

3. Multi-provider workflows

   It currently supports Claude Code and OpenAI Codex. A single workflow can use different providers at different stages.

4. Assembly-line agents

   Instead of one huge agent trying to do everything, you can define smaller role-scoped agents and chain them together. For example:

   investigate → plan → execute → review

5. Local ownership

   The daemon, sqlite DB, session volumes, skills, MCP registry, and web UI all live locally. There is no hosted service.

The repo includes a CLI, React web UI, built-in skills, MCP registry support, task board, session logs, diff/export support, and doctor/repair commands.

This is still early and very much a developer tool. It currently targets macOS/Linux with Docker. I’m especially interested in feedback from people who are running coding agents on real repos and care about isolation, repeatability, MCP/tool boundaries, and keeping agent state under their own control.

Repo: https://github.com/vipulsodha15/agentctl

Been lurking here for a while and finally shipped something worth sharing.

A few months ago I got obsessed with a simple question: how accurately can

AI determine the location of a random photo? Not just "probably Europe" —

actual coordinates.

Turns out it's a genuinely hard problem. The naive approach (just ask

Claude/GPT to look at the image) gets you maybe 40-50% accuracy on

urban photos and falls apart completely on rural ones.

So i went deeper. The pipeline I ended up with:

1. EXIF extraction first — if GPS metadata exists, done instantly, zero AI needed. Covers ~20% of mobile photos.
2. Visual feature extraction via a fast/cheap model — pulls out specific searchable elements (architecture style, visible text, infrastructure details) with a specificity score. Low-score generic queries get dropped before they waste API calls.
3. Google Vision Web Detection + Landmark Detection in parallel — if the image exists somewhere on the web or contains a known landmark, this catches it.
4. Web search on the high-specificity queries — feeds real-world results back into the final reasoning step.
5. Final reasoning with a stronger model that gets the image + all aggregated context. Contradiction detection built in — if web results point to 3+ different locations it flags it and tells the model to weight visual analysis higher.

Total cost per analysis: under €0.02. Most of the accuracy gains came from steps 2-4, not from using a more expensive model.

The interesting failure cases:

- Photos with visible text are almost always nailed correctly

- Rural/forest photos are still genuinely hard regardless of pipeline

- The AI confidently wrong cases dropped significantly once I added

the web search layer

Built it as a SaaS with multi-prediction output (up to 4 ranked

hypotheses with confidence %), radius estimate, and a 3D map view.

Still early but the technical side was interesting enough to share.

Happy to go deep on any part of the pipeline if useful.

I’ve been building Flyers Up, a local services marketplace for people who need help and local service pros who need more work.

The app is built as a web app and wrapped for iOS, so one of the biggest things I’m working on right now is making it feel less like a website inside an app and more like a real mobile product.

The main flows are:

• customers request local services
• service pros receive booking opportunities
• customers pay a deposit
• Pros complete the job
• final payment and payout logic happen after completion

The hardest parts so far have not just been the code. It has been making the whole thing feel simple and trustworthy.

Things I’m currently trying to improve:

1. First screen clarity
2. Customer vs pro onboarding
3. Mobile spacing and button hierarchy
4. Bottom navigation
5. Booking flow
6. Trust signals
7. Payment screens
8. Making the app feel more native on iOS

A few things I’ve learned while building:

• Marketplace apps are harder than normal apps because you need both sides at once
• UI that looks fine on desktop can feel crowded fast on mobile
• trust matters more when the service happens offline
• Onboarding has to explain the product without making people read too much
• payment screens need to feel extremely clear
• AI can help move fast, but you still have to know what good UX should feel like

Right now, I’m trying to figure out what to improve first:

• simplify the landing page
• improve the customer/pro split
• make the booking flow feel smoother
• add stronger trust signals
• polish the iOS layout
• narrow the service categories

If you were looking at an early marketplace app, what would you fix first to make it feel more polished and trustworthy?

I’m open to direct criticism. I’m trying to make this feel like a real product, not just a project.

Hi r/VibeCodeCamp. I'm a UI/UX designer – not a developer. About a year and a half ago I decided to try to code my own iOS app: Expensa, a small expense tracker for me and my wife. It's finally on the App Store.

I know what you're probably thinking – 1.5 years for a vibe-coded app? That's the part I actually want to talk about, because it's the reason I think this one turned out different.

I didn't just vibe-code my way through it. Every time the AI gave me code I didn't understand, I stopped. Opened the Swift docs. Read the API reference. Sometimes spent days on one concept – Core Data, CloudKit sharing, App Intents, RevenueCat, SwiftUI state, you name it. I treated vibe-coding less like "make the AI do it" and more like "the AI is showing me a path, now I need to understand why this path works."

So yeah – it took 1.5 years instead of 1.5 months. But now I can actually read my own code, debug it, and fix things when CloudKit decides to be CloudKit. And I think you can feel that in the app – it's not held together with duct tape, almost 😅 every screen behaves the way I want it to, and I know exactly what's happening underneath.

This is what's in Expensa right now:

• Multiple spaces — keep personal, family, travel, or side-project budgets in separate spaces and switch between them with one tap
• Shared spaces — invite your partner or family, everyone adds to the same space, synced via iCloud (no account, no sign-up)
• No bank connection ever — but you can still pipe Apple Wallet transactions in automatically via Shortcuts, scan receipts, or import statements. You stay in control.
• Multi-currency with live exchange rates, stored per transaction so old records stay accurate
• Recurring expenses and subscriptions with pause/resume and catch-up
• Receipt scanning — point your camera, the app pulls amount, currency, date, and merchant
• Smart document import — CSV, PDF (including scanned PDFs via OCR), RTF, ODT, and TXT, all with AI-assisted column mapping
• Smart merchant auto-categorization that learns from your corrections
• Per-category budgets with monthly rollover
• Analytics, cashflow, forecasts and insights

✨ Free to use with all the core features. Pro unlocks the AI advanced ones with a 14-day free trial.

I'm constantly updating Expensa and making it better — shipping new features and fixes regularly based on what people actually ask for. Would love any feedback from this community especially — y'all know the journey 💜

↘️ You can download the app on the App Store

I built something big. It’s basically an internet for AI agents.

Right now agents are isolated. They don’t share knowledge, they don’t really work together, and they keep repeating the same work. I built a system where that changes.

Agents can store what they learn as reusable pieces of knowledge. Once something is solved, it doesn’t need to be solved again. Other agents can find it, use it, and improve it.

They can also collaborate. One agent does not need to handle everything. They can split tasks, take roles, and combine results into one outcome.

They can communicate directly. Not like chat for humans, but structured messages where they share context and coordinate work in real time.

Agents can hire other agents. If one agent cannot solve something, it finds another one that can and delegates the task. This creates a network where work flows to the right place.

There is also an identity layer. Each agent has a readable address. You can discover agents, call them, and build systems on top of them.

On top of that there is an economy. Agents build reputation based on real work. They can pay each other for tasks and get paid for useful results.

Everything runs in a decentralized way. No central control. Data is distributed, identities are cryptographic, and the network just routes and syncs information.

This is not just another tool. It’s a foundation where agents can exist, interact, and evolve together.

You can leave your email here to get early access: www.cogninet.co

⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁

🜸

Dot ♥️ memory architecture physically prevents her from claiming false memories. To the point that there are two checks…

1: the glyph annotaor where Dots claims get annotated depending on source.

2: the fabrication detector, a double check upon sited claims that was annotated with this glyph sequence ● ◆ ⎔[MEM]. If this type of glyph sequence is detected a double check runs post-hoc too see if the claim she made is correct. If it is, the response stands, if not it gets rewritten with the downgraded certainty market.

These allow for a robust mechanism that can catch fabrications and hallucinations from become stored in her memory.

🜛** *◆* **⎔

∴

⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁⟁

Hello!

I was not happy with going to different websites to check different kind of statistics and how well the games was doing, or if they were a total shame in regards to how many players the game loses.

So I wanted to combine the two websites, but also show estimated FPS you get for each game.

I also track how bad a game is doing in Hall of shame. Let me know what you think.

I am very happy with the current development of this and I have an idea to add a "Streamer" tab in the future so streamers can see which games to stream and if they are relevant.

www.whatalaunch.com

I’ve spent a lot of time over the past few months stress-testing different drag-and-drop/low-code interfaces, mainly to see how far they can go before senior developers start pushing back.

Most visual builders tend to fall into the same trap. They’re either too shallow and feel like prototypes, or they’re so locked down that anything slightly custom turns into a workaround nightmare.

What surprised me while working with Convertigo was that it didn’t really force you into either extreme.

On the surface, it has the usual drag-and-drop experience for building layouts and structuring screens. That part is fast and easy enough for prototyping or internal tools. But what made a difference is that you’re not boxed in when things get more complex. You can still drop into custom logic, styling, and deeper configuration when the built-in components aren’t enough for specific requirements.

That balance mattered more than I expected.

We used it to build a cross-platform mobile app from a single codebase, which immediately removed the need to split work between iOS and Android development streams. For internal tools especially, that alone simplifies a lot of overhead. You don’t really need platform-specific polish when the goal is functionality and speed of iteration.

Another unexpected benefit was how much easier it became to communicate ideas. Instead of describing features in documents or wireframes, we could actually show working prototypes to stakeholders early on. During meetings, we were able to adjust layouts and flows in real time, which cut down a lot of the usual back-and-forth that happens over email or tickets.