How I think about software
I'm Owais Raza, a software engineer. This page is not a biography — it's an explanation of how I make engineering decisions, so you can judge whether that thinking fits your problem before we ever talk.
Philosophy
Software is a means. Every system I've built that worked started from what the business was losing — money, time, trust — and every decision in it can be traced back to that. When a technical choice can't be explained in terms of the problem it solves, it's usually decoration, and decoration in production code is debt.
I optimize for the day someone has to change the system, because that day always comes and it's rarely me who's there for it. That's why I treat simplicity as risk management rather than aesthetics: BillWise stores everything in SQLite on the shop's own machine because the business didn't want its data in someone else's cloud — not because local-first is fashionable. The planning platform runs its API, gRPC, and background workers in one process because one process is the simplest thing a small team can operate — the architecture earns more moving parts only when the load proves it needs them.
The hardest property to get right is evolution. You can't predict what a business will need in two years, so I don't try — I try to make being wrong cheap. That means boring, well-understood technology at the foundations, boundaries placed where change is most likely, and designs that let a piece be pulled out and replaced without taking the system down with it. Design for extraction, not perfection — that lesson came out of real work, and it's the closest thing I have to a method.
Engineering Principles
Principles only mean something when they cost you something. The five below are the decision rules behind the projects on this site, and each one names the price I accept by holding it — because a principle you'd abandon under deadline pressure was never a principle, just a preference.
Business before technology
The stack serves the roadmap, never the reverse.
Simple beats clever
Clever code is a liability the client pays for later.
Measure, then optimize
No performance work without a baseline number.
Boring reliability over exciting shortcuts
Production is not the place for novelty.
Build for the engineer who comes after me
Maintainability is a deliverable, not a virtue.
Professional Journey
Backend lead on an internal project planning platform: owned the architecture, schema, API design, deployment, and testing; led the backend side of a five-engineer team and wrote roughly sixty percent of the backend implementation myself.
BillWise: designed, built, and shipped an offline-first desktop billing system solo — schema to deployment — for a real repair business, where it remains in daily use.
Open Source
Claims are cheap; repositories aren't. A public codebase shows the things a portfolio page can't — how I name things, where I put boundaries, what I document, what I test, and what I do when a design turns out to be wrong. I publish work for the same reason the case studies on this site show tradeoffs instead of victory laps: anything I say about engineering quality should be checkable. Writing for an unknown reader also sharpens the work itself — code you expect to be read gets documented decisions, honest READMEs, and fewer shortcuts.
You've read how I make decisions — the useful next step is applying that to something real. Bring the problem you're building toward or untangling, and you'll get my honest read on it, including whether I'm the right person for it.