When I start a new software project or take on client work through my freelance development services (you can view my gig here), I don’t begin by choosing a framework.
I start with two questions:
What problem am I actually solving?
And:
What is the one thing I cannot afford to get wrong?
I learned this while building a multi-tenant SaaS product end to end, and while delivering real-world client projects through freelance work.
I was involved in everything from understanding requirements and designing architecture to writing code, testing, and deployment.
That experience completely changed how I approach software.
This is the process I follow now whether I’m building my own system or working with clients.
1. Understand the problem before writing code
Before I write a single line of code or even start a client project, I try to simplify the problem.
I want to understand:
- Who actually has this problem?
- What are they doing today?
- What is frustrating or inefficient?
- What is the minimum the product must solve first?
Then I identify the biggest constraint.
For a multi-tenant application, that constraint was tenant isolation.
One customer’s data must never leak into another customer’s data.
It affects everything:
- Authentication
- Authorization
- Database queries
- Middleware
- Sessions
If you miss this early, you can build something that works but becomes painful to fix later.
So instead of asking:
“Which framework should I use?”
I ask:
“What is the most dangerous thing that can go wrong?”
That question matters more than technology.
2. Keep the first version small
I don’t try to build everything at once.
I focus on the smallest complete end-to-end workflow.
For example:
- User registration
- Admin panel
- Tenant workspace
- Roles and permissions
- One working flow
I avoid unnecessary features early.
I prefer:
one complete working system
over
many incomplete features
This keeps development focused and practical.
3. Think about architecture before UI
UI is easy to change. Architecture is not.
So I think about:
- How is tenant identity handled?
- Where does data live?
- How is authentication done?
- Where is authorization enforced?
- What happens when context is missing?
For SaaS systems, I used a monolithic structure with strict boundaries and schema per tenant isolation.
The goal is not complexity.
The goal is clarity:
Who can access what, and how is it enforced?
4. Choose a stack I can maintain
Every technology has a cost:
- Debugging
- Deployment
- Maintenance
- Updates
So I follow a simple rule:
Don’t add technology because it exists. Add it because it solves a real problem.
If a monolith works, I keep it.
If a managed service is reliable, I use it.
The goal is to ship and maintain, not over-engineer.
5. Build the golden path early
Instead of building layers separately, I build the full user flow first:
Discover → Register → Approve → Activate → Use
This ensures everything connects early.
It quickly reveals missing pieces and broken assumptions.
6. Make security part of the release
Security is not a later step. It is part of “done.”
I always include:
- Role-based access control
- Tenant isolation checks
- Server-side validation
- Fail-closed behavior
- Cross-tenant tests
If a security issue can happen silently, I want tests to catch it early.
7. Onboarding is part of the product
A product is not just features. It is the journey before usage.
Example flow:
Registration → Approval → Payment → Activation → Workspace
Each step has meaning.
This makes system state clear and predictable.
8. Deploy early
I don’t wait for perfection.
I deploy early because real environments reveal real problems:
- Config issues
- Auth mismatches
- Build errors
- Production-only bugs
Even client projects benefit from early deployment.
Before I call it ready
I ask:
- Are core workflows complete?
- Is tenant isolation enforced?
- Are permissions tested?
- Can failures be debugged?
- Is onboarding clear?
If not, it is not ready.
What I’ve learned
A few principles always stay the same:
- Start with the hardest constraint
- Build one complete workflow first
- Enforce boundaries in architecture
- Test critical assumptions
- Treat onboarding and deployment as part of the product
Most importantly:
Don’t optimize for complexity. Optimize for clarity.
This is the same mindset I use for both SaaS products and client work through my freelance services (Fiverr gig).
Tools will change.
But clarity in thinking always wins.
How do you approach a new project?
What do you make sure is right before anything else?
Top comments (0)