Forem: sandeep

[Boost]

sandeep — Tue, 07 Apr 2026 15:19:33 +0000

sandeep

Apr 6

Your Customers Think You Stopped Shipping. You Didn't — Your Distribution Layer Is Broken.

#ai #productivity #vibecoding #sideprojects

Comments

5 min read

Your Customers Think You Stopped Shipping. You Didn't — Your Distribution Layer Is Broken.

sandeep — Mon, 06 Apr 2026 15:53:30 +0000

You shipped 47 commits last week. Three PRs got merged. A sprint closed with 12 issues done.

And your customers? They have no idea.

Release notes are buried in Notion. The roadmap lives in a spreadsheet only your PM opens. Feature requests? Scattered across Slack, email, and a Canny board nobody checks anymore.

Here's the thing — the problem isn't that you're not shipping. The problem is that nothing you ship reaches the people paying for it.

That gap between "shipped" and "seen by customers" — that's the distribution layer. And for most product teams, it's completely broken.

What Is the Customer Distribution Layer?

Think about it this way. You've probably got solid infrastructure for building — GitHub, Jira, Linear, CI/CD, staging environments. The dev side is covered.

But what's your infrastructure for the other side — the customer-facing side? Where do customers go to see what changed? How do they know what's coming next? Where do they tell you what they actually need?

For most teams, the answer is... duct tape. A blog post every quarter. A tweet when someone remembers. A changelog page that hasn't been updated since February.

The customer distribution layer is the missing piece — a single surface where your customers can see what shipped (changelog), what's planned (roadmap), and where they can tell you what's missing (feedback). All on your brand. All connected to the tools you already use.

That's what we built with Releaslyy.

Why We Built This

I've been building Releaslyy as a release notes generator — connect GitHub or Jira, pick your commits or sprint issues, and AI writes your release notes. That part works. People use it. It saves time.

But I kept seeing the same pattern. Teams would generate beautiful release notes... and then what? Copy-paste them into Notion? Email them to a list that's 6 months outdated? Post them on a blog that gets 30 visits a month?

The generation wasn't the bottleneck. The distribution was.

So we asked — what if the same tool that generates your release notes also gives you the surface to distribute them? And while we're at it, what if that surface also showed your roadmap and collected feedback?

One platform. Three problems solved. No more stitching together Canny for feedback, ProductBoard for roadmap, and Headway for changelog.

What the Distribution Layer Looks Like — Concretely

1. Public Changelog

A self-hosted changelog page on your brand — your logo, your colors, your domain. Every entry categorized as New, Improved, or Fixed. Version-tagged. Searchable.

You generate release notes from your commits or sprint issues using AI, and with one click they're published to your changelog. Your customers see what shipped — instantly.

No separate publishing step. No copy-pasting. The same flow that creates the notes also distributes them.

Live example: releaslyy.com/c/releaslyy — yes, we dogfood this.

2. Public Roadmap

A roadmap page your customers can actually see. Not your internal Jira board with 200 tickets — a curated view of what's planned, what's in progress, and what's done.

This is the page that stops your customers from emailing you "when are you adding X?" — because the answer is right there.

3. Feedback & Feature Requests

A board where customers submit, vote on, and discuss feature requests. Think Canny, but built into the same platform as your changelog and roadmap — so there's no disconnect between "we heard you" and "we shipped it."

When a requested feature ships, the loop closes automatically. The customer who asked for it sees it move from "planned" to "shipped" — without you lifting a finger.

4. Embeddable Widget

A lightweight Preact widget you drop into your app. Bell icon or button trigger. Dark mode. Your branding. Cloudflare Turnstile-protected voting so nobody games the system.

Your users don't need to leave your app to see what's new, check the roadmap, or submit feedback. It's all right there — in context, in your product.

Why Not Just Use Canny + ProductBoard + Headway?

You can. A lot of teams do. Here's what that looks like:

Canny ($400+/yr) for feature requests — but no changelog, no roadmap publishing.
ProductBoard ($5,000+/yr) for roadmap management — overkill if you just need a customer-facing view.
Headway for a changelog widget — but no feedback, no roadmap, no AI generation, limited integrations.

Three tools. Three subscriptions. Three logins. Three places where customer communication is fragmented.

Or — one platform that does all three, starts free, and is configured in under 5 minutes.

That's the bet we're making. The customer distribution layer shouldn't be three separate tools bolted together. It should be one unified surface.

The Integration Piece

This is where it gets practical. Releaslyy connects to 7 tools today — GitHub, Jira, Linear, Asana, ClickUp, Monday, and DevRev.

Here's the workflow:

Connect your project management or source control tool.
Select the commits, PRs, or sprint issues you want to turn into release notes.
Generate — AI writes the notes in seconds. Multiple audience options (customer-facing, internal QA, product team).
Publish — one click to your changelog. Or push back to GitHub Releases, Confluence, Slack, and more.

The whole thing takes about a minute. From commits to customers — literally.

And if you're on the BYOK plan, you can plug in your own API keys for OpenAI, Anthropic, Gemini, or Groq. Use whatever model you trust, on your keys.

Who This Is For

If you're reading this and thinking "that's us" — it probably is. Specifically:

Product teams at B2B SaaS companies — you ship weekly or biweekly, your customers are paying, and they deserve to know what's changing.

Solo devs and indie hackers — you're shipping fast but spending zero time on communication. A changelog that writes itself is the unlock.

Engineering leads — release notes are a chore nobody on your team wants to own. Connect GitHub, let AI do the writing, review and publish.

QA teams — you're closing sprints and summarizing for stakeholders. Generate audience-specific notes from Jira or Linear in one click.

Try It — Free

Releaslyy has a free tier. No credit card. 10 generations per month, 1 project, full changelog setup.

Pro starts at $12/mo (annual) — unlimited everything, BYOK, all integrations, all publish destinations.

Set up your customer distribution layer in 5 minutes: releaslyy.com

See what it looks like in production: releaslyy.com/c/releaslyy

Releaslyy is built by Sandeep Baligeri — a solo founder shipping after work hours from Bengaluru. If you're a product team that ships fast but struggles to communicate what shipped, this is built for you.

I built an AI tool that solves a problem you didn't even know you were wasting hours on.

sandeep — Mon, 23 Mar 2026 03:48:09 +0000

That is releaslyy.com

Every sprint, same story.

Stakeholders ask — "What's the new update?"
Testing team asks — "What code changes were made? What's the impact?"

And every time… it's painful. You're sitting there consolidating tickets, PRs, sprint items — trying to turn all of that into a one-liner answer. Nearly impossible.

I've been managing projects as a lead for the past 5–6 years. And I always had this question — what if there's a tool that just... solves this?

Then I noticed something that really hit me.

Even large product-based companies — I'm talking proper engineering orgs — share their development updates through Slack messages. That's it. Slack messages.

Now think about what that means for the testing team.

How would they know the real impact of a change? How big is it? What's affected? They don't. So QA ends up doing a complete regression — even for small updates. Hours wasted. Every single cycle.

What if a tool could read your commits, PR descriptions, your sprint board — and generate a consolidated test impact summary for QA, automatically?

That's where the idea started.

But I didn't want to build this just for QA. I wanted to solve everyone's problem. One tool.

Same release, written differently for:
→ QA — test coverage gaps, regression risks, affected modules
→ Product — feature readiness, what to demo, roadmap progress
→ Engineering — technical changelog, breaking changes, API diffs
→ Customers — what's new, how it benefits them
→ Sales — competitive advantages, feature announcements
→ Developer community — deprecation notices, migration guides, new API updates

You select the data from multiple sources, choose who you're writing for, and hit generate. And the best part? Publish back to all your platforms at once — GitHub Releases, Jira, DevRev, and more.

Right now, it's very early stage. But it works. And it's live.

If you think this solves your problem → releaslyy.com
Free to start. No credit card required. If you want any custom integration — I'm just one message away.

I spent the last month building this mostly after work hours — with a team I want to call out by name:

Cursor, Claude Code, ChatGPT, Stitch.ai, and a couple more AI agents.

These tools gave me confidence every single time. Best teammates a solo founder could ask for.

AI doesn't replace your job. It gives you better work to do. Helps you build faster.

buildinpublic #saas #releasemanagement #devtools #ai #startup #indiedev

I Built 7 AI Agents to Automate My Repetitive Platform Work

sandeep — Thu, 19 Mar 2026 16:04:48 +0000

A frustrated prompt to Claude turned into a 7-agent plugin system that automates my most of the tasks

I build things on DevRev for a living — snap-ins, AirSync connectors, dashboards, widgets. If you've ever built on a platform like this, you know the pattern: every new connector follows the same steps. Every dashboard has the same JSON boilerplate. Every time, you're making the same 15 engineering decisions you already made for the last project.

I got tired of it. So I opened Claude and typed:

"I want to build a plugin for my client DevRev. Right now there's a lot of manual work — creating agents, dashboards, connectors. I want to give a plugin complete context of what we do, and it should behave as a DevRev architect and give a solution."

That was the start. I had no idea it would turn into 6,000+ lines of agent instructions with 7 specialized AI agents. Here's how it happened.

The problem: every connector is the same (but also different)
Building an AirSync connector always goes through the same cycle:

PM phase: Gather requirements, write a PRD, write a TDD, get approval.
Architect phase: Research the external API, figure out auth, pagination, rate limits, data mapping — then generate TypeScript, manifests, and deployment scripts.
Test phase: Unit tests, deploy to a test org, run the import, verify every field.

Each phase involves dozens of decisions but none of that knowledge was reusable. It lived in people's heads and old PRs. I wanted agents that knew all the patterns.

How I built them
The PM agent — I studied patterns across our past projects and wrote detailed reference templates: discovery questions by snap-in type, PRD sections covering object mapping and permissions, TDD sections covering sequence diagrams and data mapping. The agent now asks focused questions in rounds, classifies snap-in type, and produces both a PRD and TDD before anything gets built. Key insight: don't say "write a PRD" — give it the exact format your team expects.

The architect agent — This one taught me something important. The first version generated code that looked great but was wrong. It had manual timeout tracking when the real ADaaS SDK uses processTask({ task, onTimeout }) where the platform manages everything. I caught this by comparing against official docs. That mistake led me to build the self-learning agent.

The tester agent — Two modes: Jest unit tests first (fix code bugs cheap), then UI automation that drives the actual DevRev browser — install snap-in, configure connection, go through the mapping screen, run the sync, verify every field. The mapping screen is where 80% of bugs hide.

The dashboard vertical — Wasn't planned. A teammate found 6 metric bugs in a dashboard — wrong date aggregation, wrong ticket counts, wrong response definitions. All SQL expression problems. I realized: if an agent had the complete widget JSON reference, it could both create dashboards AND diagnose broken ones. Same PM → Architect → Tester pipeline, different domain knowledge.

The skill improver — The 7th agent. When any agent makes a mistake, you run /devrev:improve-skill. It traces the error to the exact reference file, produces a patch, asks for confirmation, and logs the learning. The agents get smarter every time someone finds an issue.

The architecture
Seven agents, two verticals, one self-learning loop — packaged as a Claude Code plugin:

Snap-in vertical: PM → Architect → Tester (connectors, automations)
Implementation vertical: PM → Architect → Tester (dashboards, widgets)
Cross-cutting: Skill Improver (patches any agent from real mistakes)

6,400+ lines of skill instructions. 7 slash commands. Bug feedback flows back upstream.

What I learned

Be specific about format — define the exact sections and patterns your team uses, not generic templates.
The agent will be wrong — plan for it. The self-learning agent is how the system improves.
Separate the phases. One agent doing everything skips research and jumps to code. Handoffs force discipline.
Reference files are the real product. The workflow is just glue. The SDK patterns, SQL rules, and visualization catalogs are where the knowledge lives.
Test in the UI, not just in code. The mapping screen is where real bugs surface.

The approach is transferable: study your past projects → extract patterns → encode as agent skills → build a feedback loop. The tools are all available today.

AI agents are crazy when you know it

sandeep — Thu, 19 Mar 2026 16:02:06 +0000

I Built 7 AI Agents to Automate My Repetitive Platform Work

sandeep ・ Mar 19

#ai #agentskills #llm #claude

I Built 7 AI Agents to Automate My Repetitive Platform Work

sandeep — Thu, 19 Mar 2026 15:59:37 +0000

I Built 7 AI Agents to Automate My Repetitive Platform Work

sandeep ・ Mar 19

#ai #agentskills #llm #claude

I Built 7 AI Agents to Automate My Repetitive Platform Work

sandeep — Thu, 19 Mar 2026 15:57:15 +0000

A frustrated prompt to Claude turned into a 7-agent plugin system that automates my most of the tasks

I got tired of it. So I opened Claude and typed:

That was the start. I had no idea it would turn into 6,000+ lines of agent instructions with 7 specialized AI agents. Here's how it happened.

The problem: every connector is the same (but also different)
Building an AirSync connector always goes through the same cycle:

PM phase: Gather requirements, write a PRD, write a TDD, get approval.
Architect phase: Research the external API, figure out auth, pagination, rate limits, data mapping — then generate TypeScript, manifests, and deployment scripts.
Test phase: Unit tests, deploy to a test org, run the import, verify every field.

Each phase involves dozens of decisions but none of that knowledge was reusable. It lived in people's heads and old PRs. I wanted agents that knew all the patterns.

The architecture
Seven agents, two verticals, one self-learning loop — packaged as a Claude Code plugin:

6,400+ lines of skill instructions. 7 slash commands. Bug feedback flows back upstream.

What I learned

Be specific about format — define the exact sections and patterns your team uses, not generic templates.
The agent will be wrong — plan for it. The self-learning agent is how the system improves.
Separate the phases. One agent doing everything skips research and jumps to code. Handoffs force discipline.
Reference files are the real product. The workflow is just glue. The SDK patterns, SQL rules, and visualization catalogs are where the knowledge lives.
Test in the UI, not just in code. The mapping screen is where real bugs surface.

The approach is transferable: study your past projects → extract patterns → encode as agent skills → build a feedback loop. The tools are all available today.

Earlier, it was the Ice Age. Now, we are in the AI age 🚀. Bolt.new

sandeep — Sun, 15 Dec 2024 11:59:54 +0000

Earlier, it was the Ice Age. Now, we are in the AI age 🚀. I recently came across Bolt.new
, which is new. I couldn't resist trying it out. Hear me out.

✨𝗪𝗵𝘆 𝗕𝗼𝗹𝘁?
It helps you execute your ideas in less than an hour. If you have an idea and need a full-stack application to fulfill it, Bolt.new
will help you build it. Perfect solution for turning concepts into reality.

🛠️𝗪𝗵𝗮𝘁 𝗱𝗶𝗱 𝗜 𝗯𝘂𝗶𝗹𝗱 𝗼𝗻 𝗕𝗼𝗹𝘁.𝗻𝗲𝘄?
I face a common challenge when building static website. That is Data storage. Often static websites need to store data. For example, Career Forms, Contact Us, career page, and whatnot.

💡𝗨𝘀𝘂𝗮𝗹𝗹𝘆, 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿'𝘀 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲
• Integrate it with Google Sheets. you don't get updates
• Email the details - Difficult to manage
• Use third-party apps that can store the data for you and trigger the notification when a new entry is added.

I tried to build the app which you can use it as a backend server for your static websites.

🗒️ 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘁𝗵𝗲 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁 𝗜 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗱 𝘁𝗼 𝗕𝗼𝗹𝘁.𝗻𝗲𝘄
Build a full-stack web application that allows users to store their data (formdata) through APIs that the app provides. Which can be used for multiple purposes.
The flow looks like this :

User signup/login
Allow user to generate the API key, and they can use this API key to store their data.
Create a dashboard to see the data that
Also, a webpage with API documentation on how users can generate the key and use the API's
Create a backend server to store these data.

👾 The free trial version is very limited, so I didn’t ask Bolt.new
to fix the bugs. Instead, I resolved them myself.

After a couple of small bug fixes,🐛 I was able to get the complete web app🎉. Code has a Complete Full-stack code, It has SQL queries to create database and table, CORS handled, Rate limits set, and Documentation for API created.

Then Later I tried adding a small feature to it. Watch the video for how It worked.

You can access the complete code here: https://bit.ly/4gv006p

Watch here : https://bit.ly/3ZVOquQ

BoltNew #WebDevelopment #devto #AI #react #reactJS #frontend #backend #AIForDevelopers #BuildWithAI #SoftwareEngineering