Quite a few software ideas I've built in the last decade have had one user in mind: my wife. Feeling unsafe traveling alone? App. Reddit annoying her? App. Her music students struggling to identify tones by ear? Believe it or not, app.
Choosing what to build used to require a strict ROI calculation, simply because shipping required so much grunt work. Pre-AI, building custom tooling meant losing entire weekends to boilerplate code. With LLMs, the friction between "wouldn't it be cool if..." and a deployed app has collapsed. It's vastly simpler, decidedly less tedious, and an excellent source of spousal brownie points.
Building for such a singular use case gives you massive leeway. Think of the following as options for your unscalable playbook. If you are trying to ship a weekend build as fast as possible, these are some liberties you should be investigating for your specific usecase.
tl;dr
Every complex decision you make before your first user is just procrastination disguised as proactive engineering.
Keep the Architecture Dead Simple
You don't have to go with highly available, edge-routed, event-driven microservices with multi-AZ fault tolerance. Premature optimization is the fastest way to kill the momentum of a weekend project. A boring monolith paired with a boring data store will do for the first pass.
Every additional service you spin up is just another thing you will inevitably have to troubleshoot on a Sunday afternoon when you'd rather be doing anything else. A straightforward app + db combo will run happily for years. You don't have a strict SLA to maintain, and a system outage just means someone yelling from the kitchen that the app is wonky. Keep the architecture super boring so you can actually finish and ship.
There is a time and a place to be an architecture astronaut (when you're planning for a promotion and you need the packet to glow!) but this is not it.
Don't Be a Schema Purist
It's easy to get nerd-sniped into an elaborate, relationally correct, properly normalized schema. Don't let the ghost of Edgar F. Codd shame you into it though! Great velocity can be found in keeping the schema as flat as possible and not worrying too much about data duplication.
For instance, an attendance tracker I've built for my wife has its student roster hardcoded as a simple array into the codebase. Her roster is stable enough that updating a hardcoded array every few months is perfectly fine. Plus, you completely bypass the need to write JOINs or make unnecessary DB queries just to show a dropdown list. Sometimes the best schema is no schema at all.
Store Data in a File (if it Makes Sense)
Taking the "flat schema" philosophy to its logical conclusion: do you even need a database process running at all? If your concurrent user count is exactly one, you don't need to worry about connection pooling, or complex transaction rollbacks.
For many of these single-user utilities, just reading and writing to a .sqlite file is more than enough, or to .json if you're feeling adventurous. It eliminates the overhead of managing a separate database instance, keeps the entire project highly portable, and makes your backup strategy as simple as a cron job that copies a file.
Design Only for the Target Device
Instead of watering down your design to handle a dozen responsive breakpoints and cross-platform quirks, you get to make it pixel perfect for exactly one viewport. If she uses an iPhone, make it feel like a premium, bespoke experience on that specific screen resolution, and ignore the rest until the need arises.
You also get to skip the administrative fluff. You don't need to build out complex settings pages or preference toggles. If a value needs to change, you just update a constant in the codebase.
Having a single user is not a license to ship a garbage interface and skip the polish though. It means you can afford to go deep instead of broad.
Spicy Take: Own the Box, Skip the Auth
Grabbing a $5 VPS, or repurposing a Raspberry Pi, and tossing something like Coolify on it means you get the convenience of a modern PaaS deployment pipeline without being tied to a specific cloud vendor. You just have a box that quietly runs your Docker containers forever.
Because you actually control the host in this setup, it opens the door to my favorite hack-y shortcut: skipping the auth layer entirely. Building a robust authentication pipeline with JWTs, OAuth, and session cookies is simply overkill when you only have a single user.
Instead of writing, or importing, auth code, just drop the app onto your Tailscale network. The mesh network itself becomes your auth layer. You get access control without building a login screen or managing user states. If a device isn't securely authenticated onto your personal mesh, the application simply doesn't exist to them.
Just Ship It
If she loves the product so much that she gushes about it to her friends, and suddenly you have half the neighborhood asking for access to your Tailscale network, congratulations. You have successfully acquired a "good problem to have."
You can rewrite it in Rust and deploy it to a Kubernetes cluster then. Until that day comes, resist the urge to cosplay for scale. Just build the app, claim your brownie points, and enjoy your weekend.