Nine small apps, and what they taught me

Over the past few years, I have built and deployed nine web applications, all hosted on Zeabur. Looking at the list together, they form an unconventional software portfolio. Only two are open public tools. One runs on shared room codes. The remaining six were built for small groups with specific needs.

Building small tools for defined audiences teaches practical lessons that rarely get discussed in startup blogs or technology podcasts.

Two public utilities

Professor Turtle and Quizzard are the only two projects in the group intended for general public use.

Professor Turtle was designed to help Singapore primary and secondary students revise for school examinations. It aligns practice questions with the Ministry of Education syllabus and grades open-ended answers against SEAB mark schemes, including scanned handwriting. Quizzard was built for live group gatherings, letting a host launch a trivia room while participants join immediately from their mobile phones using a six-digit PIN.

Both tools solve specific, repeatable problems for a broad audience. They require clear on-boarding, reliable public endpoints, and intuitive mobile interfaces.

One collaborative room game

Puzzle Arena occupies a middle ground between a public web app and a private tool. Anyone who receives a room code from a host can join, and players can practice solo against automated bots. It includes seven distinct games: Sudoku, Killer Sudoku, Nonogram, Word Search, and three turn-based board games.

Because Puzzle Arena features real-time multiplayer lobbies and custom algorithmic puzzle generators, its codebase is more complex than the others. It is the only repository in the group that I keep public on GitHub.

Six private tools

The remaining six applications were built for specific people and concrete workflows:

• Inscribe: An internal tool for recording, transcribing, and searching meeting discussions.
• Storyweave: An interactive fiction experiment where narrative chapters adapt to reader decisions.
• ChordViewer: A digital chord sheet archive for church musicians, allowing instantaneous key transpositions on stage.
• YarnNest: A crochet companion that tracks round-by-round progress and previews yarn color palettes for a crafter.
• Altar and Ink: A platform that drafts topical scripture devotionals in English and Chinese.
• Lifted: A mobile-first prayer wall for a church cell group to share requests and updates.

None of these six applications have marketing campaigns, analytics trackers, or public registration funnels. They do not need them. When you build software for half a dozen people whose faces you know, the definition of success changes completely. The code either helps them complete their task smoothly, or it does not.

What building nine apps revealed

Working through these projects alongside a full-time career in technology management surfaced three consistent patterns.

The first version must be narrow

Every project that launched successfully began with an aggressively narrow scope. When I built ChordViewer, I did not attempt to build a comprehensive music composition suite. I focused on one problem: taking an existing chord chart and shifting every chord up or down three semitones cleanly.

Whenever a project stalled in development, it was almost always because I allowed the initial scope to expand into unnecessary features before the core interaction worked well.

Authentication sets the emotional tone

Deciding how users access an application requires careful thought. A public utility like Quizzard works best with zero login requirements for players; adding an email sign-up screen would ruin the spontaneous fun in a crowded room.

Conversely, a small-group prayer board like Lifted requires a shared community passcode to feel safe and private. Authentication is not just a security mechanism. It defines how welcoming, intimidating, or private the application feels to the person opening the link.

Maintenance requires ruthless simplicity

When you maintain multiple applications on your own, complexity becomes an ongoing tax. Every third-party library, external service dependency, or complex database migration is something that can fail six months later while you are busy with family or your day job.

Choosing boring, reliable architectures and minimizing unnecessary dependencies is what allows nine separate applications to run quietly in production month after month without constant emergency fixes.

Modern hosting has removed the deployment barrier

A decade ago, provisioning servers, configuring SSL certificates, managing databases, and setting up deployment pipelines consumed a substantial portion of any software project. Modern cloud platforms have streamlined that infrastructure work into a routine step.

With hosting simplified, the real challenge of software development returns to where it belongs: understanding the user’s workflow, designing a clear interface, and writing reliable code that solves a genuine problem.