Lessons from building 24hours.lk and its companion mobile suite, the 24 Eco System
Building an application is easy when everything is predictable. The database is clean. The API works. The user follows the expected flow. The server has enough resources. Nothing changes.
Real enterprise applications are nothing like that.
While working on 24hours.lk and the 24 Eco System mobile applications, I started to understand the difference between building something that works and building something that can survive in a real production environment. The most valuable part of the experience wasn't creating screens — it was dealing with everything that happens behind them.
It Started Looking Like a Normal Application
At first, an application can look deceptively simple: a user opens the app, authenticates, views some data, submits something. The backend processes the request. The database stores it. Done.
But that simple flow hides a much larger engineering problem:
- What happens if two requests arrive at exactly the same time?
- What happens if the database becomes slow?
- What happens if the mobile app is running an older API version?
- What happens if a user closes the app halfway through an operation?
- What happens when thousands of records need to be retrieved?
- What happens when one service goes down but the rest of the ecosystem keeps running?
That's where enterprise development really begins.
1. The Architecture Becomes More Important Than the Feature
One of the biggest mindset changes I experienced was realizing that a feature is never really isolated. A new feature can touch mobile UI → API → authentication → business logic → database → storage → notifications → infrastructure, all at once — and changing one part can unexpectedly affect another.
Because of that, I had to think about things like:
- Separation of concerns
- API contracts
- Service boundaries
- Database relationships
- Reusable business logic
- Error propagation
- Authentication flows
- Backward compatibility
- Deployment strategy
The question was no longer "How can I build this feature?" It became "Where should this feature actually live inside the architecture?" That's a completely different way of thinking.
2. The API Is the Contract Between the Ecosystem
When both web and mobile clients consume the same backend, the API becomes extremely important — a small API change can affect multiple clients at once.
24hours.lk Web
│
├──────────────┐
│ │
▼ ▼
API Layer → Business Logic
▲ │
│ ▼
│ Database
│
24 Eco System Mobile
This means an API can't simply be designed around what's convenient for one screen. It needs to account for request validation, response structure, pagination, filtering, authentication, authorization, error handling, version compatibility, performance, and mobile network conditions. The backend becomes the common language spoken by every application in the ecosystem.
3. Database Design Becomes a Real Engineering Problem
Working with real application data completely changes the way you think about databases. A database isn't just CREATE TABLE — or CREATE COLLECTION — and moving on. You have to think about how the data will grow, how frequently it will be queried, which fields need indexes, what happens when millions of records exist, and whether a relationship should be normalized or denormalized. Sometimes a query that looks perfectly reasonable during development becomes extremely expensive in production.
That pushed me to think more about:
- Indexing strategies
- Query optimization
- Data relationships
- Pagination
- Transactions
- Connection pooling
- Data consistency
- Migration strategies
- Read/write patterns
The database isn't simply storage. It's part of the application's performance architecture.
4. Concurrency Creates Problems You Don't See Locally
One of the more interesting things about enterprise applications is that multiple users can perform operations at the same time. Imagine two requests modifying the same piece of data within milliseconds — both can individually look correct, but together they can create an inconsistent state.
This introduces concepts like race conditions, atomic operations, transactions, isolation levels, idempotency, and optimistic/pessimistic locking — the kinds of problems you rarely notice when you're the only person using your development environment. Production is different: the system doesn't execute your code once. It executes it concurrently and unpredictably.
5. Authentication Is More Than Login
Implementing authentication taught me that "login" is only the visible part. Behind it are questions like:
- Who is this user?
- How long should their session remain valid?
- What happens when their token expires?
- What permissions do they have?
- Can this user access this resource?
- What happens if the request is replayed?
This introduces concepts such as access tokens, refresh tokens, session management, role-based access control, permission systems, token expiration, secure credential handling, and OAuth flows.
Authentication answers "Who are you?" Authorization answers "What are you allowed to do?" Enterprise systems need both.
6. Mobile Development Introduces Another Layer of Complexity
The 24 Eco System mobile applications introduced challenges that don't exist in quite the same way on the web. A mobile app operates under very different conditions. The user might have:
- Slow internet
- No internet
- An outdated app version
- Limited device resources
- Interrupted requests
- Background restrictions
- A different screen size or OS version
The server can be perfectly healthy while the user still experiences a failure. That means mobile applications need to be designed around unreliable environments — which changes how APIs, caching, error handling, loading states, retries, and synchronization all need to be approached.
7. Performance Is a Full-Stack Problem
When an application feels slow, the problem isn't necessarily the frontend. It could be frontend rendering, network latency, API processing, a database query, an external service, or server resources. A request that takes two seconds might actually break down like this:
Client rendering 150ms
Network 250ms
API processing 100ms
Database query 1,200ms
Response processing 300ms
Suddenly, the "frontend is slow" assumption becomes completely wrong. This made performance optimization much more interesting — you need to identify the actual bottleneck instead of optimizing randomly.
8. Production Errors Are Completely Different From Development Errors
Local development gives you a comfortable environment. Production doesn't. You start encountering problems caused by:
- Environment configuration
- Incorrect secrets
- Database permissions
- Network failures
- DNS
- SSL
- Deployment differences
- Resource limitations
- Unexpected user inputs
- Third-party service failures
And sometimes the most frustrating error is the one that simply says "Something went wrong."
Now you need observability. You need logs. You need meaningful error messages. You need to know what happened, where it happened, which request caused it, which user or service was involved, and what the system was doing at that moment. This is where logging, monitoring, tracing, and structured error handling become essential.
9. Deployment Changes the Way You Write Code
There's a huge difference between "it works on my machine" and "it works reliably in production." Deploying enterprise applications introduced another layer of engineering thinking — build processes, environment variables, production configuration, database migrations, domain configuration, SSL/TLS, CI/CD, server resources, rollbacks, backups, and monitoring.
A deployment isn't simply uploading code. It's changing a live system — which means every deployment needs to be treated carefully.
10. Backward Compatibility Is a Real Problem
One of the most interesting challenges of working across web and mobile is that users don't all run the latest version. Imagine the backend changes its response structure today — the web app updates immediately, but thousands of mobile users might still have an older version installed. Now the backend has to serve different generations of clients at once.
This is where API versioning, backward compatibility, deprecation, feature flags, and migration strategies become important. You aren't only developing for today's application — you're developing for multiple versions of yesterday's application as well.
11. Security Becomes a Continuous Battle
Enterprise applications are attractive targets because they contain valuable data, so security has to be considered at every layer:
Client → Authentication → API Gateway / Server → Authorization → Business Logic → Database → Infrastructure
A secure frontend doesn't compensate for an insecure API. An authenticated API doesn't compensate for broken authorization. A secure API doesn't compensate for exposed database credentials. Security is a chain, and the weakest link matters.
12. The Hardest Bugs Are Usually Not Syntax Errors
The most interesting bugs aren't usually undefined is not a function — those are easy compared to bugs caused by system behavior:
- A request succeeds but the UI doesn't update.
- Two operations happen simultaneously.
- A mobile client sends an outdated payload.
- A database query becomes slow only with large datasets.
- A token expires mid-request.
- A deployment works locally but fails in production.
- A service returns successfully before another service has finished processing the data.
These problems require system-level debugging. You need to follow the request across the architecture instead of staring at one file.
13. Enterprise Development Changed How I Debug
Earlier, debugging often meant "find the error, fix the code." Now I think more like "what is the system doing?" — tracing the flow:
User Action → Frontend → Network Request → Authentication → API → Business Logic → Database → External Service → Response → Frontend State
The error might originate in one layer but appear in another. That's why understanding the complete system is more valuable than understanding only one framework.
14. The Technology Stack Is Only Half the Story
Working on 24hours.lk and the 24 Eco System also taught me something important: knowing a framework is not the same as knowing software engineering. You can learn a framework, a programming language, how to build APIs — but enterprise development also requires understanding distributed systems, databases, networking, security, concurrency, caching, scalability, observability, deployment, and reliability.
The deeper you go, the less the problem is about syntax. It becomes about systems engineering.
What I Really Took Away
Working on 24hours.lk and the 24 Eco System changed my definition of a "developer." I no longer see an application as a collection of screens. I see it as a living system — one where users generate requests, APIs move data, business logic makes decisions, databases maintain state, infrastructure keeps everything alive, security protects the entire chain, and monitoring tells us when something goes wrong. Every one of those components has to work together.
The biggest lesson wasn't learning another framework. It was learning to think beyond the code.
Because building an enterprise application isn't about making something that works.
It's about building something that can keep working when reality starts attacking it.
Top comments (0)