1
0 Comments

Shipped 5 new features in one evening. Here's why I built them before anyone asked.

I have zero paying customers on TxDesk right now. Every founder advice column says "don't build features nobody asked for." I agree with that as a default. But I also have about 6 hours between my morning distribution session and my afternoon one, and I refuse to sit around hoping the inbox fills up.

So I made a compromise: build things that ARE distribution.

The Sui blockchain had three exploits in nine days last week. Volo lost $3.5M to an admin-key compromise. Scallop lost $142K to a deprecated contract that was still callable on chain. Aftermath Finance lost $1.14M to a missing authorization check. Twitter was on fire with post-mortems. I was already replying to threads as part of my marketing routine.

So I built Sui security tools not because a customer asked, but because every tool I ship becomes tomorrow's tweet, next week's Dev.to article, and a reason for someone to visit txdesk.io.

What I shipped:

  • Package risk scanner (catches the deprecated-contract pattern from Scallop)
  • Failed transaction diagnosis
  • Object inspector
  • Coin metadata + scam detection
  • Account risk analysis (catches the admin-key blast-radius pattern from Volo)

Numbers: 2,893 lines of service code, 2,080 lines of tests, 87 new tests, all green. From planning to deployed in one evening.

Then I ran the package-risk tool against Cetus CLMM - a well-known Sui DEX, real mainnet, no hand-picked fixtures. It returned CRITICAL with two findings: the package ID is a deprecated old version (a newer one exists), and the upgrade authority is held by a single keypair, not a multisig. Both real issues on a live protocol on day one. That's not a demo. That's the product working in production from the moment of deployment.

The distribution loop:

  1. Ship feature
  2. Tweet about it (sharp number: "found two CRITICAL issues on a real DEX in seconds")
  3. Write Dev.to article (craft angle: "what mainnet smoke testing taught me about API design")
  4. Engage in comments
  5. People visit txdesk.io
  6. Repeat

Every line of code feeds the content engine. The tweet has the punch. The article has the depth. Comments have the conversations. All of them point home.

That's the only justification I'll accept for building without customers: when building IS marketing.

Will this get me a paying customer next Monday? Probably not directly. But it keeps the product moving forward. Gives me things to talk about that aren't "please buy my product." Means that when a Sui protocol team eventually needs support tooling, which they will, after the next exploit cycle TxDesk already has the surface area. No "let me build that real quick" delay.

The honest alternative was 6 hours of dead time where I could have been improving the product. I'll take the lines of code and the article material instead.

Building when nobody is asking is dangerous, for most things. But for content-fueled products, where every feature is also a story, every story is also a backlink, and every backlink is also a hire-me-when-you-need-this signal, it works. Just need to be honest with yourself about which category you're in.

I don't know yet if TxDesk is in that category. I'll know in three months whether the loop is closing. For now, I'm running it as if it is.

Five tools shipped. Back to distribution.

on April 30, 2026
Trending on Indie Hackers
How are you handling memory and context across AI tools? User Avatar 112 comments Do you actually own what you build? User Avatar 66 comments Code is Cheap, but Scaling AI MVPs is Hard. Let’s Fix Yours. User Avatar 34 comments I Think MCP Will Punish Thin API Wrappers User Avatar 27 comments What AI Is Actually Changing in IT Certification Prep User Avatar 19 comments Cloud vs Cybersecurity Certifications | 2026 Path Makes More Sense User Avatar 18 comments