Questions to Ask Before Starting a Backend Project
by Arif Ikhsanudin, Backend Developer
“We just need an API… should be quick, right?”
That sentence has started more fragile backend systems than anyone admits.
What Exactly Is This Backend Responsible For?
Before writing a single endpoint, get clear on boundaries.
Not “we need a backend,” but:
- What does this service own?
- What data does it control?
- What is explicitly not its responsibility?
Unclear boundaries lead to messy, tightly coupled systems.
If everything talks to everything,
you’ll feel it when things start breaking.
What Does the Data Look Like — Really?
Backend projects live and die by data.
Yet this is often hand-waved early.
- What are the core entities?
- How do they relate?
- What are the edge cases (nulls, duplicates, conflicts)?
Bad data modeling is expensive to fix later.
APIs can be refactored.
Data mistakes tend to stick around.
What Are the Expected Loads and Failure Modes?
Not “will it scale,” but how it fails.
- How many requests per second?
- What happens if a dependency is down?
- What’s the timeout and retry strategy?
A backend isn’t just about handling success — it’s about surviving failure.
If you don’t design for failure,
production will do it for you.
How Will Services Communicate?
Even simple systems have dependencies.
Think early about communication:
- Sync vs async (REST, queues, events)
- How errors are propagated
- How retries and idempotency are handled
Integration complexity grows faster than you expect.
What looks simple with 2 services
gets chaotic with 5.
Who Owns the Technical Decisions?
Backend work involves constant trade-offs:
- Database choice
- Schema design
- Caching strategy
- Error handling patterns
If no one owns these decisions:
- Inconsistency creeps in
- Patterns diverge
- Maintenance becomes painful
Consistency doesn’t happen by accident. It’s enforced.
Even a small team needs a clear technical direction.
What Does “Done” Mean for This API?
“Endpoint works” is not enough.
Define what done actually includes:
- Validation and error handling
- Logging and monitoring
- Documentation
- Basic performance checks
A working endpoint isn’t a finished backend.
Production readiness is a different bar.
One Quick Backend Reality Check
If you can’t answer these questions clearly,
you’re not starting a backend project.
You’re starting an experiment.
That’s fine — as long as you admit it.
Most backend problems aren’t caused by code.
They’re caused by unclear decisions made before the code.
The Part Most People Skip
Backend systems don’t fail loudly at first.
They degrade.
Slow queries. Weird bugs. Inconsistent data.
And by the time you notice,
fixing it is much harder than building it right.
The best backend work happens before the first table is created —
when you’re still asking the questions most people skip.