This isn't a promotion.
I'm genuinely curious how developers think.
Imagine you have two platforms.
Platform A
Used by millions.
Bee...
For further actions, you may consider blocking this person and/or reporting abuse
Reasons for not choosing A:
Reasons for not choosing B:
This is probably the most balanced way to look at A vs B.
A has the risk of becoming expensive or slow to adapt, while B has the risk of reliability and abandonment.
And I think that's where the “environment” I was talking about matters. If an indie product can build trust through transparent development, responsive support, consistent updates, and a real exit path, it can gradually reduce those risks instead of asking users to simply trust it.
The interesting question is whether that can actually make B feel safe enough for people to switch. 👀
"build trust through transparent development, responsive support, consistent updates, and a real exit path, it can gradually reduce those risks instead of asking users to simply trust it."
True!
Maybe be it will take more time to win the trust than A, but it will!
Exactly! 🙌 I think that's the tradeoff.
A already has years of built-in trust, while B has to earn it one user at a time. But if it consistently delivers, listens, and stays transparent, that trust can compound over time.
Maybe the real advantage is that the trust isn't just inherited from a brand it's built through the relationship with the users. 🙂
Great framing. I've been thinking about this from a slightly different angle — not just product choice, but trust architecture.
When you choose Platform A (the giant), you're not just choosing stability. You're choosing a trust model: "I trust them because millions of others do." Social proof as verification.
When you choose Platform B (the indie), the trust model is different: "I trust them because I can read the code, see the commits, and watch the decisions happen in public." Verifiable proof as verification.
The interesting part: in developer tools, Platform B's trust model is actually stronger — if you bother to look. But most people don't bother. So social proof wins by default.
I wonder if the gap isn't about features or speed. It's about the cost of verification. Reading source code and commit history is expensive. Using what everyone else uses is free.
The indie products that break through seem to be the ones that make verification cheap — not the ones that add the most features.
This is a really interesting way of looking at it. I hadn't thought about it as a “cost of verification” problem.
I especially like the distinction between social proof and verifiable proof. Open source technically gives users more ways to verify a product, but if verifying it takes hours, most people will just rely on the reputation of the established product.
That actually connects closely to what I was trying to get at with the post: maybe the advantage of an indie product isn't simply “we ship faster,” but creating an environment where users can see what is happening, influence it, and verify that the product is actually being maintained.
“Make verification cheap” is a much more interesting principle than “add more features.”
Thanks for the thoughtful reply — you put it better than I did.
"Cost of verification" is exactly the right frame. It multiplies by orders of magnitude with agents: you need to verify not just the product, but every action taken on your behalf.
That's why I've been working on turning verification into a protocol layer rather than a manual chore. The north star is: verifying an agent's claim should be as cheap as reading a signed receipt — no audit required.
I think the real question for indie products isn't "can you build it faster," but "can you build it so transparently that verification becomes a side effect."
Yeah, that makes a lot of sense. The “verification becomes a side effect” part is especially interesting.
With agents, I can see how the problem gets much bigger you aren't just trusting the software, you're trusting it to take actions for you. Having some kind of verifiable record of what actually happened could reduce a huge amount of that uncertainty.
And I like how that connects back to the original idea: maybe transparency isn't just about showing people what you're building. It can actually become part of how users trust the product.
I'm curious to see how you're approaching the protocol layer. 👀
The protocol layer is where the bet gets concrete.
The basic unit is a PolicyDecision — before an agent touches any tool, a specific role (Manager, Developer, System Admin, etc.) must issue a signed authorization. The signature is Ed25519, the payload is canonical JSON (RFC 8785 JCS), and the decision itself is just a JSON object with four fields: what tool, what arguments, what work order, and an expiry window (usually 300s).
The execution node receives this PolicyDecision, checks the signature, executes the tool call, and then emits an ExecutionReceipt — also signed, also canonical, with the exact same causal fields plus a link to the specific PolicyDecision that authorized it. So every receipt answers the question "who authorized this" with a cryptographic proof, not a log entry.
The "verification as side effect" part comes from the EvidencePublication step. Once the work order completes, all receipts and their corresponding PolicyDecisions are bundled into a single file, ordered by the causal chain, and the publication node can optionally sign the bundle root. This means anyone — you, a third party, an auditor — can replay the entire chain offline, verify every signature, and check that every tool call was authorized by the right role at the right time. No API calls needed. No trusting the node.
The protocol doesn't run the agent. It just sits between the agent and the tool, asking "who said you could do this" and writing down the answer in a format that can be proven later.
This is the part I'm most curious whether it resonates with people who actually operate agent systems. Does it feel like too much ceremony for a single tool call, or does the cost of a JSON signature feel trivial compared to the cost of explaining to a compliance team why an agent made a destructive change?
Honestly, the “who authorized this?” part makes the idea click for me.
For a normal tool call, the extra ceremony might feel unnecessary. But once an agent is allowed to make consequential changes, having a cryptographically verifiable chain of authorization → execution → evidence seems much more valuable.
I also like that the protocol doesn't try to run the agent itself. It stays as a layer between the agent and the tool, which makes the responsibility boundary much clearer.
So I don't think the JSON signature itself is the interesting cost. The real question is whether the additional verification overhead is low enough to become invisible during normal operation. If it is, then the compliance/audit use case seems pretty compelling.
I'm not operating large agent systems myself, though, so I'd be interested in hearing what real-world latency/complexity looks like when this is running at scale. 👀
But I've been working at this article for 8 years!
I put my personal life on hold, just to focus on working at this article!
I want that promotion.
Are you giving it to Greg?
Awww, of course Greg... who could forget Greg, the king of Cafeteria smooth talking.
Jesus... after all I did... you seriously thought, you could give the promotion to Greg, and I would just sit here accepting it numbly?!?!!?
I
Want
That
Promotion
😂 Sorry, Greg had seniority. The promotion committee has spoken.
Nooooooooooo! :)
😂 I tried to fight the decision, but apparently Greg has connections in HR.
Right from the Windows 2000 days, I've always loved exploring and researching apps, and I still do.
I don't choose software because it's a giant brand or an indie project. I choose whatever is lightweight, straightforward, and gets the job done with the least navigational complexity.
I like that perspective. In the end, the software that solves the problem with the least friction usually wins, regardless of who built it. Have you found any indie tools that surprised you over the years?
Can't quite think of any for now, but there was a browser I used back in the day for just one feature I was stuck with that browser as my default simply because it could save my downloads to a virtual drive. I could go do something else for a while until the download completed, totally off my data, and then download it to my local disk at full speed.
The catch was that non-resumable downloads could complete their transfer to the virtual drive and become resumable and unthrottled afterwards. 😉
When they eventually removed that gesture, I shunned the browser too. So yeah, sometimes one feature can be enough to make you choose the "indie" option—and removing that one feature can be enough to make you leave.
That's actually a great example of what I was getting at. 😄
It wasn't “indie vs giant” that made the difference—it was that the smaller product solved one specific problem in a way the alternatives didn't.
And the second part is just as interesting: once that unique value disappeared, the loyalty disappeared with it.
Maybe the real advantage of an indie product isn't being smaller or faster. It's being willing to solve the weird, specific problems that a giant product has no reason to prioritize.
That's a much more interesting version of the idea than “ship faster.”
I'd use platform B. But often it's really hard to find them.
Yeah, I think that's one of the biggest problems with Platform B.
Even if the product is genuinely better for someone, it doesn't matter much if they never discover it. 😅
Maybe discovery is actually part of the problem I'm trying to understand too
😂 lol the way this is framed... platform B already won by what you described..
anyways, your theises falls apart because theres no choice here. youre heavily biased on the indie side, then you ask which one people would 'enjoy''? ... clear bias here, not a poill.
and your assumptions are wrong; people dont stick with giants cuz of habits, its because failure cost is real... and even if you ship weekly, you cant do it for free.
but yea, critical paths = giants but tools we build with = indie i guess. but speed alone doesnt make you switch... so depends what you are actually shipping...
😂 Fair criticism. I can see why the framing feels biased I definitely described B through its strongest qualities.
But my point wasn't really “indie is better than giant.” I was more interested in whether changing the nature/environment of the product — faster feedback loops, transparent development, users actually influencing what gets built changes how people want to work with software.
I agree that speed alone isn't enough, especially when failure has a real cost. Reliability, trust, migration, and what the product actually does matter a lot.
So maybe the better question isn't “giant vs indie,” but whether a different product environment can make people choose something new when the risk/reward actually makes sense.
And yeah, I probably should've framed the poll more fairly 😄
yeah fair enough, but the interesting bit is the environment: can a faster feedback + real user influence beat switching cost when failure isn’t free?
i think that flips when the new thing owns a job the giant doesn’t, and the exit path is real.
otherwise “transparent development” is just nicer marketing around the same risk...
curious about what product environment youre actually testing that on?
Yeah, that's fair. I think the environment is the part I'm actually most interested in too not just “we ship faster.”
If the new product doesn't reduce the actual risk of switching, then faster feedback and transparent development aren't enough. The exit path point is especially important.
I'm still testing this idea rather than claiming I've proven it. I have a product I'm applying some of these principles to, but I'm deliberately using conversations like this to figure out what actually matters before pushing the philosophy too far.
The question I'm really trying to answer is: what would make an indie product feel low-risk enough that someone is willing to give it a real job, rather than just try it for five minutes?
i think platform B give you more respect
Yeah, and I think there's another part to it: Platform B can make you feel more respected as a user.
Not because it's indie, but because your feedback can actually matter. You aren't just another number in a massive user base—you can influence what gets built, talk directly to the people building it, and sometimes see your suggestion become part of the product.
That sense of being heard is something I think gets overlooked when we compare products purely on features, reliability, and price.