From Making Features Work to Designing Systems: Anik Sikder on Architecture, SaaS, and Scale
From full-stack development to system design, multi-tenant SaaS, distributed systems, and AI-powered business automation.
Meet Anik Sikder
When you're starting out as a developer, success can feel very simple:
Does the feature work?
Authentication works.
The inventory page works.
The API returns the right response.
Ship it.
But as systems grow, the definition of "working" changes.
A feature that works for 10 users may struggle with 10,000. A design decision that seems harmless today can become a serious bottleneck later. And a system that is easy to build can become surprisingly difficult to maintain.
Anik Sikder has experienced that evolution firsthand.
Anik is a Full-Stack Engineer focused on SaaS, ERP and business systems, working primarily with technologies including Python, Django, FastAPI, React and Next.js. His current work focuses on multi-tenant SaaS architecture, ERP and business operating systems, RBAC, API design, system design and distributed systems. :contentReference[oaicite:3]{index=3}
He's also building BizNex OS, a multi-tenant ERP platform designed to bring areas such as inventory, procurement, sales, accounting, reporting, branches and warehouses into a connected business operating system. :contentReference[oaicite:4]{index=4}
But perhaps the most interesting part of Anik's journey is the change in how he thinks about software.
He started by asking:
"Does it work?"
Now he asks:
"How will it scale? What happens when something fails? Can another developer understand this six months from now? And what are the trade-offs?"
In this Developer Story, Anik shares how his thinking evolved from building individual features to designing entire systems, what building SaaS for real businesses taught him, why he chose a modular monolith for BizNex OS, what developers often misunderstand about distributed systems, and why architecture is ultimately about making good trade-offs.
Anik's Story
1. From Full-Stack Development to System Design
When I started, I was mostly focused on making features work.
If a user needed authentication, I built authentication.
If they needed inventory management, I built inventory management.
My success metric was simple:
Does it work?
Over time, I noticed that building features is actually the easiest part.
The hard part starts when the system grows.
A feature that works for 10 users might completely break down for 10,000 users. A design decision that feels harmless today can become a major bottleneck a year later.
That realization changed how I think.
Now, before writing code, I spend more time asking questions:
- How will this scale?
- What happens if this service goes down?
- Can another developer understand this six months later?
- What are the trade-offs?
I still enjoy coding, but architecture is where I find the most interesting problems.
Code solves today's problem. Architecture determines how many future problems you'll create.
2. Building SaaS for Real Businesses
One of the biggest lessons I've learned is that businesses don't buy software because it's technically impressive.
Developers love talking about frameworks, patterns, microservices, and scalability.
Business owners care about something much simpler:
"Will this save me time, money, or headaches?"
Early in my career, I focused heavily on technical elegance.
Later I realized that a simple solution that saves a business two hours a day is often more valuable than an architecturally beautiful system nobody uses.
Another thing I learned is that business processes are usually messy.
When you're building software for real companies, you quickly discover that every company has exceptions, special cases, and weird workflows that nobody documented.
The challenge isn't simply building software.
The challenge is understanding how people actually work.
3. Building BizNex OS
The idea behind BizNex OS came from a problem I kept seeing repeatedly.
Many small and medium businesses use five or six different tools to run their operations.
One tool for sales.
Another for inventory.
Another for accounting.
Another for HR.
And spreadsheets everywhere.
The result is fragmented data.
Nobody has a complete picture of what's happening inside the business.
I wanted to build something that treats a business as a connected system rather than a collection of disconnected modules.
Honestly, from a startup perspective, building a smaller SaaS product would probably be easier.
But I wasn't interested in solving just one workflow.
I wanted to understand how an entire organization operates and design a system around that.
It's definitely harder.
But it's also much more interesting.
4. The Challenge of Multi-Tenancy
Multi-tenancy sounds simple until you start implementing it.
The biggest concern is always tenant isolation.
A bug that exposes one company's data to another company isn't just a bug.
It's a trust-destroying event.
Because of that, I made tenant boundaries a first-class architectural concern.
Most queries are organization-scoped by default.
Permissions are organization-scoped.
Roles are organization-scoped.
Instead of relying on developers to "remember" tenant filtering, I try to make the architecture enforce it whenever possible.
Another lesson is that maintainability matters more than cleverness.
There are many technically sophisticated multi-tenant strategies, but if the team can't understand them, they'll become future problems.
Sometimes boring architecture is the best architecture.
5. Architecture Is About Trade-offs
One example is the decision between a traditional monolith and a microservices architecture.
Microservices are attractive.
They look modern.
They solve certain scaling challenges.
They allow independent deployments.
But they also introduce complexity.
Service discovery, distributed tracing, network failures, eventual consistency, and operational overhead — none of these exist in the same way in a simple monolith.
For BizNex OS, I chose a modular monolith approach.
Not because microservices are bad.
Because the complexity cost wasn't justified yet.
A lot of architecture decisions become easier when you stop asking:
"What's the most advanced solution?"
and start asking:
"What's the simplest solution that solves today's problem while keeping tomorrow's options open?"
That's how I think about architecture.
It's not about choosing the most impressive technology.
It's about choosing the right trade-off for the situation.
6. Learning from Large-Scale Systems
I don't study Facebook, Netflix, or Slack because I expect my projects to have billions of users.
I study them because they teach fundamental engineering principles.
For example:
- Netflix teaches resilience.
- Facebook teaches scalability.
- Slack teaches real-time communication.
What I find most interesting is that large-scale companies rarely solve problems with magic.
Most of the time they're solving the same problems we face, just at a larger scale.
Understanding their trade-offs helps me think more clearly about my own designs.
Not every solution should be copied.
But every solution teaches something.
7. Distributed Systems and Event-Driven Architecture
What attracts me to distributed systems is that they force you to think differently.
In a monolith, a function call either succeeds or fails.
In distributed systems, everything becomes uncertain.
Networks fail.
Messages arrive late.
Services go down.
Data becomes temporarily inconsistent.
You start realizing that software is really about handling failure.
One thing developers often misunderstand is that distributed systems are not an upgrade.
They're a trade-off.
Many teams move toward microservices because it feels modern.
But distributed systems introduce problems that monoliths simply don't have.
If your application doesn't need that complexity, adding it early can slow you down rather than help you.
The goal shouldn't be to build the most distributed system possible.
The goal should be to build the system that makes sense for the problem.
8. From Project to Production
Building my event management and ticketing system taught me a lesson I'll probably never forget:
Making something work is easy. Keeping it working is hard.
When you're building a personal project, success means the feature works on your machine.
In production, success means:
- It keeps working.
- It handles unexpected input.
- It survives failures.
- It remains maintainable.
Authentication, payments, permissions, QR verification — none of these are difficult because of the happy path.
They're difficult because of all the edge cases.
Production engineering is really the art of handling edge cases before your users discover them.
That was one of the biggest differences I learned between simply building a project and engineering something that needs to survive in the real world.
9. AI and Business Automation
I think AI is most valuable when it removes repetitive work.
For example:
- Document processing
- Data extraction
- Business insights
- Workflow automation
- Customer support assistance
These areas can generate immediate value.
Where I think the industry sometimes overuses AI is when AI is added simply because it's trendy.
Not every button needs a chatbot.
Not every workflow needs an LLM.
Sometimes a well-designed form solves the problem better than an AI assistant.
The question shouldn't be:
"Can we add AI?"
The question should be:
"Does AI actually improve the user's outcome?"
If the answer is no, don't add it.
10. Advice for Developers
The biggest shift is to stop thinking only about frameworks.
Frameworks change.
Principles don't.
Spend more time learning:
- Databases
- Networking
- Distributed systems
- Scalability
- Reliability
- Security
- Business domains
Another thing I'd recommend is building systems, not tutorials.
Tutorials teach features.
Systems teach trade-offs.
And finally, study real-world architectures.
Whenever you use a product like Uber, Netflix, Amazon, Stripe, or Slack, ask yourself:
"How would I build this?"
That simple question has taught me more about system design than many courses.
You don't need to reproduce the exact architecture of a massive technology company.
The point is to start thinking about:
- scale
- failure
- data
- consistency
- communication
- security
- reliability
- and trade-offs
The goal isn't to become the smartest engineer in the room.
The goal is to make good engineering decisions consistently.
In my experience, that's what separates developers from architects.
From Features to Systems
Looking back at my own development journey, the biggest change wasn't learning another framework.
It was changing the questions I ask before writing the code.
Early on, I asked:
Does this feature work?
Now I ask:
What happens when the system grows?
What happens when something fails?
Can someone else maintain this?
What are the trade-offs?
Does this actually solve the business problem?
That shift is what moved my thinking from simply building features toward designing systems.
And I think that's one of the most important transitions a developer can make.
You don't necessarily become a better engineer by knowing more frameworks.
Sometimes you become a better engineer by learning to ask better questions.
About Anik Sikder
Anik Sikder is a Full-Stack Engineer focused on SaaS, ERP and business systems.
He works primarily with Python, Django, FastAPI, React and Next.js, with a particular interest in system design, multi-tenant SaaS architecture, distributed systems, RBAC, API design and business automation. :contentReference[oaicite:5]{index=5}
He is currently building BizNex OS, a multi-tenant ERP platform designed to bring business operations such as inventory, procurement, sales, accounting, reporting, branches and warehouses into a connected system. :contentReference[oaicite:6]{index=6}
Anik is also exploring distributed systems, event-driven architecture, AI-powered business automation and cloud infrastructure. :contentReference[oaicite:7]{index=7}
You can learn more about his work at aniksikder.me.
A Final Thought
Modern software development can sometimes feel like a race to learn the newest framework, architecture pattern, or AI tool.
But the deeper lesson from Anik's journey is simpler.
Good engineering isn't about choosing the most advanced technology.
It's about understanding the problem, understanding the constraints, and making the right trade-offs.
A monolith can be the right architecture.
A simple form can be better than an AI assistant.
A boring solution can be better than a clever one.
And sometimes the most valuable engineering skill isn't writing more code.
It's knowing what code should be written in the first place.
This Developer Story is part of CoderLegion's Developer Stories series, where we share the real journeys, experiences, challenges, and lessons of developers from our community.
