Forem: Rakib Hasan

I Built a Mini Derivatives Exchange in Python. Here's How I Used Cursor Without Letting It Run the Show.

Rakib Hasan — Sun, 01 Mar 2026 20:05:51 +0000

This year I wanted to level up in AI assisted coding as a senior engineer. Also I have interests on Trading. So I built a paper derivatives exchange: order book, limit and market orders, matching engine, positions. Python, FastAPI, PostgreSQL. I used Cursor the whole time, but not the way you might think. I didn't type "build me an exchange" and hit enter. I wrote the architecture first. Then I drove Cursor one module at a time. That made all the difference.

If you're thinking of building something like this with an AI pair programmer, here's what actually worked for me.

Write the plan before you write (or generate) any code

The first thing I did was open a doc, not the IDE. I wrote a single architecture and projects file. In it I spelled out:

How repos are split (frontend and backend always separate, one deployable per backend).
Which repo does what (exchange API, demo UI, where gamification would plug in later).
Tech choices: FastAPI, PostgreSQL, Binance public API for prices. Why no Kafka yet.
Module boundaries: core, market_data, orders, matching, positions, integration. Each with a clear job and a public interface.

That doc became the plan Cursor and I worked from. When Cursor suggested putting the UI in the same repo as the API, I pointed back at the doc and said no. That's basically what Cursor calls Plan Mode: get the design and the file-level plan right before you let the agent write code.

One deployable, but with real boundaries (modular monolith)

I went with a modular monolith. One service, one database, but strict module boundaries. Each module has a public interface (like OrderService.place, OrderBook.add). Nothing crosses the boundary by importing another module's internals.

Why? Two reasons. First, ops stay simple. Second, I could give Cursor very focused tasks. "Implement OrderService.place in the orders module and wire it to the matching engine." Not "build the whole trading flow." I pasted or pointed at the architecture doc so it didn't invent a different structure.

The matching engine: break it into steps you can verify

The matching engine is the heart of the thing. I wanted price-time priority, limit and market orders, and on fill we'd update positions and optionally ping a gamification API.

I didn't ask for "a matching engine" in one go. I broke it down.

Data structures. Define Order, Fill, and an OrderBook (bids and asks by price level). I described the behavior I wanted and had Cursor implement add, insert, cancel, best bid, best ask.
Matching logic. When we place an order, load the book from the DB (all open limit orders), run book.add(order), get back a list of Fills. Cursor implemented that. I reviewed how fills were applied to orders and positions.
Persistence. Orders and positions live in PostgreSQL. The book is rebuilt from the DB on every place and cancel. So we don't rely on long-lived in-memory state. That was a deliberate trade: simplicity and correctness over ultra-low latency for this project.

Each step was one focused prompt with clear success criteria. When something was wrong (for example the maker order not updating on fill), I didn't keep patching in chat. I reverted, tightened the plan, and ran the agent again. Cursor's own docs say to do that. It works.

Let the agent find context. You own the boundaries.

I didn't paste the whole codebase into the prompt. I kept an architecture doc and a README as the "rules." I pointed at existing code: "Add the integration call where we apply fills, same pattern as in positions/service.py." I let Cursor use grep and semantic search to find where orders are saved and where positions are updated.

That kept prompts short and kept the agent inside the boundaries I'd set.

What I shipped and what I'd do next

I ended up with: order book, limit and market orders, positions, real market data from Binance (no API key), optional POST to a gamification API on fill, and a README with an architecture diagram, system design notes, and an API table. Docker Compose for local run.

What I'd do before calling it production-ready: add rate limiting (e.g. Redis) and proper unit tests for the matching engine (OrderBook.add, insert, cancel) plus integration tests for place, cancel, and book. Then the agent can iterate against a test suite too.

The takeaway

A mini derivatives exchange is a real project. Using Cursor like a senior meant: (1) writing the architecture and module map first, (2) breaking implementation into small steps I could review, (3) giving the agent clear boundaries and examples instead of "build everything," and (4) reverting and refining the plan when it went off spec. The result is a codebase I can explain in an interview and a story about how I used AI without letting it own the design.

If you're building something similar, try starting with a one-pager: repos, modules, and why this way. Then drive Cursor one module at a time. You'll get better code and a better story.

Repo links: mini-derivatives-exchange (backend), mini-exchange-ui (frontend). Both READMEs have architecture diagrams, API docs, and system design notes.

How Early Success in Tech Almost Stalled My Growth

Rakib Hasan — Wed, 17 Dec 2025 13:15:02 +0000

Early success in tech feels like momentum you can’t lose.

You get paid well.
People respect your skills.
Opportunities start coming to you instead of the other way around.

I experienced that early in my software engineering career and I didn’t realize that the same success was slowly pushing me off track.

This is not a story about failure due to lack of skill.
It’s a story about losing direction after success and what it took to recognize and correct it.

Accidental Beginnings, Real Momentum

I didn’t plan to become a software engineer.

I learned Python during university to do small side hustles. My original plan was to focus on .NET, but Python projects kept finding me. Small scripts turned into paid freelance work. Then came web projects, Django applications, payment integrations, production systems.

Within a few years, I was:

Working on real-world production systems
Handling clients directly
Designing backend architectures
Leading engineering teams in startups

From the outside, everything looked right.

Inside, I believed something dangerous:

If my skills got me here, they’ll keep me here.

When Success Stops Teaching You

The problem with early success is that it reduces urgency.

I stopped asking:

What should I learn next?
What will matter in five years?
Who am I surrounding myself with?

Instead, I focused on:

Delivering
Earning
Staying busy

I didn’t notice that:

My learning became shallow
My routines disappeared
My curiosity declined

I was still productive but I wasn’t growing.

The People Problem Engineers Don’t Talk About

One of my biggest mistakes had nothing to do with code.

I spent years around people who weren’t my peers.

I confused:

Friends with mentors
Noise with insight
“Marketing” with shortcuts

I tried to learn business and marketing from the wrong people. I invested time and money chasing knowledge that wasn’t real. That environment slowly distorted my thinking.

As engineers, we often underestimate how much our circle shapes our trajectory.

Wrong people don’t slow you down immediately.
They slowly pull you off course.

The Hidden Cost of Losing Direction

Losing direction doesn’t look like failure.

It looks like:

No long-term learning roadmap
Ignoring new technology waves
Poor financial discipline despite good income
Escaping stress instead of fixing systems

When the AI wave started accelerating, I realized something painful:

I was late, not because I lacked intelligence, but because I lacked focus.

That realization hit harder than any rejection or failed project.

The Wake-Up Moment

At one of my lowest points, I disconnected from almost everyone.

One day, I found an old note I wrote years earlier — a personal roadmap.
It had:

Clear goals
Daily routines
Learning plans
A disciplined version of myself

That version felt unfamiliar.

That’s when I understood:

I didn’t lose my skills.
I lost alignment.

What Early Success Taught Me (The Hard Way)

Here are the lessons I wish I understood earlier:

1. Early success hides structural problems
Momentum can mask bad habits for years.

2. Skills decay without intentional learning
Especially in fast-moving fields like software and AI.

3. Routine matters more than motivation
Consistency beats intensity.

4. Your environment is part of your system
Choose peers, not just friends.

5. Direction > speed
Moving fast in the wrong direction is still failure.

Rebuilding With Intention

Today, I’m rebuilding my career with clarity:

AI and system design as core learning paths
Strong routines for work and life
Better boundaries with people and time
Long-term thinking instead of short-term wins

This time, I’m not chasing momentum.
I’m building systems that sustain growth.

Final Thoughts

If you’re early in your career and things are going well, pause and audit your direction.

If you’re successful but uneasy, trust that feeling.

And if you feel lost:

You don’t need a new career.
You need a new system.

P.S: Follow me to learn from my real experiences. I'm sharing my journey publicly.

Originally published at https://www.meetrakib.com/blog/i-lost-my-direction-after-early-success-in-tech-heres-what-i-learned/ on December 16, 2025.