DEV Community: DEVANSHU PATIL

The Hidden Cost of “Just One More Feature”

DEVANSHU PATIL — Fri, 25 Sep 2026 18:30:00 +0000

The Hidden Cost of “Just One More Feature”

When you're building a real application, adding a feature rarely means adding only a feature.

A new feature usually touches existing data, existing screens, existing business rules, and existing assumptions.

I've seen this repeatedly while building FinLedger.

At first, a request can sound simple:

"Add support for recurring transactions."

The obvious implementation is:

New screen
   ↓
Save recurring transaction
   ↓
Done

But that's not really the feature.

You also have to ask:

text When should it execute? What happens if the app wasn't opened? Can it create duplicates? How is the next occurrence calculated? What happens when the user edits it? What happens when it is disabled? Where is its state stored?

Suddenly, the feature is a system.

Features have dependencies

A useful way to think about a feature is:

text Feature ├── UI ├── State ├── Business rules ├── Persistence ├── Background work └── Existing features

The visible screen is often the smallest part.

For Android applications, this becomes especially important when a feature needs to survive beyond the current screen.

For example:

text Compose UI ↓ ViewModel ↓ Repository ↓ Room ↓ WorkManager

Each component may need to understand a different part of the feature.

Don't start by writing the screen

This is one habit I'm trying to improve.

Instead of immediately creating:

kotlin @Composable fun NewFeatureScreen() { // ... }

I want to first answer:

text What data does this feature own? What existing data does it depend on? What rules must always hold? What happens when the app is closed? What happens when the operation fails?

Those questions expose the real complexity before code starts spreading across the project.

Background work changes everything

A feature that only works while the app is open is fundamentally different from one that needs background execution.

For example:

text User opens app ↓ Calculate something ↓ Show result

is straightforward.

But:

text User configures something ↓ App closes ↓ Hours pass ↓ Background task runs ↓ Database changes ↓ User opens app ↓ UI reflects new state

Now you need to think about persistence, scheduling, retries, and idempotency.

This is why Android tools such as WorkManager become architectural components rather than just utilities.

Existing data is where complexity hides

Suppose you introduce a new field:

text recurring = true

What about existing records?

You now have a migration problem.

The application needs to understand both:

text Old database

and:

text New database

without destroying existing user data.

This is one reason database schema changes deserve more thought than they usually get during feature development.

The feature should have one source of truth

Another problem appears when the same state is stored in multiple places.

For example:

text UI state Database state Cached state Background worker state

If these can disagree, debugging becomes painful.

You might see:

text UI says: enabled Database says: disabled Worker thinks: enabled

Now the bug isn't in one line.

It's a synchronization problem.

A better design starts by deciding which layer owns the authoritative state.

More code isn't always more complete

There's also a trap in feature development:

text More classes More interfaces More abstractions More configuration

can create the illusion that the feature is production-ready.

It isn't.

A feature is complete when its important states and failure paths have been considered.

For example:

text Create Read Update Delete Empty state Invalid input Failure Retry Existing data App restart

The exact list depends on the feature, but the principle is the same.

My biggest takeaway

Building real software has made me more cautious about the phrase:

"It's just a small feature."

Small from the user's perspective does not necessarily mean small from the system's perspective.

The right question isn't:

"How quickly can I add this screen?"

It's:

"What parts of the existing system does this feature change?"

That question leads to better estimates, better architecture, and fewer surprises halfway through implementation.

**A feature isn't a screen.

A feature is a change to the system.**

android #kotlin #jetpackcompose #softwarearchitecture #finledger #room #workmanager #softwareengineering #buildinpublic

The Most Useful Backend Skill I Learned From Building on a Small VPS

DEVANSHU PATIL — Fri, 25 Sep 2026 06:08:14 +0000

The Most Useful Backend Skill I Learned From Building on a Small VPS

When building backend applications, it's easy to focus on frameworks.

Node.js.

Express.

MongoDB.

Docker.

APIs.

But running my own applications on a VPS taught me that the framework is only one part of backend engineering.

The more important skill is understanding what your application is actually doing on the machine.

An API is not just an endpoint

Suppose I have:

GET /api/projects

From the outside, it looks simple:

text Client ↓ HTTP request ↓ API response

But on the server, there is a lot more happening:

text Internet ↓ Reverse Proxy ↓ Application ↓ Business Logic ↓ Database ↓ Response

If something goes wrong, knowing Express syntax isn't enough.

I need to know which layer is responsible.

Start with the request lifecycle

A useful debugging model is:

text Request ↓ Routing ↓ Authentication ↓ Validation ↓ Business Logic ↓ Database ↓ Response

Each step can fail independently.

For example, if an API returns an unexpected result, I shouldn't immediately assume the database is wrong.

Maybe:

text Route matched incorrectly

or:

text Request body wasn't parsed as expected

or:

text Validation changed the input

or:

text The database query used the wrong filter

Tracing the lifecycle is usually faster than randomly changing code.

Logs should tell a story

A backend log should help answer:

text What request arrived? What did the application do? What external operation happened? What was the result? Why did the request fail?

For example:

text Request: POST /api/transactions Validation: passed Database: insert started Database: insert completed Response: 201

Compare that with:

text Error occurred

The second message technically tells you something went wrong.

It doesn't tell you why.

Don't expose internal errors to users

There's also an important distinction between developer information and client information.

Internally, an error might contain:

text Database connection timeout

But sending the entire internal error to the client isn't always appropriate.

The API can instead return something like:

json { "error": "Unable to process request" }

while the server logs contain the technical details needed for debugging.

That gives you two useful layers:

`text
Client
↓
Safe, meaningful error

Server
↓
Detailed diagnostic information
`

Validate at the boundary

One habit that becomes more important as an API grows is validating incoming data before passing it deeper into the system.

Instead of:

text Request ↓ Business logic ↓ Database

prefer:

text Request ↓ Validation ↓ Business logic ↓ Database

For example, if an endpoint expects:

json { "amount": 500 }

the application should not blindly assume that amount exists and is valid.

External input should be treated as untrusted.

That includes:

Request bodies
Query parameters
Path parameters
Headers
Uploaded data
Third-party API responses

Database connections are part of backend engineering

An application can have perfectly good business logic and still fail because its database connection isn't healthy.

The backend therefore needs to account for things like:

text Connection failures Timeouts Unavailable database Invalid queries Unexpected data

This is one reason I prefer understanding the entire stack rather than treating the database as something that simply "works."

The application depends on it.

Deployment makes backend problems more real

Locally, an application might look like:

text localhost ↓ Node.js ↓ MongoDB

On a VPS, the environment becomes more realistic:

text Internet ↓ DNS ↓ Traefik ↓ Docker ↓ Node.js ↓ MongoDB

Now networking, environment variables, TLS, firewall rules, container health, logs, storage, and resource usage all matter.

This is where backend development starts feeling less like writing endpoints and more like engineering a system.

The lesson

Building and self-hosting applications has changed how I think about backend development.

I don't want to only know:

"How do I write this API?"

I also want to know:

"What happens to this request from the moment it enters the server until the response leaves it?"

That understanding makes debugging easier, architecture decisions clearer, and deployments less mysterious.

The framework is just one layer.

Backend engineering is understanding the entire path that your data takes through the system.

backend #nodejs #express #mongodb #api #docker #linux #devops #softwareengineering #selfhosting #buildinpublic

The Hard Part of an API Isn't Calling It

DEVANSHU PATIL — Thu, 24 Sep 2026 01:38:00 +0000

The Hard Part of an API Isn't Calling It

When I started working with APIs, it was easy to think of them as simple plumbing:

Request → API → Response

Call an endpoint, parse JSON, display the result.

That mental model works for a while.

Then you build software that depends on real APIs, and you realize the difficult part isn't making the HTTP request.

The difficult part is deciding what your application should do when the API doesn't behave exactly as expected.

A successful HTTP request doesn't mean successful data

Consider:

GET /transactions

You might receive:

{
  "transactions": []
}

The request succeeded.

But what does an empty result mean?

No transactions exist?
Wrong account?
Wrong date range?
Temporary backend issue?
Incorrect query parameters?

The HTTP request alone doesn't tell you the business meaning.

Your application needs to interpret the response.

Treat external APIs as boundaries

A useful mental model is:

Your application
       ↓
API boundary
       ↓
External system

Everything outside your application is something you don't fully control.

The API might:

Return an unexpected status code
Change a field
Return missing data
Take too long
Fail temporarily
Return malformed data
Reject a request
Return a valid response with unexpected business meaning

So the API layer should be treated as a boundary where external data becomes internal application data.

Don't spread API models everywhere

Suppose an API returns:

{
  "user_id": 42,
  "display_name": "Devanshu",
  "created_at": "2026-09-22T00:00:00Z"
}

You don't necessarily want every part of your application to depend directly on that structure.

A useful approach is to map external data into your own model:

API Response
     ↓
DTO
     ↓
Mapper
     ↓
Domain Model
     ↓
Application

For example:

data class UserDto(
    val user_id: Long,
    val display_name: String,
    val created_at: String
)

could become:

data class User(
    val id: Long,
    val name: String,
    val createdAt: Instant
)

Now the rest of the application doesn't need to know how the external API names its fields.

Error handling should have meaning

This is another place where simplistic API handling causes problems.

You don't want every failure to become:

Something went wrong.

Different failures can require different behavior.

For example:

401 → Authentication problem
403 → Permission problem
404 → Resource doesn't exist
429 → Rate limit
500 → Server-side failure
Timeout → Network problem

The application can then decide what makes sense for each case.

Maybe a timeout should be retried.

Maybe a 401 should require authentication again.

Maybe a 404 should show an empty state.

Maybe a 500 should be surfaced as a temporary error.

The important part is that the API layer shouldn't throw away useful information.

Retries are not always harmless

It's tempting to automatically retry every failed request.

But imagine an endpoint that creates a transaction:

POST /transactions

The request reaches the server.

The server creates the transaction.

Then the network connection fails before the client receives the response.

The client sees:

Request failed

Should it send the request again?

Maybe.

But if the operation isn't idempotent, you might create the transaction twice.

This is why retries need to be designed around the operation.

A read request and a money-moving operation shouldn't necessarily have the same retry strategy.

Timeouts are part of API design

A request without a sensible timeout can leave the application waiting unnecessarily.

Conceptually:

Request
  ↓
Waiting...
  ↓
Waiting...
  ↓
Waiting...

The user doesn't care that the TCP connection technically still exists.

They care that the application appears stuck.

A timeout gives the system a defined failure state:

Request
  ↓
Timeout
  ↓
Handle failure
  ↓
Retry / cached data / error UI

Failure is easier to manage when it has boundaries.

The API should not define your entire architecture

This is probably the biggest lesson.

If your application structure mirrors an external API too closely:

API
 ↓
Everything else

then an API change can ripple through the entire codebase.

Instead, I prefer thinking in terms of:

External API
     ↓
Integration layer
     ↓
Application model
     ↓
Business logic
     ↓
UI

The external API is an input to the system.

It shouldn't automatically become the system's architecture.

What I'm learning

Working with APIs has changed the way I think about network code.

The important question isn't:

"How do I call this endpoint?"

It's:

"How does my application safely depend on a system I don't control?"

That question leads to better decisions around:

DTOs
Mapping
Validation
Error handling
Timeouts
Retries
Caching
Idempotency
Logging

The HTTP request is usually the easy part.

The engineering starts after you realize the response isn't guaranteed to be exactly what you wanted.

api #backend #kotlin #android #softwarearchitecture #webdevelopment #systemdesign #programming #softwareengineering #buildinpublic

Self-Hosting Taught Me That Deployment Is Part of Development

DEVANSHU PATIL — Wed, 23 Sep 2026 13:37:15 +0000

Self-Hosting Taught Me That Deployment Is Part of Development

When I first thought about deploying an application, I mostly thought about getting the application onto a server.

Build the project.

Start the process.

Point the domain to it.

Done.

Running applications on my own VPS changed that perspective.

Deployment isn't the final step after development.

Deployment is another part of the system you are building.

My deployment stack is intentionally simple

For my self-hosted applications, I've worked with an Oracle Cloud Always Free VPS, Docker, Coolify, Traefik, MongoDB, HTTPS, and Linux server configuration.

The important thing isn't the specific tools.

It's the chain connecting them:

Internet
   ↓
Domain
   ↓
DNS
   ↓
VPS
   ↓
Traefik
   ↓
Docker container
   ↓
Application
   ↓
Database

When everything works, this feels invisible.

When something breaks, every layer matters.

A deployment is a system

Suppose my application isn't reachable.

There are many possible causes:

text DNS problem ↓ Firewall problem ↓ Reverse proxy problem ↓ Container problem ↓ Application problem ↓ Database problem

If I only know how to start the application, I can still be completely stuck.

That's why self-hosting has been useful for learning.

It forces me to understand what happens outside the application code.

Reverse proxies are more than "configuration"

A reverse proxy sits between the public internet and the application.

Conceptually:

text Client ↓ HTTPS ↓ Traefik ↓ Application container

It can handle things such as routing traffic to the correct service and terminating HTTPS.

This becomes especially useful when multiple applications need to run on the same server.

For example:

text app.example.com api.example.com admin.example.com

can all point toward the same VPS while the reverse proxy decides where the traffic should go.

The application doesn't need to expose every service directly to the internet.

Containers solve one problem, not everything

Docker makes application deployment much more reproducible.

Instead of manually installing every dependency on the server, I can package the application environment into a container.

Conceptually:

text Application + Dependencies + Runtime ↓ Container

But containers don't magically solve operational problems.

You still need to think about:

text Logs Storage Networking Environment variables Backups Updates Security Resource usage

A container can make deployment easier while still leaving you with a badly designed deployment.

Linux knowledge becomes practical very quickly

Self-hosting also made Linux commands much more useful to me.

Instead of learning commands only because they appear in tutorials, there is now a reason behind them.

For example:

bash free -h

helps inspect memory.

bash df -h

helps inspect disk usage.

bash uptime

gives a quick view of system load and uptime.

And process/container logs can tell you what the application is actually doing.

The important skill isn't memorizing commands.

It's knowing which question each command helps answer.

Monitoring changes how you think

A server can be "working" while slowly heading toward a problem.

For example:

text Disk usage increasing ↓ Logs accumulate ↓ Available storage decreases ↓ Eventually something fails

The application might appear perfectly healthy until the moment it isn't.

This is why monitoring resources such as:

text CPU RAM Disk Network Container health Application logs

matters even for small projects.

You don't need a massive observability platform to start paying attention.

The uncomfortable part of self-hosting

Self-hosting gives you control.

It also gives you responsibility.

If you use a managed platform, many infrastructure problems are someone else's responsibility.

On your own VPS, they aren't.

You become responsible for understanding:

text Updates Security Firewall rules Backups SSL Resource limits Database availability Application failures

That's not a downside if your goal is to learn infrastructure.

But pretending self-hosting is just "free hosting" misses the point.

The infrastructure becomes your problem.

The lesson

The biggest thing I have learned from deploying my own applications is that the code is only one part of the product.

A working application needs:

text Code + Database + Networking + Infrastructure + Security + Deployment + Monitoring

You don't need to master all of these before deploying your first project.

But you should understand enough of each layer to troubleshoot when something inevitably goes wrong.

That's what makes deployment engineering rather than simply uploading a project to a server.

The moment your application is running on a real machine connected to the internet, infrastructure becomes part of your codebase—even if it isn't written in your programming language.

devops #linux #vps #selfhosting #docker #coolify #traefik #deployment #backend #softwareengineering

Debugging Got Easier When I Stopped Guessing

DEVANSHU PATIL — Tue, 22 Sep 2026 05:49:00 +0000

Debugging Got Easier When I Stopped Guessing

One of the biggest mistakes I make while debugging is trying to fix the problem before understanding it.

A screen doesn't update.

An API returns unexpected data.

A database query gives the wrong result.

A deployment fails.

The instinct is immediately:

"What code should I change?"

I've found a better question is:

"What exactly do I know is failing?"

That small change in mindset makes debugging much more systematic.

Start with the symptom

Suppose an Android screen isn't showing a transaction.

There are several possible failures:

User action
    ↓
ViewModel
    ↓
Repository
    ↓
Room
    ↓
Database

The UI might be the problem.

But it could also be:

The event never reached the ViewModel
The ViewModel didn't call the repository
The repository queried the wrong data
The database contains unexpected data
The state wasn't updated
The Compose UI isn't observing the expected state

Looking only at the screen can send you in completely the wrong direction.

Follow the data

Instead of changing code randomly, I try to trace the value through the system.

For example:

text Expected transaction ↓ Was the user action triggered? ↓ Was the ViewModel called? ↓ Was the repository called? ↓ Did the database query return the record? ↓ Did the state contain the record? ↓ Did the UI receive that state?

At some point, the expected behavior diverges from the actual behavior.

That's where I want to investigate.

Logs should answer questions

Adding logs everywhere isn't debugging.

Useful logs answer specific questions.

For example:

text Fetching transactions for personId = 42 Query returned 3 transactions Calculated balance = ₹2500 Updating UI state

Now the logs tell you something about the execution path.

Compare that with:

text DEBUG: function called DEBUG: something happened DEBUG: result

Those logs create noise without explaining the system.

The goal isn't to have more logs.

It's to have useful evidence.

Reproduce before fixing

If a bug happens only sometimes, the first objective should be making it reproducible.

Try to identify:

`text
Input
+
Sequence of actions
+

Application state

Bug
`

For example:

text Open transaction → Edit amount → Save → Navigate back → Open transaction again → Incorrect value appears

Now you have a scenario you can test repeatedly.

Without reproducibility, you can easily "fix" the wrong problem.

Check assumptions

A surprisingly large number of bugs come from assumptions.

For example:

"This ID can never be null."

"This API always returns this field."

"This query always returns one record."

"The database must contain the correct value."

"The code definitely reached this function."

Instead of trusting the assumption, verify it.

text Assumption ↓ Evidence ↓ Confirmed / disproved

This is especially important when debugging systems with multiple layers.

Don't change five things at once

If I change:

text Query + ViewModel + UI state + Database schema + API response

and the bug disappears, I still don't know what actually fixed it.

Worse, I might have introduced another bug.

A better approach is:

text Hypothesis ↓ Small change / test ↓ Observe result ↓ Update hypothesis

Debugging becomes an investigation rather than a guessing game.

The same method works outside Android

This approach isn't specific to Compose or Kotlin.

For a backend request:

text Client ↓ Reverse proxy ↓ API ↓ Business logic ↓ Database

For a VPS deployment:

text DNS ↓ Server ↓ Reverse proxy ↓ Container ↓ Application

For every system, the same question applies:

Where does the actual behavior first differ from the expected behavior?

Find that point.

Then investigate it.

The lesson I'm taking from this

Debugging isn't primarily about knowing more fixes.

It's about reducing uncertainty.

At the beginning:

text Something is broken.

After investigation:

text The request reaches the API. The API returns the correct data. The repository receives it. The ViewModel state is correct. The UI is displaying stale state.

Now the problem is much smaller.

And once the problem is smaller, the fix is usually much easier to find.

**Don't debug by changing code until something works.

Debug by collecting evidence until you know what is wrong.**

debugging #android #kotlin #softwareengineering #backend #programming #jetpackcompose #development #buildinpublic

Why I Keep My Database Layer Boring

DEVANSHU PATIL — Sun, 20 Sep 2026 18:42:00 +0000

Why I Keep My Database Layer Boring

When building an application, it's easy to get excited about the visible parts.

A new Compose screen.

A better API.

A new feature.

A cleaner dashboard.

The database usually gets less attention.

But while working on FinLedger, I've found that the database layer is one of the places where boring engineering is actually a good thing.

For a finance application, I don't want the database to be clever.

I want it to be predictable.

Start with the data model

Before writing queries, I need to understand what I'm actually storing.

For example, a transaction isn't just:

amount

It can have relationships with other parts of the application:

text Transaction ├── amount ├── date ├── type ├── category/tag ├── person └── other metadata

Those relationships matter.

If the data model is unclear, the application code eventually becomes full of special cases trying to compensate for it.

Keep persistence responsibilities clear

A useful separation looks like:

text UI ↓ ViewModel ↓ Repository ↓ DAO ↓ Room ↓ SQLite

The UI shouldn't need to know SQL.

The DAO shouldn't decide business rules.

The repository shouldn't become a second UI layer.

Each component should have a reasonably narrow responsibility.

For example, a DAO might answer:

kotlin @Query("SELECT * FROM transactions ORDER BY date DESC") fun observeTransactions(): Flow<List<Transaction>>

Its job is retrieving data.

It shouldn't also decide how the dashboard calculates financial insights.

Database constraints are useful

It's tempting to rely entirely on application code for validation.

But the database can enforce important assumptions too.

For example:

text amount cannot be NULL required relationship must exist identifier must be unique

Why duplicate validation?

Because different parts of an application can eventually write data.

A database constraint provides a final line of defense.

Application validation improves the user experience.

Database constraints protect the integrity of stored data.

They're solving different problems.

Don't make every query generic

Another trap is trying to build a universal repository that can do everything.

Something like:

text save() update() delete() find() query()

can look clean at first.

But eventually the repository becomes an abstraction that hides what the application is actually doing.

A specific operation can sometimes be clearer:

text getTransactionsForMonth() getTransactionsForPerson() getTransactionsByType()

The database layer should make important data access patterns understandable.

Abstraction is useful when it removes meaningful complexity.

If it only hides a simple query behind five interfaces, it may be making the code harder to understand.

Observe data instead of manually refreshing everything

One thing I like about using Room with Kotlin is the ability to work with observable data.

Conceptually:

text Database changes ↓ Flow emits new data ↓ ViewModel receives state ↓ Compose recomposes

That is cleaner than having every screen manually ask:

"Did the database change?"

The data source can become the trigger for updating the UI.

Performance still matters

A database can work correctly and still become a performance problem.

For example, fetching a huge dataset when the screen only needs the latest records is wasteful.

Instead of:

text Load everything ↓ Filter in application ↓ Display 20 records

you often want:

text Query only what you need ↓ Return relevant records ↓ Display them

The database is good at filtering data.

Use it.

The boring database principle

The more important the data, the less interested I am in clever persistence logic.

For a financial application, I want:

text Predictable schema Clear relationships Explicit queries Useful constraints Observable data Simple migrations

Not:

text Magic abstraction Hidden side effects Queries nobody understands Business rules scattered across DAOs

The database should be something I can inspect and reason about when something goes wrong.

The bigger lesson

I've started thinking about database code differently.

The goal isn't to write the most sophisticated persistence layer.

The goal is to make it hard to accidentally corrupt the application's data model.

That's especially important for software where the data represents something users care about.

Fancy architecture is useful when it solves a real problem.

But for the foundation of an application, boring is often a feature.

**Make the database predictable.

Make the queries understandable.

Make the data difficult to corrupt.

Then build the interesting features on top of it.**

android #kotlin #room #database #sqlite #softwarearchitecture #jetpackcompose #softwareengineering #buildinpublic

A Fast VPS Is Useless If You Can't Explain Why It's Slow

DEVANSHU PATIL — Sun, 20 Sep 2026 15:12:00 +0000

A Fast VPS Is Useless If You Can't Explain Why It's Slow

One of the most useful habits I've picked up from running applications on my own VPS is this:

Don't optimize based on feelings. Measure the request.

When a website feels slow, it's tempting to immediately blame the server.

Maybe the VPS needs more RAM.

Maybe the CPU is too slow.

Maybe Docker is the problem.

Maybe the database is slow.

But "the website is slow" isn't a diagnosis.

It's a symptom.

Break the request into pieces

A web request isn't one operation.

Conceptually, it looks more like:

Browser
   ↓
DNS lookup
   ↓
TCP connection
   ↓
TLS handshake
   ↓
Server / reverse proxy
   ↓
Application
   ↓
Database
   ↓
Response

If the total response time is high, the first job is finding which part is responsible.

For example, if the request takes 800 ms:

text DNS → 20 ms Connect → 30 ms TLS → 80 ms Server → 650 ms

Then replacing your VPS probably isn't the first thing you should do.

The application or database deserves investigation.

TTFB is useful

One metric I pay attention to is Time To First Byte (TTFB).

It gives you a useful indication of how long it takes before the server starts responding.

You can use tools such as curl to inspect different parts of the request.

For example:

bash curl -o /dev/null -s \ -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \ https://example.com

The exact numbers aren't as important as the pattern.

If DNS is taking most of the time, investigate DNS.

If TLS dominates, investigate the connection path.

If TTFB is high, look closer at the server-side work.

If everything is fast until the browser renders the page, the bottleneck may be somewhere else entirely.

Don't confuse server resources with application performance

A server can have plenty of CPU and RAM and still serve a slow application.

For example:

text VPS ├── CPU: plenty available ├── RAM: plenty available └── Application: slow database query

Adding more resources doesn't necessarily fix the underlying problem.

The same applies in reverse.

If the server is genuinely overloaded, optimizing one SQL query won't solve the infrastructure bottleneck.

You need evidence before deciding which layer deserves attention.

Measure before changing architecture

This is especially important when self-hosting.

It's easy to jump from:

"My application is slow."

to:

"I need Kubernetes."

You probably don't.

At least, you don't know that yet.

Start with simpler questions:

text Is the CPU saturated? Is memory under pressure? Is swap being used heavily? Is the database slow? Is the application blocking? Is the network slow? Is the reverse proxy introducing latency?

Then measure.

Only after that should you consider architectural changes.

Simple infrastructure makes debugging easier

One reason I like running relatively straightforward deployments is that the system remains understandable.

A request might pass through:

text Internet ↓ Traefik ↓ Docker container ↓ Application ↓ Database

If something breaks, there are a limited number of places to investigate.

That's much better than adding infrastructure simply because it sounds more professional.

Complexity has a cost.

Every additional component becomes another thing you need to monitor, configure, secure, upgrade, and debug.

The lesson

Performance engineering isn't:

text Slow ↓ Buy bigger server

It's:

text Slow ↓ Measure ↓ Locate bottleneck ↓ Understand cause ↓ Optimize ↓ Measure again

That's a much more reliable process.

Running applications on a VPS has made this especially obvious to me.

You don't need an enormous infrastructure stack to learn performance engineering.

Sometimes a VPS, Linux tools, application logs, and a few well-chosen measurements are enough to teach you where your system is actually spending its time.

**Don't optimize the server you imagine you have.

Optimize the bottleneck you can prove exists.**

linux #vps #selfhosting #devops #performance #backend #docker #webdevelopment #softwareengineering

Parsing SMS Transactions Is a Data Quality Problem, Not Just a Regex Problem

DEVANSHU PATIL — Sat, 19 Sep 2026 14:11:05 +0000

Parsing SMS Transactions Is a Data Quality Problem, Not Just a Regex Problem

One of the more interesting parts of building FinLedger has been working with transaction data that doesn't arrive in a clean format.

When transaction information comes from SMS messages, the application isn't receiving a nice API response like:

{
  "amount": 500,
  "merchant": "Example Store",
  "type": "DEBIT"
}

Instead, it may receive human-readable text.

That changes the problem completely.

The input is messy

A transaction message might conceptually contain:

Your account has been debited by Rs. 500
at Example Store.

Another message from a different bank may use completely different wording.

So the parser has to identify useful information from text rather than simply reading predefined fields.

The pipeline becomes something like:

SMS
 ↓
Parser
 ↓
Extracted transaction data
 ↓
Validation
 ↓
Transaction model
 ↓
Local database

The important part is that parsing and accepting data are not the same thing.

Regex is useful, but it isn't the whole solution

Regular expressions can be useful for extracting predictable pieces of information.

For example, an amount might follow a pattern such as:

Rs. 500
INR 500.00
₹500

A parser can look for these patterns.

But extracting:

doesn't prove that the message represents a valid transaction.

You still need to answer:

Is this actually a financial transaction?
Is it a debit or credit?
Can the amount be trusted?
Was the transaction already processed?
Can the date be determined?

Extraction gives you candidate data.

Validation decides whether that data should enter your accounting system.

False positives are dangerous

For a finance application, an incorrect transaction can be worse than a missed transaction.

Imagine a parser incorrectly interprets a promotional SMS as:

Expense = ₹500

The application has now corrupted the user's financial history.

That's why automated parsing should be conservative.

A useful mindset is:

Unknown
   ↓
Try to parse
   ↓
Validate
   ↓
Accept only if sufficiently reliable

Don't force every message into a transaction.

Idempotency matters too

Automation creates another problem: the same message might be processed more than once.

If the application sees the same transaction twice:

SMS
 ↓
Parse
 ↓
Create transaction

and later processes it again:

Same SMS
 ↓
Parse
 ↓
Create another transaction

the user's balance can become incorrect.

So automated ingestion needs some way to recognize that a transaction has already been processed.

The general principle is:

Processing the same input twice should not accidentally create two financial events.

This is the same kind of problem you'll encounter in backend systems, payment processing, message queues, and distributed systems.

Store useful raw information

Another useful design consideration is keeping enough information to investigate parsing decisions.

Instead of only storing:

amount = 500
type = DEBIT

the system may benefit from retaining appropriate source information or metadata that allows the application to understand where the transaction came from.

Why?

Because when parsing goes wrong, you need evidence.

Without the original context, debugging becomes much harder.

Parsing should be treated as an evolving system

Bank and payment messages aren't necessarily designed as a stable API contract for your application.

Formats can differ between institutions and can change over time.

That means a parser shouldn't be treated as:

Write regex once
↓
Never touch it again

A better mental model is:

Input formats
     ↓
Detection
     ↓
Extraction
     ↓
Normalization
     ↓
Validation
     ↓
Transaction

Each stage has a responsibility.

That makes failures easier to understand.

The bigger lesson

Building an automated transaction parser has reinforced something I keep seeing across software engineering:

Real-world data is rarely as clean as the data in your database schema.

The database might expect:

amount
type
date
merchant

But the outside world gives you:

unstructured text
different formats
missing fields
unexpected wording
duplicate events

The engineering challenge is building a reliable boundary between those two worlds.

And that principle applies far beyond SMS parsing.

APIs can change.

User input can be malformed.

Third-party integrations can behave unexpectedly.

Files can have inconsistent formats.

Your application should treat external data as untrusted input and make it trustworthy before building business logic on top of it.

android #kotlin #fintech #softwareengineering #parsing #databases #architecture #jetpackcompose #buildinpublic

Offline-First Doesn't Mean "No Internet"

DEVANSHU PATIL — Wed, 16 Sep 2026 02:45:44 +0000

Offline-First Doesn't Mean "No Internet"

One architectural decision I've found particularly interesting while building FinLedger is the idea of making the application offline-first.

At first, "offline-first" can sound like:

The app should work without the internet.

That's true, but it's not the complete idea.

The more important question is:

What should the application consider its source of truth when the network is unavailable?

For a personal finance application, I think this matters a lot.

The database should not depend on the network

If I record a transaction, I don't want the core operation to depend on an API being available.

A useful flow is:

User action
    ↓
Local database
    ↓
UI updates

The network becomes an additional capability rather than a requirement for basic functionality.

This is one reason local persistence is so important in an offline-first architecture.

With FinLedger, the application is designed around local data and uses Android technologies such as Kotlin, Jetpack Compose, Room, and WorkManager.

Think about the source of truth

Imagine I add:

text Expense: ₹500

The UI shouldn't need to wait for:

text Internet ↓ API ↓ Server ↓ Response ↓ Database ↓ UI

just to show the transaction.

Instead:

text Expense created ↓ Room database updated ↓ Observable state changes ↓ Compose UI updates

The user gets immediate feedback.

The application can then perform network-related work separately when necessary.

Offline-first changes how you design features

Consider exchange rates.

Unlike a locally created transaction, exchange rates are external data.

They may require a network request.

So the architecture can treat them differently:

text Local transaction ↓ Local database ↓ Immediately available

versus:

text Exchange rate ↓ Fetch from API ↓ Store locally ↓ Use cached value when offline

Now the application can still provide useful functionality even when the network isn't currently available.

WorkManager fits naturally here

Some operations don't need to happen immediately.

For example, background work can be scheduled for tasks that should happen when the required conditions are available.

Conceptually:

text Application ↓ Schedule background work ↓ WorkManager ↓ Check constraints ↓ Perform operation

This is different from blocking the user's current interaction until the network finishes.

The user can continue using the application while background work happens independently.

Offline-first also creates new problems

It's not automatically easier.

You now have to think about:

Stale data
Synchronization
Conflicts
Failed requests
Retries
Cached data
Data consistency
Background execution

For a fully local application, some of these problems disappear.

But once remote data or synchronization is introduced, they become architectural concerns.

That's why I don't think "offline-first" should be treated as just a feature.

It's a data architecture decision.

The important distinction

There is a big difference between:

text Offline-capable

and:

text Offline-first

An offline-capable application might say:

"If the internet disappears, we'll try to keep working."

An offline-first application starts from:

"The local experience should work independently, and network connectivity is something we can use when available."

That difference affects the architecture from the beginning.

What I'm learning

Building a real application has made me think less about individual technologies and more about the responsibilities between them.

Room isn't just a database library.

WorkManager isn't just a background-task API.

Jetpack Compose isn't just a UI toolkit.

Together, they can support an architecture where the application doesn't make the network a dependency for every user action.

For a finance application, that makes sense to me.

Your transaction history shouldn't become inaccessible simply because your connection disappeared.

A good offline-first architecture doesn't pretend the network doesn't exist.

It makes sure the application doesn't depend on it for everything.

android #kotlin #jetpackcompose #room #workmanager #architecture #mobiledevelopment #softwareengineering #buildinpublic

When a Feature Looks Simple, Write Down Its Invariants First

DEVANSHU PATIL — Tue, 15 Sep 2026 05:55:14 +0000

When a Feature Looks Simple, Write Down Its Invariants First

One of the things I've learned while building FinLedger is that a feature can look simple from the UI while being surprisingly complicated underneath.

Take something like editing a transaction.

At first glance:

Tap transaction
   ↓
Edit amount
   ↓
Save

Easy.

But the moment real data is involved, the questions start:

What if the amount changes?
What if the transaction type changes?
What happens to the current balance?
What happens to the transaction history?
What if the record no longer exists?
What if the user saves the same data without making changes?

These aren't UI questions.

They're business-rule questions.

Start with invariants

An invariant is something that should remain true regardless of which operation the user performs.

For a transaction system, examples might look like:

Amount must be valid
A transaction must belong to a valid entity
A balance must be calculated consistently
A deleted record must not leave invalid references

The exact rules depend on the application, but writing them down changes how you implement the feature.

Instead of starting with:

"Which Compose components do I need?"

you start with:

"What must always be true after this operation?"

That's a much better starting point.

Think about the operation as a state transition

A useful way to reason about changes is:

Before
  ↓
Operation
  ↓
After

For example:

Before:
Outstanding = ₹5,000

Edit transaction:
₹5,000 → ₹7,000

After:
Outstanding = ₹7,000

Now consider a more complicated case:

Before:
Outstanding = ₹5,000

Repayment:
₹2,000

After:
Outstanding = ₹3,000

The important question isn't simply how to update a number.

It's whether the operation preserves all the relationships and history the application expects.

Don't let the UI define your business logic

This is where architecture becomes important.

A screen might collect:

amount
type
date
note

But it shouldn't be responsible for deciding what those values mean to the entire application.

A cleaner flow is something like:

Compose UI
    ↓
User event
    ↓
ViewModel
    ↓
Business logic
    ↓
Repository
    ↓
Database

The UI collects intent.

The business layer determines what that intent means.

The repository handles persistence.

That separation makes the feature easier to test and reason about.

Edge cases expose weak designs

The happy path rarely tells you whether your design is good.

Try the uncomfortable cases:

Edit an existing transaction
Edit it without changing anything
Change the amount
Change the transaction type
Delete it immediately after editing
Open an old transaction
Use invalid input
Perform the operation twice

If the system behaves consistently across these cases, your design is probably getting stronger.

If every edge case requires another special condition, that's a warning sign.

The problem may not be the edge cases.

The problem may be the underlying model.

The lesson I'm taking from this

I've started trying to solve fewer problems by immediately writing code.

Before implementing a feature, I want to understand:

What state exists?
What can change?
What must remain true?
What events can modify it?
What happens when the operation fails?
What happens when it is repeated?

This is especially important in applications where data has relationships and history.

A feature isn't just a screen.

It's a state transition inside a larger system.

And the better you understand that transition before coding, the less likely you are to build a feature that works only in the happy path.

android #kotlin #jetpackcompose #softwarearchitecture #backend #databases #systemdesign #buildinpublic

Jetpack Compose Made Me Rethink How I Build UI

DEVANSHU PATIL — Mon, 14 Sep 2026 10:13:31 +0000

Jetpack Compose Made Me Rethink How I Build UI

When I started working with Jetpack Compose, the biggest change wasn't the syntax.

It was the way I had to think about UI.

With traditional Android UI, it's easy to think in terms of views:

Find a view
 ↓
Change its value
 ↓
Update another view
 ↓
Refresh something

Compose pushes you toward a different model:

text State ↓ UI ↓ User action ↓ State changes ↓ UI recomposes

The UI becomes a function of state.

Don't make the UI the source of truth

Consider a simple screen displaying a transaction.

Instead of having the UI independently track everything, the screen can consume a state object:

kotlin data class TransactionUiState( val transactions: List<Transaction>, val isLoading: Boolean, val error: String? = null )

Then the UI can essentially ask:

"Given this state, what should I display?"

For example:

kotlin when { state.isLoading -> LoadingIndicator() state.error != null -> ErrorMessage(state.error) state.transactions.isEmpty() -> EmptyState() else -> TransactionList(state.transactions) }

This is much easier to reason about than having different pieces of UI independently deciding what state the screen is in.

Events should flow in one direction

A pattern I've found useful is treating user interactions as events.

For example:

text User taps Save ↓ onSaveClicked() ↓ ViewModel ↓ Repository ↓ Data changes ↓ New UI state ↓ Compose recomposes

The UI doesn't need to know how the transaction is stored.

It only needs to communicate the user's intent.

For example:

kotlin Button( onClick = { viewModel.saveTransaction() } ) { Text("Save") }

The ViewModel handles what happens next.

That separation becomes increasingly useful as the application grows.

Recomposition isn't something to fear

One of the first concepts that can feel strange with Compose is recomposition.

The important mental model is:

Your composable should be able to run again.

That means avoiding unnecessary side effects directly inside composable functions.

Instead of thinking:

text "This function runs once."

think:

text "This function describes the UI for the current state."

If the state changes, Compose may run the composable again.

That's not a bug.

That's the point.

State ownership matters

Another important question is:

"Who should own this state?"

Not every piece of state belongs in the ViewModel.

For example, temporary UI state such as whether a dropdown is expanded can often remain local to the composable.

But application state such as:

text Transactions Current balance Loading state Error state

usually needs a longer lifecycle and may belong higher in the architecture.

A useful rule is:

`text
Local UI state
↓
Composable

Screen/application state
↓
ViewModel
`

The exact architecture can vary, but the principle is to keep state as close as possible to where it is actually needed.

Compose doesn't eliminate architecture problems

This is probably the most important lesson.

A modern UI framework doesn't automatically create a good application architecture.

You can still build a mess with Compose.

For example:

text Composable ↓ Database ↓ Business logic ↓ Network request ↓ More UI state

It might work initially.

But eventually the screen becomes responsible for too many things.

Compose makes it easier to write UI declaratively.

It doesn't remove the need for good separation of concerns.

What I'm learning

Working with Jetpack Compose has made me think less about manipulating UI elements and more about modeling state and events.

Instead of asking:

"How do I update this screen?"

I'm increasingly asking:

"What state should this screen represent, and what events can change that state?"

That shift is useful beyond Android.

It's a general way of thinking about interactive software.

The UI is not the application.

The UI is a representation of the application's current state.

Once that becomes your mental model, many UI problems become easier to reason about.

android #kotlin #jetpackcompose #softwarearchitecture #mobiledevelopment #programming #buildinpublic

Self-Hosting Taught Me That Deployment Is an Engineering Problem

DEVANSHU PATIL — Sat, 12 Sep 2026 13:49:35 +0000

Self-Hosting Taught Me That Deployment Is an Engineering Problem

I used to think of deployment as the final step after development.

Build the application.

Push the code.

Deploy it.

Done.

Working with my own VPS changed that perspective.

When you deploy your own application, you become responsible for much more than the application code.

You have to think about the server, networking, containers, domains, HTTPS, environment variables, logs, updates, and security.

My deployment stack

The setup I'm working with looks roughly like this:

GitHub
   ↓
Coolify
   ↓
Docker
   ↓
Application
   ↓
Reverse Proxy
   ↓
Domain
   ↓
Internet

The interesting part is that every layer can fail independently.

Your application can be perfectly fine while the deployment is broken.

For example:

text Application works locally ↓ Docker container starts ↓ But the port is wrong ↓ Reverse proxy can't reach it ↓ Domain shows an error

From the browser, all you see is:

"The website isn't working."

But the actual problem might have nothing to do with your application code.

A VPS forces you to understand the infrastructure

With managed hosting, many infrastructure decisions are hidden from you.

That's convenient.

But when something goes wrong, you may not understand what is happening underneath.

With a VPS, you start seeing the actual layers:

text Linux ↓ Docker ↓ Container ↓ Application ↓ Network ↓ Reverse Proxy ↓ DNS ↓ HTTPS

That's more responsibility, but also more learning.

Coolify makes the process easier

Using Coolify means I don't have to manually manage every deployment command.

I can connect a repository, configure the application, provide environment variables, and let the platform handle much of the deployment workflow.

But Coolify doesn't remove the need to understand infrastructure.

It just moves the repetitive work away from the command line.

If something fails, I still need to understand whether the problem is:

text Git Docker Application Environment Network DNS Reverse Proxy Server

That's where the real learning happens.

DNS is part of deployment

One thing that's easy to overlook is that your application isn't truly accessible just because it is running on the VPS.

The domain needs to point to the right server.

The traffic needs to reach the correct service.

HTTPS needs to be configured.

So the complete path becomes:

text User enters domain ↓ DNS resolves domain ↓ Request reaches VPS ↓ Reverse proxy receives request ↓ Request forwarded to container ↓ Application responds

Every arrow represents another possible failure point.

Deployment changes how you write software

Once you know your application will eventually run somewhere other than your laptop, you start making better decisions.

You think about:

Configuration outside the source code
Environment variables
Reproducible builds
Containerization
Logs
Health checks
Database persistence
Backups
Security
Rollbacks

These aren't "DevOps things" that someone else will deal with later.

They're part of running the software.

The biggest lesson

Self-hosting has made one thing very clear to me:

Writing code is only one part of software engineering.

An application isn't finished when it compiles.

It isn't finished when it works on localhost.

It's finished when you can reliably build it, deploy it, operate it, debug it, and recover when something goes wrong.

I'm still learning these parts by actually deploying and managing my own projects.

And honestly, that's much more valuable than memorizing deployment commands.

Because commands can be searched.

Understanding the system is what stays with you.

devops #selfhosting #docker #coolify #vps #linux #deployment #softwareengineering #buildinpublic