Mobile engineering
Android taught me to take constraints, lifecycle, performance, edge cases, and the last mile to a real user seriously.
About
Engineering depth.
A wider product lens.
I’m Stoyan Korudzhiev, a software engineer and product builder. Android and mobile shaped my technical foundation; building complete products expanded the questions I care about.
Product architecture
That foundation grew into a focus on boundaries, state, data flow, testability, and code that can change without turning every feature into a rewrite.
Complete products
I now carry those engineering standards across desktop and web products, product definition, interaction design, release work, and launch.
The through-line
Make the problem—and the system—legible.
The most valuable engineering work often happens before the implementation is obvious: choosing the right boundary, making state and data flow understandable, identifying which interaction carries the product, and deciding what does not need to exist yet.
I care about the complete result. That includes a technical structure that can evolve, predictable interface behavior, written language, visual coherence, documentation, and the way a product introduces itself to the market.
This is not an agency story. It is a hands-on engineering practice that has grown wider by repeatedly taking products from idea to something real.
Under the product
Architecture is how a product stays changeable.
Most people should never need to care about layers or dependency direction. They do care when a small change becomes a rewrite, behavior is hard to predict, or ownership cannot move safely to another engineer.
Keep change local
Give domain logic, data access, platform integrations, and presentation clear responsibilities so a change in one place does not ripple through the whole product.
Make behavior explicit
Treat loading, empty, error, offline, lifecycle, and performance behavior as part of the system—not cleanup left until the happy path is finished.
Build for continuation
Earn abstractions through real needs, protect critical paths with tests, and document the decisions another engineer will need to change the system safely.
GitGlow
A local Rust and Tauri foundation paired with a focused React interface.
Continuum
A local-first calculation workspace expressed across browser and macOS surfaces.
Green Compass
An Expo and TypeScript mobile product connected to Next.js web and Supabase data.
Working principles
What stays consistent.
Tools and surfaces change. The standards behind the work should not.
Make the problem legible
A team moves faster when the real constraint is clear and the language around it is precise.
Prototype the uncertainty
The first build should answer the hardest question, not simply produce the easiest visible progress.
Keep presentation honest
Polish should reveal the product’s value and boundaries, not decorate around missing substance.
Keep judgment in the loop
Use AI and automation to accelerate exploration and repeatable production while keeping verification, product judgment, and responsibility with a person.
A useful overlap?
I’m always interested in a thoughtful conversation.
Especially when the problem crosses product direction, technical execution, and the systems around shipping.