From Telegram Dreams to TurboRepo Reality: Building PoolMind’s Multi-Interface DeFi Architecture

At first, I wanted a clean, minimalist setup — just a Telegram bot and a backend. That was it. The dream was simple: users talk to the bot, the backend does all the magic, and everyone is happy.

But then reality came knocking. We needed wallet connections. We needed to call smart contracts. And here’s the kicker — you can’t do that directly from the backend in a smooth way for the user. You need an actual wallet connection from the client side, which meant… yep, a frontend.

The React Era
I knew React, so I reached for React. Felt challenged, but ready.
Of course, reality had more surprises for me.

I had to:

• Sync environment variables between the frontend and backend (fun times).

• Figure out how to build the frontend while building the backend.

• Run both apps in development and still get them to talk nicely to each other.

• Make Express serve the React app in dev without complaining.

Eventually, I got it working. The flow was simple: the user creates an account in Telegram, wants to connect a wallet, we send them a link with a JWT, frontend grabs it, authenticates to the backend, and links their wallet.

It worked… but the frontend? Ugly. Painfully ugly. The kind of ugly that stares back at you every time you open localhost.

Next.js to the Rescue (Sort of)
I wanted a proper framework. So I moved to Next.js. Added MongoDB, wallet connection, a landing page, NextAuth — the works. Finally, it felt like a “real” app.

Until I realized… You can’t run background jobs in Next.js. No Telegram bot. No long-running jobs. That’s when NestJS entered the chat.

Enter NestJS (and TurboRepo Madness)
I spun up a NestJS app for the backend jobs and bot logic, kept the Next.js frontend, and stuffed them both into a TurboRepo. My old Express app? Yeah… still there. Just chilling in the repo.

In the end, I had:

• NestJS for orchestration and background jobs

• Next.js for the frontend

• Express from the early days (legacy, but still breathing)

• A Telegram bot running alongside it all

Architecture Diagrams

Before – Original vision: just Telegram bot + backend

User (Telegram)
     |
[Telegram Bot (Node.js, Telegraf)]
     |
[Express.js Orchestrator]
     |
[AI Agent (Python)] --- [Clarity Smart Contracts]

---

After – Current multi-interface setup

User (Telegram)                     User (Web)
     |                                  |
[Telegram Bot]                   [Next.js Frontend]
     |                                  |
     +--------> [NestJS Backend] <------+
                       |
              [AI Agent (Python)]
                       |
              [Clarity Smart Contracts]
                       |
                   [MongoDB]

Lessons Learned
I won’t lie — the architecture got messy. But with each pivot, I learned what works, what doesn’t, and what definitely shouldn’t be in the same repo.

If I could go back, I’d spend more time upfront thinking about the architecture instead of patching things together mid-flight. But hey, sometimes you have to build the wrong house before you learn how to lay the right foundation.