> ## Content Index
> Fetch the complete content index at: https://www.kaitlinquinn.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# I Stopped Treating My Phone Like a Finished Product
- URL: https://www.kaitlinquinn.com/blog/i-stopped-treating-my-phone-like-a-finished-product/
- Published: 2026-09-16T23:42:25.000Z
- Updated: 2026-09-16T23:42:25.000Z
- Description: TL;DR: I connected a Fairphone to my computer with Android’s official developer tools and rebuilt it around the way I actually live. You do not need to become a programmer to stop accepting someone else’s defaults as the natural order of your phone.
- Author: Kaitlin Quinn
- Tags: Making things

I bought a Fairphone because I wanted a physical object I could repair. The more revealing change happened after I connected it to my Windows computer and began configuring it with Android’s own developer tools.

Most of us use our most personal computer as if it were a sealed appliance. We choose among the options the manufacturer places in front of us, rearrange a few icons, download our usual apps, and call the device ours. Technically, it is. Functionally, much of it still reflects somebody else’s theory of how a person should move through a day.

The Fairphone interrupted that routine. It is less common than an iPhone or a Samsung, which meant I could not move through setup entirely by muscle memory. I had to ask a better question than “Where is the setting I usually change?” I had to ask what I actually wanted the phone to do.

That question opened a door that sounds far more intimidating than it is. I did not “code my own phone” in the movie sense. I did something more useful: I treated the phone like a system I could understand and author.

## A phone already contains a theory of your life

A default Home screen is not neutral. Neither is a notification badge, a weather widget, an app drawer, or the choice to place entertainment one swipe away while hiding the information you need to leave the house on time. Each design decision distributes attention. Enough small decisions become a routine, and enough routines become the shape of a day.

I wanted weather that could answer a practical question: what will conditions look like over the next several hours? I wanted my actual calendar commitments visible without opening an app. I wanted ChatGPT, Transit, and Camera within immediate reach. I wanted music to remain available without letting every application compete for the same inch of my attention.

None of that is technically spectacular. That is exactly why it matters. The technology industry tends to present customization as decoration for ordinary users and infrastructure for experts. Change the wallpaper if you are a consumer. Open a command line if you are a developer. The useful territory between those roles is enormous, and most people are never invited into it.

## The intimidating door had an ordinary room behind it

Android hides Developer options by default. On my Fairphone 6, I exposed them by tapping the build number seven times and authenticating. From there, I enabled USB debugging, connected the phone with a data cable, and authorized my computer.

The connection used Android Debug Bridge, usually called ADB. It is an official Android tool that allows a computer to communicate with an Android device. The word “debug” makes it sound like something reserved for people repairing software at 2:00 a.m. (which I am doing more and more of these days 😼). In practice, my first command did nothing more dramatic than ask which devices were connected.

I started read-only. I verified the manufacturer, model, Android version, security patch, current launcher, installed packages, Quick Settings order, and selected notification settings. I checked the digital facts before changing the visible object. That let me work from the phone’s actual state instead of guessing from screenshots or following an old tutorial for a different Android version.

I was not rooting the phone, unlocking the bootloader, flashing firmware, or replacing the operating system. Those are different actions with different risks. I used a documented connection, approved one computer from the phone itself, and made controlled changes through interfaces Android already provides. USB debugging can also be turned off when the work is done.

This distinction matters because technical language often creates a false border. Specialized vocabulary can make an available capability feel forbidden. Sometimes the correct response is caution. Sometimes it is simply translation.

## Access is not the same thing as judgment

The useful part of this project was not gaining access to more powerful controls. It was deciding what deserved to change.

Before connecting the phone, I wrote down the jobs I needed it to do and the dependencies I couldn't casually disrupt. The wallpaper, accounts, media, authentication tools, property-access apps, and existing services all had value. The computer could help configure and inspect the phone, but the phone still needed to function independently when the computer was off.

That created a practical rule: make the smallest change that solves the real problem, then verify the result. I did not uninstall applications to create the appearance of minimalism. I did not replace the stock launcher simply because another launcher offered more control. I didn't delete tasks, invent test events, or alter emergency settings to create a cleaner before-and-after story.

Android reported a few historical widget bindings that were no longer visible on either Home page. It would have been easy to call them clutter and remove them. I left them alone because stale-looking data is not the same as harmful data. Technical access without judgment is just a faster way to make a mess.

## The finished screen looks almost boring

The top of my primary Home screen now shows Weawow’s seven-hour forecast across the full width. I removed my full saved street address because it added exposure without adding useful weather context. The underlying location, units, provider, alerts, and update behavior stayed intact.

Below that is a full-width Outlook calendar widget displaying the primary calendars from my two Microsoft 365 accounts. Birthday and holiday calendars are excluded, so the space is reserved for commitments that require my attention. The next row holds direct access to Weawow, ChatGPT, Transit, and Camera. My second Home page remains a deliberate music and listening space.

I also changed specific notification behaviors. Sensitive content is hidden while the phone is locked. Bubbles are off. Notification history and cooldown are on. Silent notifications no longer fill the status bar with icons. I left alarms, emergency alerts, priority contacts, and app-level notification relationships alone.

The result will not impress anyone who measures technical work by how complicated it looks. It impresses me because the complexity receded. The screen now presents information in the order I need it, and the phone asks for less attention when it has nothing useful to say.

## Defaults are tiny policies

We talk about phone configuration as personal taste, but a default is a policy in miniature. It determines which information is prominent, which actions are easy, which interruptions are rewarded, and which tradeoffs remain invisible. The effect may be small in a single interaction. Phones repeat those interactions hundreds of times a day.

The device does not know which obligations are real, how my body responds to interruption, whether I rely on transit, what information helps me leave home, or which parts of my life should remain private on a lock screen. A manufacturer can design for a market segment. It cannot design for my life with the specificity available to me.

This is where “personalization” usually sells us short. Choosing an accent color personalizes a system's appearance. Choosing what the system foregrounds, remembers, interrupts, and protects gives the user authorship over its behavior.

## You do not need to become a phone person

I am not arguing that everyone should install platform tools and start issuing commands. Maximum customization is not the goal. Proportional authorship is.

There is a wide ladder of control available before anyone needs to consider rooting a phone or installing a different operating system:

- Audit the native settings against the way you actually use the device.
- Replace a default app when another one serves the job better.
- Use widgets, launchers, shortcuts, and automation to change the path to frequent actions.
- Inspect an Android phone with official tools when the Settings interface does not provide enough visibility.
- Document what you changed and preserve a recovery path.

The first step can be as ordinary as noticing that your phone shows tomorrow’s temperature when the decision in front of you is whether to bring a jacket tonight. That mismatch is design information. You don't have to tolerate it just because the phone shipped that way.

## Technical people can afford to be more curious, too

People who work in technology are not immune to default thinking. Plenty of technically capable people buy the same two families of phones, reinstall the same applications, accept the same platform boundaries, and reserve experimentation for work. Convenience can be a sound reason for that choice. It should not make the choice invisible.

Try repairable hardware. Test a custom launcher. Read the permissions an application requests. Explore an open-source alternative. Connect an Android device to ADB and see what it can tell you before changing anything. Keep an older device as a safe place to experiment. An experiment does not have to become your daily driver to expand your understanding of what a daily driver could be.

The interesting challenge is not “code your own phone.” Most people do not need to write an operating system, and pretending otherwise turns agency into a technical purity test. A better challenge is to author your own computing environment: question the assumptions, choose the components, understand the permissions, make deliberate changes, and retain the ability to recover.

That approach asks more of technical expertise than cleverness. It asks for restraint, documentation, threat awareness, and respect for the ordinary human who has to live with the result. Sometimes that human is you.

## Ownership should include legibility

Fairphone is not liberation in a box. It is still a commercial smartphone running Android, connected to the same broad application economy and many of the same platform incentives as other devices. Less mainstream is not automatically more ethical, more private, or more capable.

What Fairphone changed for me was the starting posture. Its repairable hardware makes a quiet argument that ownership should include access, replacement, and continued use. Connecting it to my computer extended that argument into software. If I own the device, I should be able to inspect it, understand the important boundaries, and shape its behavior without treating every departure from the default as a hack.

I started with a weather widget and ended with a clearer standard for ownership: I should be able to understand the system, decide what it is optimizing for, and change it without asking permission from the person who guessed what an average user wanted.

The most personal computer I own should not merely recognize my face. *It should recognize my life.*