Why Planning a Project Is the Most Important Aspect of Building

ADITYA DUTT PANDEY — Wed, 02 Jul 2025 18:33:54 +0000

I recently set out to build an E-commerce platform using a Microservice Architecture. With a decent level of experience, I figured I could move fast: define a high-level plan, get help refining it, and dive straight into implementation.

To speed things up, I shared my initial ideas—workflow, database schema, and API routes—with GPT, got a refined version, and started building based on that.

In hindsight, this approach taught me a lesson I didn’t expect to learn at this stage of my career: no matter how experienced you are, skipping proper planning will come back to haunt you.

Where Things Started to Fall Apart

After jumping into implementation, I began to realize that the schema I was working with had several gaps. Things looked good at first glance, but I hadn’t accounted for:

Edge cases
Data integrity constraints
API request/response inconsistencies
System-wide failure handling

As I began to handle these situations, I needed to redesign the schema multiple times, and every time I did, it started breaking the previously built routes and services. I was using Bruno to test the APIs, and it became clear that things weren’t as stable as I thought.

The Domino Effect of Midway Changes

Once the BFF (Backend for Frontend) layer was complete, I moved on to building the frontend. That’s when I hit another wall.

New frontend requirements led to additional changes in the schema and logic, which again caused issues in the routes and services I had already implemented. The lack of a stable contract between services and layers became a real bottleneck.

The deeper I went, the more everything started feeling like a Jenga tower—one change, and things would start to collapse.

Key Lessons Learned

This experience forced me to take a step back and reflect. Here's what I took away from this:

🧠 Plan extensively before implementation: Even if it delays coding by a week, it's worth it.
🧩 Model your schema based on actual business logic, not assumptions or third-party suggestions.
🔄 Version and document your APIs early to prevent regression from breaking existing services.
🧪 Validate your design against use cases before committing to it—mock flows, simulate errors, think long-term.
🛑 Don’t depend entirely on tools (or even AI) for architectural decisions—they're great support systems, not decision-makers.

The Role of an SDE II Isn't Just to Build—It's to Architect

At the SDE II level, you're expected to think beyond writing clean code. You're responsible for:

System design decisions
Long-term maintainability
Collaboration between services
Edge case handling
Ensuring that your implementation scales with the product

This project reminded me that being effective means slowing down when it matters. Rushing into code may feel productive at first, but without proper planning, it creates long-term technical debt.

Final Thoughts

I still love building things fast, but now I do it differently.

Spend more time on schema modeling
Write down API contracts
Think through edge cases and fallback scenarios
Collaborate with teammates early to identify potential blockers

If you're at a similar stage in your engineering journey—or even just starting out—treat planning as an engineering discipline. The time you spend upfront will pay off tenfold during implementation.

Thanks for reading. If you've had a similar experience (or a completely different one), I’d love to hear your thoughts in the comments.

Why using Turborepo in a MicroServices architecture

ADITYA DUTT PANDEY — Mon, 30 Jun 2025 14:50:57 +0000

Though it may feel counterintuitive at first, using TurboRepo in a microservices system begins to make a lot of sense when you consider the valid and strategic advantages it brings.

Key Benefits

1. Monorepo with Microservices: Structure with Flexibility

Monorepo + Microservices = Shared code + Independent services

TurboRepo supports a monorepo architecture where each microservice remains logically independent.
This works particularly well for internal microservices developed and maintained by a single team or organization.
Not ideal for third-party or externally hosted services, but excellent for cohesive systems.

2. Shared Code and Libraries

Extract common logic into reusable packages (e.g., in the /packages folder).
Avoid duplication across microservices.
Ensure updates and fixes to shared libraries are automatically reflected across all consuming services.

Example shared packages:

packages/
  auth-lib/       # Shared authentication logic
  config-utils/   # Common configuration tools

3. Consistent Tooling Across Services

Use a unified configuration for tools like ESLint, Prettier, and TypeScript across all services.
Manage dependencies via pnpm or Yarn workspaces.
Enforce best practices and streamline onboarding for new developers.

4. Incremental Builds and Caching

TurboRepo provides smart caching of build artifacts.
Supports incremental builds—only rebuilds packages/services that have changed.
Use remote caching (e.g., with Vercel) to speed up CI/CD across machines and teams.

Saves time and compute in both local dev and CI environments.

5. Improved Developer Experience (DX)

Use scoped commands like:

  turbo run test --filter=payment-service

Run, build, or test only the affected services or packages.
CI pipelines are significantly faster due to parallel execution and caching.
Local development becomes easier with co-located code and utilities.

Recommended Project Structure

apps/
  api-gateway/       # API gateway or BFF layer
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3og7rldz2dwtsr0fz63n.jpg)
  web-app/           # Frontend web application
  mobile-app/        # Mobile frontend (React Native, Flutter, etc.)

packages/
  auth-lib/          # Shared authentication logic
  config-utils/      # Common config/environment utilities

services/
  user-service/          # Microservice for user management
  payment-service/       # Microservice for payments
  notification-service/  # Microservice for sending notifications

When Does It Make the Most Sense?

Using TurboRepo for microservices is ideal when:

You have closely related services developed in parallel.
Your services are internally deployed or tightly coupled in purpose.
You want to share code, config, and tools across services.
You need fast, intelligent CI/CD pipelines and optimized builds.

DEV Community: ADITYA DUTT PANDEY