What I Learned From Shipping Multiple Apps While Still at University

Studying computer science and shipping software are complementary, but they train different instincts.

University gives me a vocabulary for reasoning: data structures, complexity, systems, networking, databases, and the discipline of explaining why something works. Building products forces a different question: can a real person use this reliably, on a device and a day I did not control?

Working on projects including Spheriz, PassportPlate, 100 Reps, Ritual Grove, and DevGuess has made that distinction concrete. I do not see coursework as a warm-up before “real” engineering. The fundamentals matter constantly. But a finished product creates constraints that a contained assignment often cannot.

A Working Feature Is Not Yet a Product

In a project assignment, the main milestone is often that the program meets its specification. In an app, that is the start of another list: first launch, empty states, loading, privacy, sign-in, failure messages, accessibility, updates, and the question of what happens when a person returns weeks later.

The core of 100 Reps is intentionally focused: a clear daily workout loop, progress, and a premium upgrade rather than a huge training platform. That simplicity is not a lack of engineering. It creates pressure to make the few interactions it does have obvious and dependable. A user should not need a tutorial to understand today's target or recover from an interrupted session.

PassportPlate made a related point from the opposite direction. Its central experience is offline and account-free by design. That means fewer backend problems, but it also means local data, saved history, product boundaries, and privacy are not incidental details. Choosing not to require an account is still an architecture decision with consequences.

Shipping Means Finishing Imperfect Things

The hardest part of independent work is often not starting. It is deciding when a product is coherent enough to release, knowing there are still improvements on the list.

Spheriz, Ritual Grove, and 100 Reps all pushed me toward scope control. A smaller complete loop, tested and explainable, is more useful than an ambitious backlog with no stable release. That has changed how I think about features: I now ask what the smallest version is that delivers the promised experience, what it costs to maintain, and what I am deliberately not building yet.

This is also where technical debt becomes real. A shortcut is not automatically bad. Sometimes it is the sensible way to test an idea. But it needs a name, an owner, and a point at which it gets revisited. The dangerous version is accidental debt: code added in a hurry that no one recognizes as a tradeoff until the next feature breaks around it.

Stores Turn Code Into a Whole Product

App Store work taught me that the application is larger than its screens.

For the mobile projects, release preparation includes build configuration, versioning, screenshots, metadata, support and privacy pages, TestFlight or device testing, and purchase behavior where relevant. RevenueCat and App Store purchasing are not just “a paywall package”; they introduce restore behavior, entitlement state, sandbox testing, and the obligation to avoid taking a user's money without giving them a reliable way to regain access.

Account deletion and privacy are similar. They are not cleanup tasks to append shortly before submission. If an app creates an account, deletion affects authentication, owned data, support flows, and what remains in backups or logs. If an SDK collects data, the disclosure has to match reality. The store review process makes those questions unavoidable, which is useful pressure.

Users Find the States I Did Not Model

The most valuable testing mindset I have learned is to stop testing only the happy path.

A fresh install is different from an update. A person with no data is different from a person returning after a month. A network request that fails halfway through is different from a request that never started. A purchase restored on a new phone is different from the first purchase. These are not exotic cases; they are normal product states.

DevGuess has been a good reminder that even a web project needs that thinking. A game loop and a polished interface are not enough if the data model, API limits, sharing output, or error handling are fragile. The interesting engineering is often in the boundaries around the obvious feature.

University fundamentals help directly here. Understanding data modeling makes state easier to reason about. Algorithmic thinking helps when a feature needs a clear invariant rather than another conditional. Networking and security basics make it easier to see why client input cannot be trusted. The practical difference is that production provides more ways for an assumption to be wrong.

Product Decisions Are Engineering Decisions

Building independently has made me more comfortable making choices that are not purely technical:

• Which user problem is worth solving now?
• What should work without an account?
• What does premium add without hollowing out the free product?
• What does this feature cost to support after release?
• Is another configuration option helping anyone, or avoiding a decision?

Ritual Grove is deliberately calm rather than optimized around punishing streak mechanics. PassportPlate uses randomness to reduce dinner-choice friction rather than providing an endless recipe database. Those are product choices, but they shape the data, UI states, and maintenance work underneath.

The goal is not to make every decision permanent. It is to make it intentional enough that the code, the product, and the explanation agree.

What I Bring Back to University Work

Shipping apps has made me more careful with university projects. I think sooner about boundaries, invalid input, failure modes, and whether a design has a clear source of truth. It also makes abstract topics feel less abstract: complexity matters when a list grows, persistence matters when state survives an update, and authorization matters whenever one user must not see another user's data.

At the same time, university gives me room to study ideas that a release schedule might postpone. That combination is the useful one. Coursework helps me reason beyond trial and error; product work forces me to translate that reasoning into something complete enough for another person to use.

Summary

I have learned that shipping is not a final button pressed after engineering. It is engineering under broader constraints: imperfect information, real devices, policy requirements, support, maintenance, and the need to decide what not to build. Smaller finished products have taught me more about those constraints than one indefinitely expanding side project could—and they have made me take the fundamentals behind my university work more seriously, not less.