About — cold2blue

PROCESS

How I work

Solo development, end to end.

Every project goes through the same four-step sequence: isolate the problem, build it on-device, test it on real hardware in real conditions, then ship it with the submission handled. Nothing gets handed off, which means nothing gets lost in translation.

ISOLATE —

Define the exact problem before writing a line. If the scope can't be stated in a sentence, it needs more work before it needs any code.

BUILD —

On-device first, local by default. The architecture follows the constraint — not the other way around. Remote dependencies are introduced only when there's no local alternative.

TEST —

Real devices, real conditions — not just the simulator. Edge cases get tested because the users who hit them aren't running ideal setups either.

SHIP —

Store submission handled, review queries answered, post-launch issues read personally. The work doesn't end at the binary.

PRINCIPLES

What I believe

"Local processing is not a feature. It's the architecture."

If a task can run on-device, it runs on-device. I don't move data off the phone to simplify my infrastructure. The user's storage and data aren't a resource I get to tap for my own convenience.

"The user shouldn't have to trust the app. The code should make trust irrelevant."

Good privacy engineering means the user doesn't need to take anything on faith. The tool either has access to the data or it doesn't. Promises in the privacy policy are not a substitute for architecture.

"A smaller scope finished well outranks a larger scope that's almost there."

Scope is a design decision. Every extra screen is a commitment to maintenance, support, and explanation. I'd rather ship something complete and narrow than something broad that apologises with a roadmap.

"If it needs explaining, it needs redesigning."

A utility tool should be self-evident. If a user has to read a tooltip to understand what a button does, the button is wrong — not the user.

FAQ

Common questions

Are you a solo developer?

Yes. cold2blue is a one-person operation. Every line of code, every submission, every support reply comes from the same person. That's a deliberate choice — it keeps scope honest and quality personal.

What platforms do you build for?

iOS and Android, using native SDKs for each. Cross-platform runtimes are avoided where they limit access to platform-level APIs — which, for privacy and file management tools, is almost always.

Do you take contracts or only build your own products?

Occasionally both. If the scope is clear, the function is well-defined, and the approach is compatible with how I work, I'm open to contract engagements. The best way to find out is to send the brief.

How do you handle privacy in the apps you build?

On-device by default. Permissions requested only when the feature that requires them is actively in use. No analytics that contradict the stated function of the tool. If a data practice would look bad in a sentence, it doesn't appear in the product.

How long does a typical project take?

Depends on the scope, which is the point of defining it precisely upfront. A well-isolated, single-function utility can move from brief to submission in weeks. A suite of related tools takes longer — but the timeline is honest from the start.

The process is the quality control.