I studied computer science and physics on separate tracks — CS taught me to ship software before the semester ended, physics taught me what the numbers in a sensor CSV actually mean. uranashel exists at the intersection of those two educations, and nearly every feature that works across our five apps followed the same sequence: a real-world problem appeared, physics described why the naive approach fails, and code was written to respect that description rather than fight it. The sequence was never trend-first — nobody at this studio sat down and said "AI is hot, let's wrap an API." The sequence was problem-first, and the problems kept being physical.

Wheria: when the map lies

The origin story is documented elsewhere, but the physics content is the point. GPS fails underground not because Google Maps is lazy, but because L-band microwave signals attenuate in concrete and multipath reflections bias pseudorange estimates by tens of meters. The naive software response — show the blue dot anyway, maybe smooth it — is lying to the user with extra steps. The physics-informed response is pedestrian dead reckoning: detect discrete steps from accelerometer peaks, update heading from gyro integration corrected by magnetometer when the field is clean, hint floor level from barometer differentials, fuse everything in a Kalman filter that outputs uncertainty rather than false precision. I would not have written that pipeline without knowing why double integration of accelerometer data drifts meters per second, or why compass readings become worthless near steel columns. CS alone would have produced a prettier map tile. Physics alone would not have shipped it through App Store review.

Sonarish: when the machine hums differently

Sonarish started because an air conditioner began humming at 127 Hz after three years of service — a harmonic of the 60 Hz mains supply coupling into a 2-pole induction motor running at 3600 RPM. The physics is rotating machinery: shaft frequency, bearing defect sidebands, broadband noise from loose mounts. The naive response is "train an AI classifier on cloud audio." The physics-informed response is an on-device FFT with A-weighted LAeq integration, a baseline snapshot when the machine is healthy, and a diff view that shows which frequency bins rose more than 6 dB since last month. We do not auto-diagnose bearing failures because the physics is ambiguous without knowing the machine — we show the spectrum diff and let you call a technician with data instead of vibes. Knowing Nyquist's theorem before choosing the 48 kHz sample rate, and knowing A-weighting before comparing readings to a municipal noise ordinance, are physics decisions that directly determine whether the app is useful or misleading.

Estua and Phyzix: perception and pedagogy

Estua exists because the human auditory system detects periodicity in looped recordings within minutes — a psychoacoustics problem, not a compression problem. The solution is real-time synthesis of 1/f noise with uncorrelated LFO modulation, running on the audio thread under hard real-time constraints described in our audio thread post. Phyzix exists because students treat phones as consumption devices rather than measurement instruments — a pedagogy problem. The solution is live sensor graphs with SI units, exportable CSV, and simulations where the equation sits beside the animation so the connection between formula and motion is visible. Neither app required a physics degree to conceive. Both required physics to implement correctly.

What each discipline alone would miss

Computer science without physics produces apps that compile, pass review, and confidently display wrong answers. You integrate accelerometer data because the API returns acceleration values and integration is what programmers do with time-series data — then you wonder why the parking dot teleports. Physics without computer science produces correct equations in notebooks that never survive Android foreground service rules, iOS background location limits, Compose recomposition jank, or ktuyen's test matrix that catches compass drift on iPhone 15 in a steel garage but not on Pixel 8. uranashel is three people precisely because the skill set spans both: I write the sensor pipelines and DSP, atuan makes the backend and release infrastructure real, ktuyen makes the quality gate real in Vietnamese and English on real devices in real garages.

You do not need two degrees

You need curiosity about the sensor underneath the API documentation, and honesty when the math says your UX is lying. A degree is one path to that honesty — it is not the only path. Garage logs at Landmark 81 taught me more about multipath than any textbook chapter. Listening to an AC unit change pitch over three years taught me more about bearing degradation than any lecture. The Lab page on this site exists so you can reproduce some of those observations yourself. If you want the studio context, start with the welcome post and follow the links wherever your curiosity points — whether that is magnetometer ellipsoids, pink noise spectra, or Kalman covariance traces.