Starting at the end

This was the largest product I worked on. Too large for a quick walkthrough, so I'll show the big picture first, then zoom into one feature that captures the approach best.

The platform went through three major rebuilds. It started as a closed crypto and web3 community. Evolved into a networking tool for founders and investors. Ended up as a multifunctional platform with messaging, calendar, project tools, AI-assisted profiles, and a built-in banking system.

You can't plan your way through chaos

The biggest challenge wasn't any single feature. It was the fact that everything kept changing. Target audience, visual language, positioning, feature set. We'd spend a month building something, ship it, and then discover the business had already moved on.

Rapid prototyping helped. We used no-code tools (Bubble for the platform core, Figma for design) to test ideas with real users fast. But speed created its own problem: a loop where we built, the business pivoted, we rebuilt, and nobody ever felt like the product was "done."

The frustration was real. When you invest weeks into a feature and it gets shelved, your first instinct is to fight for it. That instinct is wrong.

The approach that actually worked

Eventually I stopped trying to deliver polished features and started delivering hypotheses.

The process: sketch the functionality quickly, push it to production. Yes, rough. Yes, with "Coming Soon" banners where half the buttons should be. But functional enough for the business to use, show investors, and form an opinion.

Then wait. If the business comes back in a month or two with feedback, that feature matters. Refine it properly. If they don't come back, it wasn't needed. Kill it.

Out of roughly 15 features we shipped this way over six months, 9 made it to full production. The other 6 were quietly removed. Under the old approach, we would have spent months polishing all 15 before learning which ones mattered.

The "Coming Soon" banners turned out to be surprisingly useful. They served as interest signals: we could see which locked features users clicked on most, which helped prioritize the next round of development.

How it works in practice: the investment account

Before we added financial features, the platform only facilitated introductions. We weren't involved in the actual deals. But the obvious monetization path was taking a percentage from transactions between founders and investors.

The problem: these are high-value deals. You can't launch a payment system without serious protective mechanisms, compliance (KYC), and trust-building. Doing it wrong means legal exposure and destroyed user trust.

So we applied the same approach. First iteration: two screens. A simple request form where investors could express interest, list amounts, and indicate preferred payment methods. No actual money moved through the platform.

This did two things:

• Gave the business real data on demand. Within the first month, we had 40+ investment requests through the form.

• Gave us time. While the business tested whether users trusted the process, I designed the full transaction system architecture in parallel.

When the green light came, we were ready. A few months later, we had a working in-house banking system integrated with Linkcy (European banking provider), supporting fund transfers, investment tracking, and basic financial reporting.

Within the first quarter after launch, the system handled its first completed investment cycles. More importantly, 60% of users who started with the two-screen version came back to use the full banking system. The lightweight entry point did its job..

What three rebuilds taught me

The hardest part wasn't the work. It was letting go. When you've spent two weeks on a feature and someone says "we don't need this anymore," your gut reaction is to defend it. I learned to ask a different question: "Did we learn something from shipping it?" If yes, the time wasn't wasted. It was research.

Concrete things I'd do differently:

Start with "Coming Soon" everywhere.
We discovered this tactic by accident. Next time, I'd make it the default for every new feature area. Cheap signal collection before committing to development.

Set a feedback deadline.
Our "wait and see if they come back" approach had no time limit. Some features lingered in limbo for months. A 6-week rule ("if no feedback in 6 weeks, it's cut") would have been cleaner.

Track the kill rate explicitly.
We killed ~40% of shipped features. That number itself is valuable. It means we were testing aggressively enough. If the kill rate drops to zero, you're probably only shipping safe bets.